Hmmm... I have to question the FIX=NO part, as that will only search for
inconsistencies; it won't fix them. You should clarify with the engineer
who answered your question, as there might be a typo.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-08-18
08:01:22:
>
> Yesterday I posted to the list about an error message that was
> generating when our TSM Server came back on-line after an upgrade to
> 5.2.2. Those error messages were causing other error messages
> during the Expiration process and seemed to be slowing down the
> Expiration process (my hope is that getting rid of these errors will
> solve the slow-down problem of the Expiration process...I won't be
> sure however until I get rid of the messages :~)
> We opened an ETR with IBM yesterday afternoon and there was
> already a response when I came in this morning. Someone expressed
> interest in the solution if we found one so I will post an edited
> version of IBM's response. Because our TSM Server is on an MVS/ZOS
> mainframe, some things are done differently than other platforms but
> the gist of it is the same.
>
> The error messages are the result of a corrupt entry in the TSM
> Server database. The ANR9999D's callchain indicates that the TSM
> server's migration thread is working to try and calculate space in
> the tapepool to run a disk to tape migration. In that process, the
> TSM server must access the AF.Custers table. It is in this table
> that there is an orphaned entry causing the error messages to be
> logged in the activity log.
>
> To fix the problem, you will have to remove the orphaned entry. The
> way to do this is with audit of the TSM server's database. This is
> an off-line process, during which the TSM server is down.
>
> In short run an
>
> AUDITDB ARCHSTORAGE FIX=NO
>
> Once the process is complete, restart the server normally.
>
> I'm scheduling time to do this today, I have a regularly scheduled
> Expiration process done on Fridays? before each weekend. I will
> post the results on the list?. and if it really was affecting the
> Expiration process time.
>
> As always,
> Thank You
> Shannon
>
>
>
>
>
>
> Madison Gas & Electric Co
> Operations Analyst -Data Center Services
> Information Management Systems
> sbach AT mge DOT com
|
