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. Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Tuesday, May 16, 2006 6:46 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM 5.3.3 loaddb and audit problem Do not take any further actions on your own: call TSM Support and engage them in the problem. You risk doing further damage to your database if you continue tinkering with it, as we have and IBM have stressed in the past. It seems this needs to be stressed again: DO NOT ELECTIVELY RUN UNLOADDB - LOADDB ON YOUR TSM DATABASE!! These are *salvage* utilities. The ADSM-L archived chronicle the horror stories of customers who have followed mis-advice and proceeded to perform "compress" on their TSM database. If you need corroboration on this, review the APARs on these utilities. Such software does not receive a lot of attention from developers, who are pressed to work on new features rather than old, lesser-used utilities like these. And there are no long-term gains in reorganizing your TSM database: it's a lot of risk and no real gain. We've seen too many customers in pain because of this stuff, and I don't want to see any more. Richard Sims On May 16, 2006, at 8:09 AM, Abdulaziz Almuammar wrote: > Dear All, > we did unloaddb and loaddb but after the loaddb we faced a problem on > the backup of the nodes and it was resolved by upgrading TSM server > from 5.3.2 to 5.3.3. > However, we are facing a problem on some nodes when we do restore, > some files could ot be restored and we got a message that those files > are not available on the TSM server :( although all volumes with > "readwrite" access status > > > to make sure that the TSM db information is synced we have to run the > auditdb but the problem with this is it takes a long time to do it and > it is offline proccess > > Is there another way to make sure that the database information is > correct? > Is audit volume command on the storagepool level ( All volumes) will > do the same job as auditdb? although it takes a long time but atleast > the TSM server is up > > > > Regards, > Abdul
