Been there......done that........read the book.......saw the
movie.............

I feel your pain.  We had the same problem and had to do this - over a
long holiday.....the non-full audit ran 4-days when the DB was only 80GB.
Now up to 160GB. I would not want to perform a full audit at this point.




"Mcnutt, Larry E." <larry.mcnutt AT TIMKEN DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/02/2008 04:21 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] Delete volume problem






We have a database corruption problem that apparently was a result of a
failed "delete volume".  We are at version 5.3.3.0.  The effects we
experience are that expiration logs a few thousand errors daily, and we
cannot run "delete file" for some defunct nodes.  The solution from TSM
support is to upgrade to at least 5.4.1.2 and then run an auditdb.  I
have verified on a test instance that this solution works, but it takes
almost 24 hours to run.  The TSM database is 70GB at 90 percent.
Looking forward to the outage in June.

Larry McNutt

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Thomas Denier
Sent: Wednesday, April 02, 2008 2:03 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Delete volume problem

We have a 5.3.4.0 TSM server running under mainframe Linux. We are
in the process of migrating some of our offsite copies to newer tape
technology. Yesterday I finished backing up all the data in one of
our primary tape pools to a new copy storage pool. This morning I
started deleting the volumes from the old copy storage pool
previously used for offsite copies of the same primary pool. The
first couple of 'delete volume' commands worked fine. The third one
was running when our automation started a snapshot database backup.
The snapshot process froze with 0 of 0 pages backed up. The 'delete
volume' process froze. A number of migration processes running at the
time stopped moving data. Node sessions went into permanent run
status and stopped moving data. I executed a 'cancel process' command
for the 'delete volume' process. It had no visible effect. A little
while later I issued a 'cancel process' command for the snapshot
process. It caused the status reported by 'query process' to change to
'Cancel pending' but otherwise had no visible effect. I finally
shut down the TSM server. I then had to wait some minutes for a
defunct dsmserv process to go away before I could restart the TSM
server.

Later in the day our automation ran an incremental database backup.
Once the backup process was safely under way I tried another 'delete
volume' command. The 'delete volume' process deleted a few hundred
files and then froze. Migration processes and node sessions stopped
moving data. The database backup continued to run until it had
written all the necessary database pages and dismounted the output
tape. It then froze. I was once again unable to cancel either the
database backup or the 'delete volume' process. I had the same
problem with a defucnt dsmserv process when I stopped the server
for the second time that day.

Are there any other TSM functions that cannot co-exist safely with
'delete volume' processes? We are preparing to upgrade our TSM
server to 5.4.2.0. Will the de facto rules about when to run
'delete volume' processes be different under this release?

-----------------------------------------
This message and any attachments are intended for the individual or
entity named above. If you are not the intended recipient, please
do not forward, copy, print, use or disclose this communication to
others; also please notify the sender by replying to this message,
and then delete it from your system. The Timken Company / The
Timken Corporation