Mark,
as others already said, these utilities (DSMSERV UNLOADDB, DUMPDB,
LOADDB and AUDITDB) in fact ARE documented and always have been
(Appendix A in the 3.7 and 4.1, appendix D in the 3.1 admin ref.).
They are poorly documented though, e.g. not saying anything about
the required time, and not stating the possibility to restrict the
AUDITDB on part of the DB, but that's what the recurrent complaints,
at least in part, where about.
Furthermore, you may come into a situation, where support advises
you to perform these utilites. I once was there, but fortunately decided
to perform a test on a copy of my production server at first. It turned
out to last for several weeks, so I decided not to follow that advice.
That was on version 3.1, things may have changed since then, but again:
nothing official can be heared from Tivoli.
Personally, I'm feeling very uncomfortable about that situation. And I
think, complaining about it has nothing to do with "whining".
Reinhard
Mark Stapleton (stapleton AT berbee DOT com) wrote:
> "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)
--
Reinhard Mersch Westfaelische Wilhelms-Universitaet
Reinhard Mersch Westfaelische Wilhelms-Universitaet
Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583
E-Mail: mersch AT uni-muenster DOT de Fax:
+49(251)83-31653
|
