DB2 for z/OSのデッドロックに関与したSQLの特定方法

デッドロックの分析に関して小さくまとまった資料があるので読んでいた。

全部を説明する気がなくなるくらいさっぱりしている。

SQLを特定するまでの話で、そのSQLの何が悪いかを扱うものではない。

著者は全部同じ人です。よし、名前覚えておこう。

これらの資料はさらりと読める分量で、実際に役に立つだろう。

APサーバー側から分析するエンジニアをいつも思うものだ、

DB側には何か情報出ていないのかと。

そういう時に、これやってくれと言えばいい。

これらをおこなう前提として

STATISTICS TRACEのCLASS 3が取られてないといけない。

厳密には2つ程度のIFCIDでいいっぽいけど、SMFに出しておこう。

動的SQLについてはDYNCACHの設定も必要。

デッドロックしたらEXPLAIN STMTCACHE ALLをすぐ取る必要がある。

さもなければいくつかのイベントにおいてステートメントが消えるからだ。

そこは自動化した方がいいという提案付きでもある。

デッドロックのついては、SYSLOGに出るメッセージを見た段階で、

静的SQLか動的SQLかの区別が出来る気がする。

いずれにしても最後はSTMT IDを元にSQL TEXTを調べる流れ。

動的SQLの場合は、STMT IDがSYSLOGから分からない。

OMEGAMON XE for DB2 Performance Expert on z/OSを使う。

LOCKING ACTIVITYを見る。

しかし動的SQLではまだSTMT-IDが分からない。

RECTRACE TRACEを流すとようやく分かる。

静的SQLと動的SQLでは格納されてるテーブルが異なるが、

まあ単純にSELECTしてSQL TEXTを見つけ出すという流れ。

欠点としては、ホスト変数までは取れないIFCIDなので、

実際の値まで調査の必要があるケースでは、

より煩雑な追加調査が必要になるようだ。

ロックエスカレーションとロックタイムアウトも良い資料だが

ここでは解説するのはやめておこうと思う。

DB2は本職じゃないんでね。

きどたかのブログ