AuditDB diskstorage does tend to run more quickly than other flavors of
auditDB. The majority of the DB size is in the archstorage area (tape for most
people) not the diskstorage.
A word of caution - always take a full DB backup before performing an AuditDB
procedure. You may not like the results of the AuditDB and you may need to be
able to regress its effects. If nothing else, it's just good practice.
Dwight - given that you pay for maintenance, you would probably be better off
having a record open with TSM support. Open the record, get the background
information on AuditDB, take your DB Backup!, and the run the audit.
Glen Smith.
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:
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 in
>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
**/
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup
|
