Hi, Andy -
I realize that you and I are "interested parties" in what is a server-
area topic, removed from our direct, respective realms.
And thanks for reinforcing the cautions which should be in place in
approaching this type of operation.
The product documentation started "blithely" enticing customers to
start reorganizing their databases in the TSM 5.x Technical Guide,
which introduced the ability to do this as though customers had been
deprived of it in the past, and letting the reader infer that it
should be a regular part of their regimen. (Here the redbook was very
disappointing, in that the Technical Guide has been a source of why-
and-how insights.) Then there was the 5.1 Admin Guide, which lead off
the topic with:
"Over time, database volumes become fragmented. You can restore the
efficiency of
the database and improve database performance by reorganizing the
database
using database unload and reload processing. By reloading the
database, you
compress and reorganize it."
Which was accompanied by terse instructions on how to do it, with no
advisory on risks, how long the TSM server outage would be, what to
look for at any stage, or what to do if there were problems. My jaw
dropped when I saw that in the manual. I was just astonished that IBM
would just plop it down like that. This is what I mean by "blithely".
It's like handling a child a knife: shiny, enticing, with great
inherent dangers.
The TSM 5.3 Admin Guide is no better. It continues to encourage the
practice, with no substantive perspective on when or why it should be
done (and I mean in real database terms), no perspective on whether
any positive effects will endure long enough to have made the effort
worthwhile, no information on risks, no information on messages to
expect or their significance relative to the operation, and no
guidance for when things go wrong.
No customer should be given a facility like this without benefit of
full insight into what's involved, and there IBM has withheld all the
vital information needed to make an informed decision. An enterprise
customer who is left to contemplate operating on the core of his
corporations recoverability - the TSM database - needs substantive
information on what this is all about. The Admin Guide provides
enticement rather than substance; the ESTimate DBREorgstats command
doc provides no perspectives; and the TSM Performance Tuning Guide,
where one would expect to find in-depth perspectives, has no
information on db fragmentation or reorganization. What little info
is provided anywhere just mentions space reclamation, with no
perspective on Insert performance, structural ramifications, or any
other factors. This is poor.
And, again, the old physical unload-reload utilities are simply the
wrong suite of tools to be given to customers to perform this task -
if it should be performed at all.
I remain very angry with IBM having introduced this capability in
this form of software, and with wholly inadequate documentation. The
long-experienced TSMers have perspective on what the dangers are; but
this is being put in front of naive TSM customers, who don't have
that perspective, and who we know from experience end up with an
unusable TSM system because of it.
In all this, I'm not trying to protect myself: I know better. I'm
trying to protect the kid who finds the shiny knife.
Again, thanks for your authoritative advisories to customers in this
matter. I know you're trying to help. It's the server people who made
the poor decisions who need to address and fix this.
Richard Sims
