例: 変更履歴イベント・モニターを使用したロック・エスカレーションの増加の調査
変更履歴イベント・モニターを使用して、 データベースのパフォーマンスの低下を引き起こした可能性がある変更を突きとめることができます。
シナリオ
この例では、データベースのパフォーマンスが低下したとユーザーが報告しています。 データベース管理者 (DBA) は、この 24 時間に発生したロック・エスカレーションの数が異常に多いことに気が付きました。 また、DBA は、この同じ期間内のアプリケーション・ロック待機時間にも、類似した増加が見られることに気が付きました。DBA は、変更履歴イベント・モニターを使用して、構成変更、索引変更、および LOAD 操作のモニターを行っています。
このイベント・モニターは、以下のステートメントを使用して作成しました。
CREATE EVENT MONITOR CFGHIST
FOR CHANGE HISTORY WHERE EVENT IN (DBCFG, DBMCFG, DBCFGVALUES,
DBMCFGVALUES,REGVAR,REGVARVALUES, DDLDATA, LOAD)
WRITE TO TABLEこのイベント・モニターを活動化するために使用したステートメントは以下のとおりです。
SET EVENT MONITOR CFGHIST STATE=1以下の表に、
CFGHIST 変更履歴イベント・モニターが表 CHANGESUMMARY_CFGHIST に書き込む可能性があるイベント・モニター・データの例を示します。
すべての変更履歴イベント・モニターは、CHANGESUMMARY 論理データ・グループに書き込みます。
『CHANGESUMMARY 論理データ・グループ
』で説明しているように、CHANGESUMMARY 論理データ・グループは、キャプチャーされたイベントを要約したいくつかのイベント・モニター・エレメントを戻します。以下の出力は、それらのエレメントのサブセットのみを示しています。表の名前は、表 (CHANGESUMMARY) にデータを設定するために使用された論理データ・グループの名前と、CREATE EVENT MONITOR ステートメント (CFGHIST) でイベント・モニターに指定された名前とを連結することによって導出されます。
APPL_ID APPL_NAME .... EVENT_ID EVENT_TIMESTAMP
---------------------------- --------- .... -------- -------------------
*LOCAL.tripathy.111028110756 db2bp .... 1 28/10/2011 07:12:02
EVENT_TYPE MEMBER ....
---------- ------ ....
EVMONSTART 0 .... これまでパフォーマンスに問題はなかったため、
DBA は、最近行われた何らかの変更によって問題が生じているのではないかと考え、
以下の手順を実行しました。
- この 24 時間に行われた変更がないか、CHANGESUMMARY 論理データ・グループを確認しました。
この例では、現在時刻は 2011/10/31 06:00:00 だとします。
この照会は、以下の結果を返します。SELECT EVENT_TYPE FROM CHANGESUMMARY_CFGHIST WHERE EVENT_TIMESTAMP > CURRENT TIMESTAMP - 24 HOURS
出力に、この 24 時間にデータベース構成の更新が 2 回あったことが示されます。EVENT_TYPE ---------- DBCFG DBCFG - DBDBMCFG 論理データ・グループを照会して、それらの構成変更の詳細情報を取得しました。
この照会は、以下の結果を返します。SELECT EVENT_TIMESTAMP, CFG_NAME, CFG_VALUE, CFG_OLD_VALUE, DB_DEFERRED FROM DBDBMCFG_CHGHIST
出力に、 パフォーマンスが低下した期間内にロッキングの変更が行われたことが示されています。EVENT_TIMESTAMP CFG_NAME CFG_VALUE CFG_OLD_VALUE DB_DEFERRED ------------------- ----------- --------- ------------- ----------- 30/10/2011 08:41:39 LOCKLIST 1024 2048 N 30/10/2011 08:42:35 LOCKTIMEOUT 0 -1 Y
DBA は、LOCKTIMEOUT 変更が据え置かれたことに気が付き、
この構成変更の後にデータベースが活動化されたかどうかを確認するための照会を実行しました。
この確認により、構成変更がデータベースに反映されたかどうかが分かります。
変更が反映されていなかったのであれば、
その変更がパフォーマンス問題の原因である可能性はなくなります。
データベースの活動化時刻は、EVMONSTART 論理データ・グループに記録されています。
すべての変更履歴イベント・モニターは、デフォルトでは EVMONSTART 論理データ・グループに書き込みます。
SELECT COUNT (*)as POST_CFG_ACTIVATIONS FROM EVMONSTART_CHGHIST
WHERE DB_CONN_TIME > TIMESTAMP(2011-10-30-08:42:35)照会を実行すると、
ゼロ以外の値が戻されました。 POST_CFG_ACTIVATIONS
--------------------
1このゼロ以外の値により、
LOCKTIMEOUT 構成パラメーターの変更後にデータベースが活動化されたことが確認できました。つまり、新しい値は有効になっています。
これで、システム上で何が変更されたかが明らかになり、DBA は、ロック関連の構成パラメーターを元の値に戻して、問題が解決するかどうかを試すことができます。
注: 構成パラメーターの変更時に変更履歴イベント・モニターが非アクティブであった場合、
変更履歴イベント・モニターはその DBCFG イベントをキャプチャーしません。
その代わり、変更履歴イベント・モニターは、開始されたときに DBCFGVALUES イベントをキャプチャーします。
DBDBMCFG 論理データ・グループの各行は、
DBCFG または DBMCFG イベントの一環として更新された構成パラメーター、または、
DBCFGVALUES または DBMCFGVALUES イベントの一環としてイベント・モニターの開始時にキャプチャーされた構成パラメーターを表します。
CFG_COLLECTION_TYPE モニター・エレメントは、
レコードの内容が、構成パラメーターの更新に関するものか、
あるいはイベント・モニターの開始時に記録された初期値に関するものかを示します。DBA は、
問題を引き起こした可能性がある変更値を探すときには、
現行の変更履歴イベント・モニターの開始時にキャプチャーされた値と、
その前にキャプチャーされた値とを比較する必要があります。
診断ログを調べることも有用です。