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