The following is copied from the Windows NT V.3.7 Admin guide
Periodically the database size and internal organization can develop to where
it is no
longer internally efficient. To improve database performance, the database can
be
unloaded and re-loaded in an optimal manner that will:
Improve the performance of the server database dump and load functions
Improve the performance of the database audit functions
Organize the database in an internally optimal manner so that an efficient
amount of
space is used, fragmented page allocations are re-organized, and the
performance of
long-running scans of the database is improved.
See "Compressing the Database" on page 425 for more information.
The database and recovery log buffer pool sizes can also affect TSM
performance. A
larger database buffer pool can improve performance, and a larger recovery log
buffer
pool reduces how often the server forces records to the recovery log.
On Tuesday, October 03, 2000 7:37 AM, Richard Sims [SMTP:[EMAIL PROTECTED]] wrote:
> >I am currently looking into unloading and reloading our TSM database. My
> >database has not been unloaded or reloaded since we installed ADSM in 1995,
> >and the database has grown from 6gb to 32 gb.
>
> Monte - This issue was discussed on the list about 10 days ago, so see
> the archives for info.
> Databases grow because of the amount of data contained in them.
> Doing an unload-reload will not reduce the amount of data: it will
> only consolidate blocks. As daily activity proceeds after such a
> reorganization (which will likely take 3 days), updating will result
> in database records scattering, so you'll eventually end up with
> what you already have. And the b-tree nature of the database may
> actually require the size of your database disk allotment to be
> increased for the reload. I don't see any real advantage to going
> through an unload-reload - particulary considering the cost - and
> Tivoli has not published any supporting background information or
> studies that I am aware of. Databases are random-access amalgams
> where consolidation is of no inherent advantage. The historic
> absence of any information supporting unload-reload as an efficiency
> booster in the product leaves me dubious. And if it were of great
> benefit then one should expect Tivoli to provide far more efficient
> means of performing it.
> Richard Sims, BU
