Db2運用者の宿命「SQL0911N」を攻略する：デッドロックとタイムアウトの正体

Db2を運用していて最も遭遇する頻度が高く、かつ厄介なエラーといえば SQL0911N です。アプリケーションのログにこの文字が躍ったとき、インフラSEやDBAとしてどう動くべきか。今回はその「処方箋」をまとめます。

1. SQL0911N の正体：理由コードを読み解く

SQL0911N は、大きく分けて2つのパターンがあります。メッセージ末尾の Reason Code を確認してください。

• Reason Code 2：デッドロック
  2つ以上のトランザクションがお互いのロック解除を待ち合い、身動きが取れなくなった状態。Db2が強制的に片方をロールバックさせます。
• Reason Code 68：ロック・タイムアウト
  誰かが資源を掴んだまま離さず、待機時間が上限（LOCKTIMEOUT）を超えた状態です。

2. 【実践】SQL0911N (RC 68) を再現させる

理解を深めるために、あえてロック・タイムアウトを発生させてみましょう。ターミナル（db2bp）を2つ用意します。

準備：タイムアウト時間を5秒に設定

再現手順

この手順は Db2 標準の SAMPLE データベースにある STAFF テーブルを使用しています

【ターミナル A：更新担当】          【ターミナル B：参照担当】
--------------------------          --------------------------
$ db2 +c "UPDATE STAFF              
  SET SALARY = 10000 
  WHERE ID = 10"
(未コミットのまま放置)

                                    $ db2 "SELECT * FROM STAFF 
                                      WHERE ID = 10"

                                    ... 5秒間、応答が止まる ...

                                    SQL0911N  The current transaction 
                                    has been rolled back because of 
                                    a deadlock or timeout. 
                                    Reason code "68".
    

※ `+c` オプションは自動コミットをオフにします。

3. 現場で使える 3 つの処方箋

① 現在コミット済み (CUR_COMMIT) の活用

Db2 V9.7以降の強力な機能です。書き込み中のデータがあっても、待たされる代わりに「直前の確定データ」を読みに行きます。

② 適切な LOCKTIMEOUT の設定

システム特性に合わせて 30秒〜60秒 程度に設定し、アプリケーション側で「リトライ処理」を実装するのがSEの定石です。

③ db2pd コマンドによる犯人の特定

「今まさに待たされている」状況なら、以下のコマンドで犯人を特定できます。

出力結果の `TranHdl` を追いかけることで、どのアプリケーション・ハンドルがロックを握りつぶしているかが見えてきます。

5. まとめ