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
lipp AT storserver DOT com

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Tuesday, May 16, 2006 6:46 AM
To: ADSM-L AT VM.MARIST DOT 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