>
> UNDOCUMENTED OPTIONS FOR EXPIRE INVENTORY:
> There are two undocumented/unsupported options for EXPIRE INV;
> BEGINNODEID and ENDNODEID.
>
> These accept the decimal node number of a node and can be used to
> expire a specific node's filespaces, or a specific range.
>
>
>
> WHY WOULD YOU EVER WANT TO USE THESE?
> EXPIRE INV won't check for filespace lock before parsing a filespace.
>
We are currently using the CLEANUP EXPTABLE cmd with
the BEGINNODEID/ENDNODEID options . . . . . . UNDER THE
DIRECTION OF TSM SUPPORT.
We are on TSM V5.3.2. Back when we were V5.1 (last year),
we were getting ANR9999 messages that prevented us from deleted
old nodes out of TSM. We did bunches of stuff with support, but
the fix was to move to v5.3. This we were planning, and did.
As part of migrating to v5.3 we ran the cleanup procedure for Win
system objects. After upgrading we still couldn't delete the nodes
out of TSM. The solution was to run the CLEANUP EXPTABLE command.
We did this on our test system for each of our production databases.
Once started, this command cannot be stopped without halting the TSM
server.
Running it against a production DB on our test server ran well over 2
weeks for one TSM server, and just about 2 weeks for our other TSM server.
After running, we were able to delete the nodes.
Ok, now we are told by the support center to run it on
production. Remember . . . . you cannot run expiration while this is
running. We told them we could not go without expiration for that long,
and
we can't just halt our TSM server at anytime to stop it!!!!!!
The answer was to get the NODEID's for all the nodes and run CLEANUP
EXPTABLE for one
node at a time using the BEGINNODEID/ENDNODEID. We tried this on one
node . . . it worked, but we have well over 500 nodes on each TSM server.
I've writtes a script that automatically works through a file of nodeid's.
After each node is cleaned up, it runs expiration for some amount of
time. The longer the cleanup runs, the longer expiration runs.
I run this script Monday thru Friday, cleaning up one node at a time with
some normal expiration between each cleanup. On
the weekend I put our normal expiration processing back in place to get
a couple good full expiration runs.
It took several months to work through the first TSM server. If I
understand the output of the command, it fixed almost 15 million
errors on this TSM server. The 2nd TSM server has been going
through this process since Feb 1st is finally getting close to
finishing - it's processed 509 out of 526 nodes.
Anyway, this is one reason to use these options.
If anyone has a similar problem, I would be happy to send them this script
(ksh). It's
highly specific to our environment, but could be adapted easily.
rick
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
|
