>So, will defragging the database really improve my restore times?
>Seems pointless otherwise.

Shawn - One of those issues...  Tivoli provided the barely-documented
        unload-reload db reorg procedure, but at the same time has
published no information anywhere about TSM database internals and
what's good or bad, because it is proprietary and not to be disclosed.
This leaves customers in purely guess-mode, speculating amongst
ourselves as to whether any given statistic about the database is
meaningful or should incite some kind of administrative action.
Given the random nature of a database, is fragmentation "bad" - or
does it represent an opportunity to insert the next record in the
midst of things instead of way out on the fringe?  "Fragmentation"
in a database typically means that data is distributed, not that
it is "broken up" or "disjointed".  We're really in the dark on this
issue.

So is it worth proceeding with the unload-reload?  Taking TSM down for
a prolonged period represents a disruption in the service schedule.
Those who have undertaken the reorg have posted marginal gains in
performance, and those gains are ephemeral, as database updating
gets us back to where we started.  And the operation is a huge
gamble...  How rigorously developed and tested are backwater utilities
like this?  And what if, unbeknownst to you, there is a problem in
your database that daily processing doesn't go near.  We've all seen
the postings of customers whose database load ran for many hours -
and then failed on an internal inconsistency...an awful situation
in which to find one's self.

There are many causes for slow restorals, and I would pursue those
before approaching a db reorg.  Much can be done for database
environmental tuning and the like.  I've accumulated notes in
http://people.bu.edu/rbs/ADSM.QuickFacts regarding restoral
performance, based upon experience that all of us have had:
perhaps that can be of some aid in your analysis.

  Richard Sims, BU