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     rogerd AT uic DOT edu
               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 <fminns AT WILEY.CO DOT UK>
>Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>28.02.2003 18:14
>Please respond to "ADSM: Dist Stor Manager"
>
>
>        To:     ADSM-L AT VM.MARIST DOT EDU
>        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" <ADSM-L AT VM.MARIST DOT EDU>
>
>Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>To:        ADSM-L AT VM.MARIST DOT EDU
>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
>
>
>
>