Mark,
I agree with you that the benefits from using UNLOADDB/LOADDB may prove
transitory, and that they tend to be very long running and therefore are of
marginal utility for a production
database, but
DSMSERV UNLOADDB
DSMSERV LOADDB
are documented commands at least in the OS390 world, see:-
TSM for MVS and OS/390: Administrator's Guide
4.4.5.5 Compressing the Database
Over time, database volumes become fragmented. You can restore the
efficiency of the database by unloading and reloading it. First unload the
database in key order. Then reload the database, which will compress and
reorganize it. When the server is offline, use the DSMSERV UNLOADDB
utility. After unloading the database, use the DSMSERV LOADDB utility.
After using the DSMSERV UNLOADDB utility and the DSMSERV LOADDB utility,
the DSMSERV AUDITDB utility may be required to locate and correct any
database inconsistencies. Here is an example of compressing the database,
where the database is unloaded to tape:
.
Mark Stapleton <stapleton AT BERBEE DOT COM> on 04/26/2001 05:18:30 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: John Naylor/HAV/SSEG)
Subject: Re: Reducing/compressing the database
"Thomas A. La Porte" wrote:
> Is anybody else a little bit distressed that Tivoli's TSM
> administrator needs to seek this advice from the list, rather
> than from the developers of the product?
I think I've read just about enough whining in this thread about how
Tivoli 'distresses' people by not commenting on/explaining/helping with
undocumented and proprietary commands. *Of course* there is no official
documentation on undocumented UNLOADDB/LOADDB, SHOW, and the various
undocumented flags to some commands.
There seems to be some mania in our list about 'defragging' a database
and how it is considered a cure for all TSM ills. The real world shows
that 'defragging' any database has at best minor results, save in the
most severely edited database. 99% of slow response problems stem from
far more likely situations, such as poorly configured networks and bad
TSM configurations.
People should keep in mind that there is a reason why undocumented
commands are undocumented. It's because they're buggy, unreliable, and
in some cases, dangerous to your TSM installation. Anybody who would run
UNLOADDB/LOADDB on a production box gets anything they deserve. If
you've *got* to reach for the nirvana of defragging your database,
consider running DSMSERV RESTORE DB from the OS command line; this is a
documented procedure for which you can get support help if necessary.
There. That should be enough flamage for one day. Sorry, folks; I've
been subjected to the same basic complaint for the four years I've
tracked this mailing list, and it was just time to say *something*.
--
Mark Stapleton (stapleton AT berbee DOT com)
Mark Stapleton (stapleton AT berbee DOT com)
**********************************************************************
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy plc.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission.
Scottish Hydro-Electric and Southern Electric are trading names of
Scottish and Southern Energy Group.
**********************************************************************
|
