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
