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:[EMAIL PROTECTED] Gesendet: Dienstag, 02. M�rz 2004 18:10 An: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/02/2004 09:44 AM Please respond to "ADSM: Dist Stor Manager" To [EMAIL PROTECTED] cc Subject AW: TSM DB cleanup 1) halt 2) dsmserv auditb regards juraj -----Urspr�ngliche Nachricht----- Von: Levi, Ralph [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 02. M�rz 2004 16:09 An: [EMAIL PROTECTED] 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
