Dwight,
Ahh yes... I had this same problem. I don't know if you use the Austin
Textsearch site, but that's where I found the answer. Anyway, if you can
afford downtime on this server, you should be able to do an offline audit of
the
"diskstorage" objects in the database. Before I did this I attempted every
possible online audit, delete, vary etc. that I could think of, to no avail.
First you want to migrate all your diskpools so that they are empty. This is
because the audit will take longer to run if there is data in them. Then halt
the server, and from the server directory run the following command:
DSMSERV AUDITDB DISKSTORAGE FIX=YES
Keep in mind that this can have a negative effect, it will delete entries in
the database if it finds inconsistencies. Obviously you and I know that they
aren't real files, because the AIX logical volumes hasn't existed for some
time, but it could be harmful. So be careful with this command.
By the way, when I used this command, it only took a few minutes of downtime,
probably because the actual diskpool volumes that still existed were empty.
And this was on a 18 Gig database, so I wouldn't expect more than 15 minutes
even for a very large one.
Good luck.
-Matt
>Ok, over the years I've had disk failures that have left disks defined i>Ok,
>over the years I've had disk failures that have left disks defined in
>storage pools that I can't get rid of !
>
>Anyone know of a sure fire way to purge these volumes from TSM ? ? ?
>
>basic problem is they are offline because they physically don't exist
>anymore, if I try to recreate them they won't define back in because it
>doesn't find something it is looking for, a move data says there is no data
>on the volume, yet a del vol blah gives a RC 13.
>
>Yes, I could open up a problem with Tivoli (we pay maint.) but if I could
/**
** Matt Bacchi mbacchi AT us.ibm DOT com
** IBM Global Services SDC Northeast
** F6TG; MD Filesystems/Internet (802) 769-4072
** ADSM & AFS/DFS Backup (tie) 446-4072
**/
|
