Roger,
I once got the information that it's good to leave 16 MB unused in the TSM
DB for easing any select command you may send via admin client...
René LAMBELET
NESTEC SA
GLOBE - Global Business Excellence
Central Support Center
Information Technology
Av. Nestlé 55 CH-1800 Vevey (Switzerland)
tél +41 (0)21 924 35 43 fax +41 (0)21 703 30 17 local
UBS-Nestec, Bussigny
mailto:[EMAIL PROTECTED]
This message is intended only for the use of the addressee
and may contain information that is privileged and confidential.
-----Original Message-----
From: Roger Deschner [mailto:[EMAIL PROTECTED]
Sent: Monday,17. March 2003 19:15
To: [EMAIL PROTECTED]
Subject: Re: Fragmented Database Question 2
Why is your Maximum Extension anything other than zero? Is there some
reason you are deliberately hiding some of your database capacity from
yourself? At any rate, it is probably causing confusion as you look at
the numbers from QUERY DB. Enter
EXTEND DB 1500
and then do a query and the numbers should make much more sense.
The only time you should deliberately reduce the database capacity is if
you have some kind of reorganization project underway, in which case it
is useful and essential to reduce the database and/or log to less than
the amount of disk space you have. There's a nice treatise on how all
this works in "TSM Administrator's Guide" - look for the section titled
"How Space is Managed by the Server" which is in the chapter "Managing
the Database and Recovery Log", which is Chapter 19 in the manual
version for V4.2. (GC35-0403-01)
And I agree with Richard Sims about not worrying about fragmentation. It
comes with the territory, and there's nothing lasting you can do about
it, so spend your time worrying about the things you can control. You
can gain much more performance, and your gains will be permanent, with
basic OS-level disk tuning, and by spending your time lobbying your boss
for a bigger faster computer to run your server on. The economic
downturn has produced some fabulous buys on used server-grade equipment,
such as RS/6000 and Sun. In December, I upgraded the hardware to 8x more
crunching power and 8x more memory, and it's a much, much happier TSM
server.
Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED]
Academic Computing & Communications Center
"Have you ever, like, tried to put together a bicycle in public? Or a
grill?" Astronauts David Wolf and Piers Sellers, explaining the
difficulties encountered in attaching equipment to the Space Station
On Sun, 16 Mar 2003, Zlatko Krastev/ACIT wrote:
>2176000 - 1787528 = 388472 empty pages
>388472 * 4096 bytes/page = 1591181312 bytes = 1553888 kB = 1517,46875 MB
>Maximum reduction is 1492 MB, thus the fragmentation is 1,7% - you ought
>to happy with it.
>
>Zlatko Krastev
>IT Consultant
>
>
>
>
>
>
>Farren Minns <[EMAIL PROTECTED]>
>Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
>28.02.2003 18:14
>Please respond to "ADSM: Dist Stor Manager"
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject: Fragmented Database Question 2
>
>
>Hi Again
>
>Regarding the TSM DB, wouldn't the 'Used' and 'Total Usable Pages' figures
>help to point to a fragmentation problem.
>
>The output fro our DB is as follows:-
>
>Available Space (MB): 10,000
> Assigned Capacity (MB): 8,500
> Maximum Extension (MB): 1,500
> Maximum Reduction (MB): 1,492
> Page Size (bytes): 4,096
> Total Usable Pages: 2,176,000
> Used Pages: 1,787,528
> Pct Util: 82.1
> Max. Pct Util: 82.5
> Physical Volumes: 2
> Buffer Pool Pages: 32,768
> Total Buffer Requests: 10,278,342
> Cache Hit Pct.: 98.88
> Cache Wait Pct.: 0.00
>
>
>
>Our database is 8500Mb assigned, and 82.1% utilised. So how do the figures
>of '1,787,528 pages used' and '2,176,000 Usable Pages' work in this case.
>If we have used 81% percent of 8500, our usable pages should be much lower
>than used pages shouldn't it? Or am I missing something?
>
>Thanks again
>
>Farren Minns - John Wiley & Sons Ltd
>
>
>
>
>
>Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
>
>Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
>
>To: [EMAIL PROTECTED]
>cc:
>Subject: Re: Fragmented Database Maybe?
>
>
>>I'm Running TSM 4.2.2.12 on a Solaris 2.7 server (E250 400Mhz, 1GB mem).
>>We have been having severe performance issues recently and moved our
>database
>>volumes off onto a new disk...
>
>You haven't cited the cause-effect case which would motivate such a
>change.
>Are you certain that is the problem area? If this is a substantial
>server,
>then I would first wonder about the 1 GB memory size, which is rather
>small
>these days. More memory is usually the most expeditious way to increase
>the performance of a computer system. System performance monitoring
>should
>reveal the bottlenecks.
>
>>Also, is there anyway to see if indeed the database is fragmented?
>
>(Chuckle) By definition, all databases are "fragmented" - it's
>inevitable,
>and the way they operate. You will see numerous postings in the archives
>that advise you not to be fixated on this, as it's unavoidable, and
>efforts
>to "fix" it are ephemeral and time-costly.
>
>Richard Sims, BU
>
>
>
>
