Glen, your points are sound.
I still see it more differentiated.
I run 4 ~ years ago an audit just on occasion,
just as Ralph wants to.
It found a sleeping inconsistency.
This resulted in more and more work, in an opened PMR,
even in sending a DB dump to the tivoli labors
... only to figure out my hardware was faulty
and I had to replace it.
In detail, both the interrupt controller on motherboard
and raid controller had occasionaly problems
to handle shared interrupts, causing scsi disk writes
to write wrong data(!) to disks. Raid5 was of no help.
This error happend only once a week or so, causing faulty DB writes
to happen maybe quarterly.....
Needles to say, few files in disk storage pools had bit failures as well.
And yes, the server and all componets used
were suposed to be of high quality.
Well, this is like like an anti-LOTTO first price win,
(LOTTO known in US? you win if 5 correct guessed from 45)
but still I cannot be the only who had had such problems -
think about CRC options added some times later to TSM.
So If one can afford time to do an audit, maybe with fix=no,
it will do no harm at all (except for irritating mirriads of mirriads of
elektrons)
and make him know everything is OK.
This is my personal experience -
there is difference between believeing
everythyng is OK and between knowing it.
Maybe weird? I do not carry.
Juraj Salak
-----Ursprüngliche Nachricht-----
Von: Glen Hattrup [mailto:ghattrup AT US.IBM DOT COM]
Gesendet: Dienstag, 02. März 2004 18:10
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Re: AW: TSM DB cleanup
Ralph,
Without knowing why or what your exact concerns are with the TSM database,
it is hard to give you generic advice to follow.
Unless you are experiencing internal errors, diagnostic messages, or other
oddities that clearly indicate there is something wrong with your TSM
server, you do NOT need to do anything specific to 'verify' the database
before upgrading your system.
An Unload / Load would only reorganize your database. It does not 'clean'
your database or verify that your database is 'clean'. The Unload / Load
process has more of an effect on performance than space allocation. Search
the list archives and you'll find differing opinions regarding short and
long term benefit of an unload / load process. I don't think it's needed
in your case.
Please do NOT audit your database as was suggested below. Depending upon
the size of your database, you may end up wasting a significant amount of
time (days, weeks?). DB Audit is a 'computationally intensive' process
(to put it mildly) and it is not clear that you'll see any benefit from
doing so. There are very few cases where the blanket response of "audit
your database" is appropriate.
There are some known problems during upgrade from 4.2.x that depend upon
your system and backup environment. The monthly FAQ posts answers to the
general "how do I upgrade" question, and the list archive is another
excellent source to search. Always read the README's, and always take a
full database backup before upgrading your TSM environment.
Glen Hattrup
IBM - Tivoli Systems
Tivoli Storage Manager
Salak Juraj <j.salak AT ASAMER DOT AT>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
03/02/2004 09:44 AM
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
AW: TSM DB cleanup
1) halt
2) dsmserv auditb
regards
juraj
-----Ursprüngliche Nachricht-----
Von: Levi, Ralph [mailto:RLevi AT HESS DOT COM]
Gesendet: Dienstag, 02. März 2004 16:09
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: TSM DB cleanup
I am running TSM 4.2.1 (upgrading in a month after our next disaster
recovery test) and noticed that our DB is now 95% full. I don't want to
have to expand it before the upgrade. Is there a utility that can be
run to make sure it is "clean" ?
Thanks,
Ralph
|
