Richard,
Is there any way can minimize the fragmentation? For example, like how
much maximum reduction size should have before the database reach a point
of no response.
Frank Tsao
[EMAIL PROTECTED]
PAX 25803, 626-302-5803
FAX 626-302-7131
Richard Sims <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
05/17/2006 05:09 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
To
ADSM-L@VM.MARIST.EDU
cc
Subject
Re: TSM 5.3.3 loaddb and audit problem
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.
