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 [EMAIL PROTECTED] 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
