ADSM-L

Re: Database deadlock

1999-10-05 14:00:58
Subject: Re: Database deadlock
From: Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU>
Date: Tue, 5 Oct 1999 14:00:58 -0400
> What is the reclaim value for the storagepool of the volume you
> are deleting?  If it is less than 100%, maybe reclaim is trying to
> work on the volume when it is half way thru the delete.  If so, set
> the reclaim to 100% before starting the delete.

The reclaim value for the storage pool is always kept at 100%.

> You say "... every few days".  Are you deleting volumes every
> few days?  With 'discarddata=yes'?  I am curious why you
> are doing this.

We consolidate the contents of offsite copy pool volumes by deleting low
occupancy volumes and then running 'backup stgpool' commands to recopy the
files whose offsite copies were on the deleted volumes. As far as I can tell,
this approach is the best of three unsatisfactory alternatives. The other two
alternatives I am aware of are using ADSM reclamation and running 'move data'
commands for the low occupancy volumes. The trouble with ADSM reclamation is
that there is no 'wait=yes' option for it. This would make it very difficult
to integrate offsite volume consolidation into an orderly succession of ADSM
housekeeping tasks. The 'move data' command does have a 'wait=yes' option, but
it is likely to trigger a larger number of input volume mounts than the
process we are using. If two or more of the offsite tapes being consolidated
contain files from the same onsite tape, the onsite tape will be mounted two
or more times. I think the 'backup stgpool' command is designed in such a way
that no input tape is mounted more than once.
<Prev in Thread] Current Thread [Next in Thread>