Thanks to everyone who replied to this.
Most helpful indeed.
Farren :)
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: Question about database fragmentation
If your system is at all large, fragmentation is just a way of life.
After a while, it will not get any worse. Except when you do a lot of
filespace deletions at once, as Paul Seay said, or if expiration breaks
for a while and is then repaired, it will get out of kilter, but that is
a self-healing problem. It will work itself back towards its normal
steady-state fragmentaion, eventually. (Disclaimer!) I _THINK_ it will.
You can't fix it without more downtime than you can afford, and it's not
easy to measure, either.
SOMEBODY PLEASE TELL ME IF I'M COMPLETELY WRONG, but my observation is
that there are two kinds of fragmentation in the TSM database. 1) The
B-tree gets unbalanced and fragmented 2) The pages that contain active
parts of the structure become fragmented across too many blocks.
BOTH kinds of fragmentation are harmfull in that they increase seek
distances to get to the data, and increase the number of disk seeks to
get a group of data items which are logically together.
I do not know how to measure the first kind of fragmentation, except for
the painful and lengthly UNLOAD/RELOAD process and then see how much it
shrinks. This will take "until the cows come home" or whatever
expression you use for "much too long".
However, the second kind of fragmentation is more easily measured. Do Q
DBVOL F=D and add up the "Allocated space" for all of them. Divide that
into the total Avalable Space, and you'll get a percentage. The
difference between that percentage and the Percent Utilization shown by
Q DB is how badly disk pages are fragmented across disk blocks.
The SECOND kind of fragmentation, BUT NOT THE FIRST, can be cured by
DELETE DBVOL. This is still a time-consuming process, but at least it
can be done with TSM up and available to clients, albeit running slow.
What I have described, about two different kinds of fragmentation, is
from observations on my own system, not from any information from
anybody else. If this is wrong, somebody please tell me a different way
to interpret what I am observing.
But, to summarize, it is probably not worth worrying too much about
Database fragmentation, because there is not much you can afford to do
about it, and it really is not hurting performance all that much,
compared to some of the glaring configuration mistakes you can make.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
==== "Research is what I'm doing when I don't know what I'm doing." ====
========================= -- Wernher von Braun =========================
On Wed, 2 Oct 2002, Seay, Paul wrote:
>The only way to reorganize the database is an UNLOADDB, LOADFORMAT,
LOADDB.
>Nothing else accomplishes this. If your database has had lots of
filespace
>deletions the tree can get severly unbalanced and negatively affect
>performance.
>
>Paul D. Seay, Jr.
>Technical Specialist
>Naptheon Inc.
>757-688-8180
>
>
>-----Original Message-----
>From: Farren Minns [mailto:fminns AT WILEY.CO DOT UK]
>Sent: Wednesday, October 02, 2002 9:47 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Question about database fragmentation
>
>
>Hi All
>
>I wonder who can help me with this. Does the database become very
fragmented
>over time? If so, is there any way of telling how much? Also, is the only
>fix for this to do a dump and reload of the database?
>
>If the answer to the final question is yes, how easy are dump/reloads?
>
>We recently upgraded from TSM 3.7.3.8 to 4.2.2.12 and had to run an
auditdb
>first (which completed without any problems).
>
>Many thanks in advance
>
>All the best
>
>Farren Minns - TSM and Solaris System Admin - John Wiley and Sons Ltd
>
>Our Chichester based offices have amalgamated and relocated to a new
address
>
>John Wiley & Sons Ltd
>The Atrium
>Southern Gate
>Chichester
>West Sussex
>PO19 8SQ
>
>Main phone and fax numbers remain the same:
>Phone +44 (0)1243 779777
>Fax +44 (0)1243 775878
>Direct dial numbers are unchanged
>
>Address, phone and fax nos. for all other Wiley UK locations are unchanged
>
****************************************************************************
>**
>
Our Chichester based offices have amalgamated and relocated to a new
address
John Wiley & Sons Ltd
The Atrium
Southern Gate
Chichester
West Sussex
PO19 8SQ
Main phone and fax numbers remain the same:
Phone +44 (0)1243 779777
Fax +44 (0)1243 775878
Direct dial numbers are unchanged
Address, phone and fax nos. for all other Wiley UK locations are unchanged
******************************************************************************
|
