Re: Database deadlock
1999-10-04 17:10:32
Tom,
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.
You say "... every few days". Are you deleting volumes every
few days? With 'discarddata=yes'? I am curious why you
are doing this.
--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <H000132102f90b83@MHS>, on 10/04/99
In <H000132102f90b83@MHS>, on 10/04/99
at 04:39 PM, Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU> said:
>I have been seeing sequences of messages similar to the following every few
>days:
>10/01/1999 15:17:29 ANR0390W A server database deadlock situation has been
> encountered: lock request for transaction 0:5336084 will
> be denied to resolve the deadlock.
>10/01/1999 15:17:29 ANR9999D ASUTIL(706): Lock acquisition (ixLock) failed
> for volume root.
>10/01/1999 15:17:29 ANR1181E ASTXN348: Data storage transaction 0:5336084 was
> aborted.
>10/01/1999 15:17:29 ANR2183W ADMDVOL1807: Transaction 0:5336084 was aborted.
>10/01/1999 15:17:29 ANR1160W Transaction was aborted for volume 600052.
>10/01/1999 15:17:29 ANR0986I Process 227 for DELETE VOLUME (DISCARD DATA)
> running in the FOREGROUND processed 179 items for a
> total of 12,172,611 bytes with a completion state of
> FAILURE at 15:17:29.
>As far as I can tell, there were no node sessions in progress when the failure
>occurred, and no administrative processes other than process 227 itself. I
>find it difficult to imagine why ADSM would have any trouble with database
>contention under those circumstances. We are running a 3.1.2.20 server under
>MVS. Does anyone recognize this as a know problem?
|
|
|