As any other monitoring measurement, it matters only for the value it
measures - fragmentation.
For example it shows high fragmentation numbers for Wayne's database. The
latter leads to a conclusion that he would really benefit from doing
unload/load. But all others having the database less than 20-30%
fragmented, the typical answer would apply - even if database is
defragmented the result will be temporary.
If the fragmentation value is 50% (or more), some space can be conserved.
And for 80% and beyond, the space savings can be significant.
So it is only one aspect of TSM server health-check. As with any complex
product, the overall picture consists of many such throttles, bells and
whistles :-)
Zlatko Krastev
IT Consultant
Roger Deschner <rogerd AT UIC DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
21.10.2003 18:42
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Database fragmentation formula (was Re: Online DB
Reorg)
I have to ask one thing about all this higher math - Does it matter?
That is, what can you do about it, or what should you do about it? I
think the answer is that, even if these competing formulae are correct
and you discover your database is fragmented, there is practically
nothing you can or should actually do. Except in the case where a TSM
system is being deliberately shrunk, such as by removing a bunch of
nodes, there is nothing you should attempt to do about database
fragmentation.
Fragmentation occurs at three levels, as far as I can tell. But any
speculation on my part as to what those three levels are is just that -
speculation. And conjecture from external observation.
I do know that there is fragmentation within TSM's storage units, and
then there is fragmentaiton of TSM's units within the OS file system's
storage units. Measuring or fixing the former involves the lengthly and
risky unload/reload procedure which I do not ever recommend. I suspect I
can see the latter, by comparing the amount of free space shown by Q
DBVOL F=D, and the amount of free space shown by Q DB. I could correct
fragmentation at that level with DELETE DBVOL, which is easier than
unload/reload, but it still won't achieve much and the effect still
won't last.
So all this mathematics still does not give me much to go on, in terms
of how to make my TSM system run better in the long term. I ran that
first SELECT published in this thread on my system and came up with
-0.04% fragmented. Obviously a flawed formula. I know my database is
fragmented, simply because it is old and big.
But what you can do, that will help, is to just give it enough room and
let it spread itself out far enough that it can usually get contiguous
space, at all levels including the physical level, when it wants to
write something that is large enough to span multiple units, whatever
those units are. A full, fragmented database will defragment itself to a
degree after it has been run with additional space for a while. Throw
more disk drives at the problem. An 80% full database of any kind WILL
run faster than a 98% full database. Of that I am very, very certain.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
"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
|
