ロックのエスカレーションとデッドロックの関連


パイロットのロードランナーでの負荷テスト実行時に発生したデッドロックの原因は
ロックのエスカレーションが直接の原因だった。


DB2サーバks144の

/db2/n001/sys0/db2dump/ディレクトリ下
/db2/n001/sys1/db2dump/ディレクトリ下

にDB2サーバ側のログが吐き出される。


db2diag.log
pn00z01d.nfy

にイベントが刻まれる。


デッドロックが発生した時刻に

ADM7513W  データベース・マネージャーが開始されました。
^^
2003-06-17-18.53.36.890944   Instance:pn5xz01d   Node:000
PID:29653(db2agent (PN5XZ01D) 0)   TID:1   Appid:GA5B988D.BA3D.035BE7095155
data management  sqldEscalateLocks Probe:2   Database:PN5XZ01D

ADM5500W  DB2 は、ロック・エスカレーションを実行しています。
現在保留されているロックの合計数は "253" で、保留するロックのターゲット数は
"126" です。
^^
2003-06-17-18.53.44.834357   Instance:pn5xz01d   Node:000
PID:29653(db2agent (PN5XZ01D) 0)   TID:1   Appid:GA5B988D.BA3D.035BE7095155
data management  sqldEscalateLocks Probe:3   Database:PN5XZ01D

ADM5502W  ロック・インテント "S" に対する、表 "PN5XZ01D.PARTITION_TENKEN" での
"245" ロックのエスカレーションは成功しました。
^^
2003-06-17-18.53.45.249827   Instance:pn5xz01d   Node:000
PID:27772(db2agent (PN5XZ01D) 0)   TID:1   Appid:GA5B988E.F017.06A017094619
data management  sqldEscalateLocks Probe:2   Database:PN5XZ01D

ADM5500W  DB2 は、ロック・エスカレーションを実行しています。
現在保留されているロックの合計数は "340" で、保留するロックのターゲット数は
"170" です。
^^
2003-06-17-18.53.45.271638   Instance:pn5xz01d   Node:000
PID:27772(db2agent (PN5XZ01D) 0)   TID:1   Appid:GA5B988E.F017.06A017094619
data management  sqldEscalateLocks Probe:3   Database:PN5XZ01D

ADM5502W  ロック・インテント "S" に対する、表 "PN5XZ01D.PARTITION_TENKEN" での
"317" ロックのエスカレーションは成功しました。
^^
2003-06-17-18.53.45.254032   Instance:pn5xz01d   Node:000
PID:21037(db2agent (PN5XZ01D) 0)   TID:1   Appid:GA5B988D.B966.035CE7094618
data management  sqldEscalateLocks Probe:2   Database:PN5XZ01D

ADM5500W  DB2 は、ロック・エスカレーションを実行しています。
現在保留されているロックの合計数は "353" で、保留するロックのターゲット数は
"176" です。
^^
2003-06-17-18.53.45.780871   Instance:pn5xz01d   Node:000
PID:21037(db2agent (PN5XZ01D) 0)   TID:1   Appid:GA5B988D.B966.035CE7094618
data management  sqldEscalateLocks Probe:3   Database:PN5XZ01D



のような警告が出力されていた。


この対応方法として、

1.アプリケーションがコミットをするように修正する。
2.サーバ側の設定値のロックパラメータの数を増やす。locklistとmaxlocks

がある。

大きな処理をコミットしないで行うと
DB2がロックに使うリソースが足りなくなり
DB2はロックを行ロックから表のロックにエスカレートさせる。

結果としてデッドロックが多発する。





以下は参考まで。


http://dbforums.com/t737723.html



From: Tim.D     
Date: 03-28-03 18:40
Subject: Excessive Locks    

--------------------------------------------------------------------------------
People,

I'm getting the following message warnings in the Event Viewer and
wondered if this is a problem or not.

ADM5502W The escalation of "2034" locks on table "SYSIBM 
.SYSCOLDIST" to lock
intent "X" was successful.

ADM5502W The escalation of "5525" locks on table "DB2ADMIN.TEST1" to
lock
intent "X" was successful.

ADM5500W DB2 is performing lock escalation. The total number of
locks
currently held is "5536", and the target number of locks to hold is
"2768".

Is there anything I should be doing to prevent this ?

Many thanks,

Tim.D

edit post 
 
  
 From: Anton Versteeg     
Date: 03-31-03 09:21
Subject: Re: Excessive Locks    

--------------------------------------------------------------------------------
1. investigate the application that is causing this, if possible do more
often a COMMIT.
2. Increase the lock parameters: locklist and maxlocks.

"Tim.D" wrote:

1.この警告の原因になっているアプリケーションを探して、可能ならばもっとコミットをするように修正する。

2.ロックパラメータの数を増やす。locklistとmaxlocks


  > People,
  > I'm getting the following message warnings in the Event Viewer and
  > wondered if this is a problem or not.
  > ADM5502W The escalation of "2034" locks on table "SYSIBM
  > .SYSCOLDIST" to lock
  > intent "X" was successful.
  > ADM5502W The escalation of "5525" locks on table "DB2ADMIN.TEST1" to
  > lock
  > intent "X" was successful.
  > ADM5500W DB2 is performing lock escalation. The total number of
  > locks
  > currently held is "5536", and the target number of locks to hold is
  > "2768".
  > Is there anything I should be doing to prevent this ?
  > Many thanks,
  > Tim.D

--
Anton Versteeg
IBM Netherlands

edit post 
 
  
 From: Knut Stolze     
Date: 03-31-03 10:24
Subject: Re: Excessive Locks    

--------------------------------------------------------------------------------
Anton Versteeg wrote on Monday 31 March 2003 11:21:

  > 1. investigate the application that is causing this, if possible do more
  > often a COMMIT.
  > 2. Increase the lock parameters: locklist and maxlocks.

3. Using a different isolation level if that's possible.

3.可能ならば別の分離レベルを設定する。


-- 
Knut Stolze
Information Integration
IBM Germany / University of Jena

edit post 
 
  
 From: Ian D. Bjorhovde     
Date: 04-02-03 15:34
Subject: Re: Excessive Locks    

--------------------------------------------------------------------------------
Tim.D wrote:
  > People,
  > 
  > I'm getting the following message warnings in the Event Viewer and
  > wondered if this is a problem or not.
  > 
  > ADM5502W The escalation of "2034" locks on table "SYSIBM 
  > .SYSCOLDIST" to lock
  > intent "X" was successful.
  > 
  > ADM5502W The escalation of "5525" locks on table "DB2ADMIN.TEST1" to
  > lock
  > intent "X" was successful.
  > 
  > ADM5500W DB2 is performing lock escalation. The total number of
  > locks
  > currently held is "5536", and the target number of locks to hold is
  > "2768".
  > 
  > Is there anything I should be doing to prevent this ?

Lock escalation can cause problems (including deadlocks), so you should
research the cause of this. Usually the solution to this issue is making
your applications commit more frequently (i.e., smaller units of work).

You can help prevent or perhaps even stop this by updating the database
config parameters LOCKLIST and MAXLOCKS.

ロックのエスカレーションは(デッドロックを含む)問題を起こす。
この原因を調べるべき。

通常、この問題の解決策はアプリケーションでもっとコミットを増やすことである。
(例えばユニットオブワークの範囲を小さくするのである。)

この問題はLOCKLIST と MAXLOCKS設定パラメータを増加することで防いだり、
多分起きないようにすることができる。






-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

edit post 
 
  
 From: Pm \     
Date: 04-02-03 18:38
Subject: Re: Excessive Locks    

--------------------------------------------------------------------------------
X on SYSIBM.* looks like a runstats or reorg statement to me...
ADM5502W is just a warning.
Performance degradation issue only. It takes time to convert the row locks
to a single table lock.

In addition to what other posters said, you could also look at
reorg concurrency options, etc. (if the related statement is in fact a
reorg, etc.)

PM
 

2003/06/19 ugya@lycos.com