ADSM-L

Re: TSM 5.3.3 loaddb and audit problem

2006-05-17 14:22:40
Subject: Re: TSM 5.3.3 loaddb and audit problem
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 17 May 2006 11:25:48 -0700
Hi Richard,

Thanks for your remarks. If you have specific recommendations to improve
the quality of our documentation, they are welcome and will be considered.
I agree that more could be included with regard to understanding the
potential run-time for the commands, ensuring that proper precautions are
taken before beginning the operations in questions, etc., and this will be
looked at.

There is no denying that -- like many other functions -- there have been
defects in the subject utilities. Having said that, I would like to
address a few items:

- All of the commands and utilities described in the TSM documentation
proper are officially supported production code (I am not aware of any
exceptions to this).

- UNLOADDB/LOADDB is NOT a salvage operation.

- DUMPDB/LOADDB is indeed a salvage operation.

The "Database Salvage Utilities" section in the Admin Reference (Appendix
A) states:

"Use the following utilities to re-establish your server database if a
catastrophic error occurs, and the database cannot be recovered
effectively using the DSMSERV RESTORE DB utility."

The reference info for DUMPDB includes this statement:

"Use this command as the first step in dumping, reinitializing, and
reloading the server database if a catastrophic error occurs (recovery log
corruption, for example), and the DSMSERV RESTORE DB command cannot be
used."

Thus it should be clear that DUMPDB is NOT a database "reorganization"
utility to be used willy-nilly.

The AUDITDB reference info includes this statement:

"Attention: Contact Tivoli Storage Manager Software Support before issuing
the DSMSERV AUDITDB command if you are using this command in situations
other than when a message indicates it is necessary."

So for these functions, which are indeed related to salvaging the
database, the warnings are there.

- I do not know where the manual "blithely [entices]" customers to
reorganize their database. If you could point that out to me, we will
investigate rewording if it is too "footloose and fancy-free". I do agree
that the reference info for UNLOADDB might be well served with a caution
to use the BACKUP DB command first, to ensure that the database is backed
up before undertaking a reorganization. The documented procedure in the
Admin Guide for reorganizing the database includes this precaution.

- See the ESTIMATE DBREORGSTATS command in the 5.3 Admin Reference (or do
HELP ESTIMATE DBREORGSTATS from the Admin CLI), as this addresses the
issue of identifying the potential savings that a reorg might achieve.

General advice: one should take great care to READ AND UNDERSTAND this, or
any other command, before issuing that command (and this applies to almost
ANY software product, not just TSM).

Best regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www-306.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2006-05-17
05:09:39:

> Hi, Kelly -
>
> I was appalled when I first saw TSM manuals blithely enticing
> customers to reorganize their TSM databases as though it were some
> kind of risk-free, trivial undertaking. Nowhere in the documentation
> for this procedure are there the strong advisories which should be
> there regarding the prolonged unavailability which your site's data
> recovery facility will experience during the procedure, full
> perspective on why it might ever be warranted, the risks involved,
> what messages to expect, how to know whether or not the operation has
> succeeded, or what to do in case of a problem. Conspicuously missing
> is any mention that the utilities involved are not mainstream TSM
> software, but rather salvage utilities - which get little developer
> attention or testing (as is evident in the frightening APARs I've
> read on these utilities).
>
> To my experienced eye, this was an extraordinarily irresponsible
> thing for IBM to do, and a recipe for disaster. TSM novices in
> particular will see this in the manual, think it harmless because IBM
> offers it, and launch right into it. Unfortunately, the disaster
> potential has been borne out by customers writing to ADSM-L for help
> upon discovering the hard way that their TSM database is no longer
> viable after the operation. (And we don't know how many more
> customers have suffered silently.)
>
> It is high risk stuff, and almost always unwarranted, as customers
> are typically trying it expecting it to be some panacea for their
> system. Without an understanding of databases in general and the TSM
> db specifically, a customer is wandering through an unfamiliar house
> in the dark in such an undertaking, where the risk of getting hurt is
> high.
>
> The fact is that IBM *DOES NOT* have suitable software for its TSM
> customers to use to reorganize the TSM database. Salvage utilities,
> by their nature, are VERY physical in their orientation and
> operation, with no customer-meaningful feedback during execution and
> no customer-oriented assurance summary at conclusion.  (I speak from
> experience in having run these utilities - and having seen no
> enduring performance or space benefit.)  And, again, these utilities
> are not part of the main product and, as "tributary" software,
> receive little developmental attention. Such software is wholly
> unsuitable for this purported usage. And the encouraging but
> unadvising documentation only makes the situation worse.
>
> I can't imagine who, at what level in IBM, thought it was a good idea
> to suggest that salvage utilities be promoted as a means for
> accomplishing vaguely described goals.  It boggles my mind that IBM
> would encourage their enterprise customers to blindly risk their
> corporate recovery vehicles, to no well-defined end.  I simply do not
> understand how a technical organization could have decided upon such
> an ill-conceived and irresponsible course of action.
>
> I strongly believe that all documentation for the use of these
> utilities for TSM db reorganization should be removed from the TSM
> manuals.  If at some time in the future, IBM can provide a true,
> customer-suitable TSM database reorganization function - AND a full
> rationale for engaging in such an undertaking - then such may be
> reintroduced to the documentation set.
>
> Thankfully, we have this forum to try to keep customers from getting
> into trouble when someone suggests actions which we experienced
> technicians know are just plain bad.
>
> To all the novice customers:  Get the whole story on a major
> procedure before considering undertaking it.
>
>      Richard Sims
>
> On May 17, 2006, at 7:08 AM, Kelly Lipp wrote:
>
> > Richard,
> >
> > I could not agree more on your stance regarding Dump/Load.
> > However, I'm
> > in Holland teaching a Level 2 class and have been surprised to learn
> > that a lot of my students perform this action as a matter of course on
> > their servers.  The objective is to reduce the size of aged TSM
> > databases.  In TSM 5.3 we have new functionality to determine if a db
> > reorg would reclaim a significant amount of space.  Then the Dump/load
> > is executed to get this space.  Do you suppose this new command is
> > encouraging us to do something that is high risk?  Alternatives?
> >
> > I guess they've decided the risk is worth the potential gain.
> >
> > I personally have not experience the problem so have not attempted
> > this
> > solution.