ロック・イベントおよびデッドロック・イベントのモニター

大規模な DB2® 環境内での ロック競合状態の診断および修正は、複雑で時間がかかる作業となる場合があります。 ロック・イベント・モニターは、 ロック・データを収集してこの作業を単純化するように設計されています。

注: デッドロック・イベント・モニターは推奨されなくなり、 このイベント・モニターが提供していた機能は、ロック・イベント・モニターに統合されました。 また、DB2DETAILDEADLOCK イベント・モニターも推奨されなくなりました。 推奨されないロック・モニター機能を参照して、 このイベント・モニターの使用に関する重要な情報を確認してください。

ロック・イベント・モニターは、ロック・イベントの発生時に、それらのロック・イベントに関する説明情報をキャプチャーするために使用します。 キャプチャーされた情報により、ロック・イベントの原因となっているロック競合に関係した主要なアプリケーションを識別できます。 ロック・リクエスター (デッドロックまたはロック・タイムアウト・エラーを受け取ったアプリケーション、または指定された期間を超えてロックを待機したアプリケーション)、および現在のロック所有者の両方についての情報がキャプチャーされます。

ロック・イベント・モニターにより収集された情報は、 データベース内の未フォーマット・イベント表にバイナリー・フォーマットで書き込めます。 この場合、キャプチャーされたデータは、キャプチャーの後工程で処理する必要があります。 代わりに、通常の表のセットに ロック・イベント情報を書き込むこともできます。最も適切な出力形式を選択する方法の詳細については、イベント・モニターの出力オプションを参照してください。

動的または静的 SQL のいずれかを使用して、ロック・イベント情報を収集するために、DB2 リレーショナル・モニター・インターフェース (表関数) に直接アクセスすることもできます。

デッドロックまたはロック・タイムアウトが発生しているかどうかの判別も、単純化されています。 これらのイベントのいずれかが発生している場合、メッセージが管理通知ログに書き込まれます。これはアプリケーションに返される SQL0911N (sqlcode -911) エラーの補足となります。 加えて、ロック・エスカレーションの通知も管理通知ログに書き込まれます。この情報は、ロック表のサイズおよびアプリケーションが使用できる表の量の調整に役立てることができます。 ロック・タイムアウト (lock_timeouts)、ロック待機 (lock_waits)、およびデッドロック (deadlocks) のカウンターもあり、これらを調べることもできます。

ロック・データのキャプチャーの対象にできるアクティビティーのタイプには、以下があります。
  • SQL ステートメント。例えば以下のようなものがあります。
    • DML
    • DDL
    • CALL
  • LOAD コマンド
  • REORG コマンド
  • BACKUP DATABASE コマンド
  • ユーティリティー要求

ロック・イベント・モニターは、非推奨のデッドロック・イベント・モニター (CREATE EVENT MONITOR FOR DEADLOCKS ステートメントおよび DB2DETAILDEADLOCK)、および非推奨のロック・タイムアウト・レポート機能 (DB2_CAPTURE_LOCKTIMEOUT レジストリー変数) を、ロック・イベント・データ収集用の単純化されて一貫性があるインターフェースで置き換え、ロック待機に関するデータをキャプチャーする機能を追加します。

機能の概要

ロック・イベント・モニターを使用してロック・イベント・データをキャプチャーできるようにするには、以下の 2 つのステップが必要です。
  1. CREATE EVENT MONITOR FOR LOCKING ステートメントを使用して LOCK EVENT モニターを作成する必要があります。 モニターの名前を入力する他、出力形式として UE 表を使用する場合は、ロック・イベント・データが書き込まれる未フォーマット・イベント表の名前も入力します。
    注: イベント・モニターの出力に通常の表を使用するように選択した場合は、 デフォルトの表名が割り当てられます。このデフォルトは、必要があれば、 CREATE EVENT MONITOR ステートメントを使用してオーバーライドすることができます。
  2. 以下のいずれかの方式を使用して、ロック・イベント・データをキャプチャーするレベルを指定する必要があります。
    • 既存のワークロードを変更するか、CREATE または ALTER WORKLOAD ステートメントを使用して新規ワークロードを作成することにより、特定のワークロードを指定することができます。 ワークロード・レベルで、キャプチャーするロック・イベント・データのタイプ (デッドロック、ロック・タイムアウト、またはロック待機)、およびロックに関係したアプリケーションの SQL ステートメント履歴および入力値を必要とするかどうかを指定しなければなりません。 ロック待機の場合、アプリケーションがロックを待機する期間 (その後ロック待機についてデータがキャプチャーされる) を指定することも必要です。
    • 以下の適切なデータベース構成パラメーターを設定することで、データをデータベース・レベルで収集し、すべての DB2 ワークロードに影響を与えることができます。
      mon_lockwait
      このパラメーターは、ロック待機イベントの生成を制御します。

      ベスト・プラクティスは、ロック待機データ収集をワークロード・レベルで有効にすることです。

      mon_locktimeout
      このパラメーターは、ロック・タイムアウト・イベントの生成を制御します。

      ベスト・プラクティスは、ロック・タイムアウト・データ収集がアプリケーションで予期されていない場合には、それをデータベース・レベルで有効にすることです。 予期されている場合には、ワークロード・レベルで有効にします。

      mon_deadlock
      このパラメーターは、デッドロック・イベントの生成を制御します。

      ベスト・プラクティスは、デッドロック・データ収集をデータベース・レベルで有効にすることです。

      mon_lw_thresh
      このパラメーターは、mon_lockwait のイベントが生成されるまでのロック待機時間を制御します。

SQL ステートメント履歴および入力値のキャプチャーにより、プロセッサー時間、メモリー、およびストレージの使用量が増大しますが、 ロック問題を適切にデバッグするには、多くの場合このレベルの詳細情報が必要です。

ロック・イベントが発生した後に、 イベント・モニターによって生成された出力内で、そのイベントのデータを参照できます。 UE 表を使用した場合、その未フォーマット・イベント表内のバイナリー・データは、 db2evmonfmt と呼ばれる付属の Java ベース・アプリケーションを使用して XML またはテキスト文書に変換できます。さらに、未フォーマット・イベント表の BLOB 列内のバイナリー・イベント・データは、EVMON_FORMAT_UE_TO_XML 表関数を使用して XML レポート文書にフォーマットするか、または EVMON_FORMAT_UE_TO_TABLES プロシージャーを使用してリレーショナル表にフォーマットするかのいずれかが可能です。

出力形式として通常の表を使用した場合は、 SQL を使用して直接データを照会できます。

ロック・イベントについてモニター対象とするワークロードを判別するための助けとして、管理通知ログを調べることができます。 デッドロックまたはロック・タイムアウトが検出されるたびに、メッセージがそのログに書き込まれます。 これらのメッセージでは、ロック・リクエスターまたはロック所有者 (複数の場合あり) が実行しているワークロード、およびロック・イベントのタイプが示されます。 ロック・タイムアウト (lock_timeouts)、ロック待機 (lock_waits)、およびデッドロック (deadlocks) のワークロード・レベルのカウンターもあり、これらを調べることもできます。

ロック・イベントについて収集される情報

ロック・イベント・モニターにより収集されるロック・イベントの情報のいくつかには、以下があります。
  • イベントの原因となったロック
  • ロック・イベントの原因となったロックを保持しているアプリケーション
  • ロック・イベントの原因となるロックを待機または要求していたアプリケーション
  • ロック・イベント時のアプリケーションの実行内容。
注:
  • DB2 pureScale® 環境では、クラスター・キャッシング・ファシリティー (CF) がビジー状態のときやロック保有者がロックを解放したばかりのときは (あるいはその他の理由のために)、ロック保有者に関する情報のない「ロック・イベントの発生中はロック保有者情報を取得できません (Unable to obtain Lock Holder information during the occurrence of the lock event)」というメッセージが表示されることがあります。
  • DB2 pureScale 環境では、デッドロック・イベント・モニターは必ず lock_mode モニター・エレメントを報告するとは限りません。デッドロック・イベント・モニターの出力にロック所有者についての情報が含まれないこともあります。このことは、 CF がビジー状態でなくても起こることがあります。

推奨されないロック・モニター機能

デフォルトでは、各データベースで、推奨されない詳細なデッドロック・イベント・モニター DB2DETAILDEADLOCK が作成され、データベースがアクティブになるときに開始されます。 ロック・イベント・モニターを使用してデッドロックを検出する場合は、 DB2DETAILDEADLOCK イベント・モニターを無効にすることを検討してください。DB2DETAILDEADLOCK イベント・モニターが アクティブなまま、ロック・イベント・モニターでもデッドロック情報を収集すると、 両方のイベント・モニターがデータを収集することになり、 パフォーマンスに重大な影響を与える可能性があります。

DB2DETAILDEADLOCK イベント・モニターを除去するには、以下の SQL ステートメントを発行します。 
SET EVENT MONITOR DB2DETAILDEADLOCK state 0
DROP EVENT MONITOR DB2DETAILDEADLOCK