Hi, Frank -

Our ability to deal effectively with TSM database behaviors is
extremely limited, in that very little information about it has been
published by IBM. The most insight we have is from the occasional
SHARE presentation, such as "Everything You Always Wanted to Know
About the TSM Database" (Kaczmarski 2001), but itself very limited.
Databases vary in their methods of handling data distribution. TSM's
database will split a page when it fills, and that results in db data
being distributed within it. This may be viewed as "bad" because it
separates some content; but it is also "good" in that it makes space
and thus the opportunity to collocate db entries adjacent to others.
As with all databases, having active portions of it cached in memory
or accessed by multiple disk arms (multiple disks and/or RAID). And,
"database performance" is relative to what content is being
referenced at any given point in time: the pattern of reference.

There is no real control over fragmentation in a database. It could
be said that "fragmentation" is being characterized these days as a
negative term to describe any database's natural method of managing
its internal space as new records are added. I think if it were
instead termed "population apportionment" that no one would get
agitated about it, and the veritable fad for TSM database
reorganization would abate. Adjacency seems like a goal only if you
discount the overhead of then having to make space for inserts
because of overcrowding. (Those of us who dealt with VSAM remember
how costly Control Area and Control Interval splits were.) This is
all over-emphasis on one aspect of a very large whole that is TSM.
Don't get preoccupied with it.

   Richard Sims

On May 17, 2006, at 12:32 PM, Frank Tsao, email is tsaof AT sce DOT com wrote:

Richard,

Is there any way can minimize the fragmentation? For example, like how
much maximum reduction size should have before the database reach a
point
of no response.

Frank Tsao