デッドロックは、複数のデータベース処理が互いのロック解除を待ち、先へ進めなくなる状態です。DBは通常、一方の処理を中断して循環待ちを解消します。SAPで「ロックにより更新できない」と表示されても、それが必ずDBデッドロックとは限りません。まずDBのデッドロックとSAPの排他ロック待ちを区別します。
最初に集める情報
- 発生日時、クライアント、ユーザー、トランザクション、ジョブ名、対象伝票・テーブル
- 画面のエラー全文、ST22のダンプ、SM37のジョブログ、必要ならSM13の更新エラー
- DB種別、同時に動いていた処理、再現頻度
DBデッドロックのログを見る
DBACOCKPIT（またはST04）から、利用DBに応じたロック・デッドロック監視を開きます。メニュー名や取得できる情報はHANA、SQL ServerなどのDBとリリースで異なります。発生時刻の記録から、競合したセッション、対象オブジェクト、実行した処理を追います。SQL Serverでは「Diagnostics → Deadlock Monitor」が使える構成があります。HANAではDBACOCKPITやHANAの監視機能を確認します。
SAPのロック待ちだった場合
SM12で対象オブジェクトのエンキューロックを確認し、保持ユーザーや時刻を調べます。ST22・SM37・SM13と突き合わせ、処理が実行中なのか異常終了したのかを判断します。ロックを機械的に削除すると処理中の整合性を損ねるため、担当者・運用手順に従って対処します。
再発防止の観点
同じデータを異なる順序で更新していないか、更新範囲が広すぎないか、コミットまでの時間が長くないか、ジョブが重複起動していないかを確認します。単発の再実行で直っても、頻発する場合は更新順序とトランザクション設計を調べます。
参考・関連記事
- ST22・SM37でエラーを調べる方法：ダンプとジョブログの見方
- ワークプロセスの種類：処理がどこで動くかを理解する
- SM50のプロセス一覧を取得する方法：実行中処理を確認する
- バグの少ないABAPプログラミングの基本：更新処理の設計を見直す
