DB2 ロッキングの問題
ナビゲーションに移動
検索に移動
目次
DB2 ロッキングの問題
発生する主なロッキング問題
ロック待機、タイムアウト
- ロック要求は、タイムアウト期間を超えるか、またはデッドロックが発生するまで、待機アプリケーションに対して保留
- locktimeout データベース・パラメーター (秒単位) を使用して、ロックが使用可能になるのをアプリケーションが待機する期間の長さを構成
- タイムアウト期間を超えた場合、待機アプリケーションは戻りコード 68 を伴う SQL0911 エラー・メッセージを受け取りロールバック
- locktimeout のデフォルト値は -1 で、これによりロック・タイムアウトは使用不可(永久に、またはロックが解除されるまで待機し続けます)
エスカレーション
2 つの異なるシナリオで発生
- 単一アプリケーションが、許可されるロック数を超えるロックを要求
- システム上でのデータベース・ロックの最大数を超えたため、アプリケーションがロック・エスカレーションをトリガー
<blockquote>データベース・マネージャーが、表ロックを取得し、既存の行ロックを解除することによって、ロッキングに割り振られたメモリーを解放しようと試みます。望ましい効果は、追加のアプリケーションがより多くのロック・メモリーを使用できるようにする</blockquote>
- locklist- 並行してデータベースに接続されているすべてのアプリケーションが保持する、すべてのロックのリストを保持するために割り振られるストレージの量 (4k ページの単位)。
- maxlocks- 単一アプリケーションが使用できるロック・リストの許容可能なパーセンテージ。
ロック・エスカレーション問題の解決
以下の情報を、管理通知ログから収集
- 現在保持されているロックの数
- ロック・エスカレーションが完了する前に必要なロックの数
- 現在保持されている非表ロックの数
- エスカレーションの一部として獲得される新しい表レベルのロック。通常、S または X ロックが獲得
- 新しい表レベル・ロックの獲得に関連付けられた内部戻りコード
管理通知ログの情報を使用し、エスカレーション問題の解決方法を決定
- maxlocks または locklist データベース構成パラメーター (あるいはその両方) を確認または調整
- RR、RS、CS、または UR などの、アプリケーションおよび SQL ステートメントが実行中の場合の分離レベルを考慮
- アプリケーションでのコミットの頻度を増やす
- アプリケーションを変更し、LOCK TABLE ステートメントを使用して、表ロックを取得
デッドロック
デッドロックが検出されると、デッドロック検出機能は、自動的にロールバックされ戻りコード 2 を伴う SQL0911 sql コードが出されるビクティム (犠牲となる作業単位) を選択します。ビクティムをロールバックすることにより、ロックの競合が除去され、他のアプリケーションは処理を続行
<blockquote>SQLコード -911 の場合、理由コード 2 ならデッドロック、68ならタイムアウト</blockquote>
ロックエスカレーション
突然ロックタイムアウトやデッドロックが多発
まずはロック・エスカレーション を疑ってみましょう。DB2はデフォルトでは行ロックですが、ロック用のメモリー(LOCKLIST )が全体として不足したり、ロック用のメモリー(LOCKLIST)を1トランザクションで所定量(MAXLOCKS) 以上使うと、ロックの量を減らすために自動的に表ロックになります。表ロックになると並行度が下がり他の処理が待たされたりデッドロックが起きやすくなります。
- ログを確認
db2diag -g db=[DBNAME]
- 例
2008-04-XX-00.00.29.617870+540 E413519E589 LEVEL: Warning PID : 3707 TID : 47070471776608PROC : db2sysc INSTANCE: db2inst1 NODE : 000 DB : XXXDB APPHDL : 0-44235 APPID: *LOCAL.db2inst1.080424212730 AUTHID : DB2INST1 EDUID : 36147 EDUNAME: db2agent (XXXDB) FUNCTION: DB2 UDB, data management, sqldEscalateLocks, probe:2 MESSAGE : ADM5500W DB2 is performing lock escalation. The total number of locks currently held is "212121", and the target number of locks to hold is "106060".
診断と解釈
© 2006 矢木浩人
