Db2が遅い

Db2が遅延する原因は様々です。トランザクションが増加したのかもしれません。SQLがロック・タイムアウトしているのかもしれません。いずれにせよ調査にあたり、遅延したときにどんなSQLが実行されていたかは知りたいです。遅いSQLがデータベース遅延の引き金であれば、そのSQLに対して対策を講じるのがあるべき姿だからです。そのためには遅いSQLを見つける必要があります。

この記事では遅いSQLを見つける方法を紹介します。

データベースの性能を評価したい方は以下の記事もご覧ください。
Db2:性能評価にSQL平均応答時間を用いる

どんなやり方があるのか

現場では以下をよく使います。

ロック・イベントモニター
db2pd
ステートメント・イベントモニター
MON_GET_PKG_CACHE_STMT 表関数
MON_CURRENT_SQL 管理ビュー

ロック・イベントモニター

デッド・ロックやロック・タイムアウトをしていないかを調べるときに使います。

データベース作成後、手動で常時有効に設定
デッド・ロックやロック・タイムアウトが発生するとDb2が自動的に情報を取得
情報はdb2evmonfmt(Javaプログラム)でテキストファイルにフォーマット
どのSQLがデッドロック、もしくはロック待ちになっているのかを詳細に出力

以下はIBMのウェブサイトです。
[DB2 LUW] ロック・イベント・モニターの設定方法

db2pd

障害がまさに発生しているときに実行、その瞬間にメモリーにある診断情報を出力します。

事前設定は必要ない
コマンドにより、診断情報を手動で出力
ロック取得状況、実行しているSQLの経過時間など詳細な情報を出力
出力ファイルが大きいので見るのが大変

db2pdやロック・タイムアウトやついて知りたい方は以下の記事もご覧ください。
勉強会:Db2問題判別ロックタイムアウトと長時間SQL

ステートメント・イベントモニター

遅延が再現できるときやピーク時間の詳細な動きを見たいときに使います。

手動で一時的に有効化
有効にしている間、全てのSQLの情報を取得できる
詳細な情報を取得できる
負荷が高く、出力ファイルも大きいので実行時間は1分、長くても3分

以下はIBMのウェブサイトです。
ステートメント・イベント・モニターによって生成されるデータ

MON_GET_PKG_CACHE_STMT 表関数

気軽に遅いSQLをチェックしたいときに使います。パッケージ・キャッシュにあるSQLを実行時間順に出力できます。

事前設定は必要ない
select文の実行でパッケージ・キャッシュに残っているSQLを出力
実行時間を降順でorder byすることで遅いSQLを識別
同じSQLはまとめられ、実行時間と回数が積算される
Where句がパラメーターマーカーではなく文字だと別のSQLと扱われる
パッケージ・キャッシュに残っているSQLしか出力されない

以下はIBMのウェブサイトです。
MON_GET_PKG_CACHE_STMT 表関数 - パッケージ・キャッシュ・ステートメント・メトリックの取得

MON_CURRENT_SQL 管理ビュー

現在実行中のSQLを表示します。**cronで定期実行、遅いSQLがあったら収集することで、後から遅かったSQLを確認することができます。**ステートメント・イベントモニターやMON_GET_PKG_CACHE_STMT 表関数がリアルタイムでの取得に向いているのとは対照的です。

事前設定は必要ない
select文の実行で現在実行中のSQLを出力
経過時間を降順でorder byすることで遅いSQLを識別
同じSQLも別々に出力
経過時間をwhere句でフィルターしたのをcronで定期収集が吉

遅いSQLを収集したい方は以下の記事もご覧ください。
Db2:後から遅いSQLを見つけたい

以下はIBMのウェブサイトです。
MON_CURRENT_SQL - 全メンバーの全アクティビティーに関する主要なメトリックの取得

まとめ

各ツールを比較しました。状況によって、使い分けています。

ツール	負荷	情報量	取得方法
ロック・イベントモニター	低い	多い	自動取得、後で確認が可能
db2pd	低い	多い	リアルタイムで手動取得が現実的
ステートメント・イベントモニター	高い	多い	リアルタイムで手動取得が現実的
MON_GET_PKG_CACHE_STMT 表関数	低い	少ない	リアルタイムで手動取得が現実的
MON_CURRENT_SQL 管理ビュー	低い	少ない	cronで自動取得、後で確認が可能