スナップショットは特定の時点で取るのに対して、 イベント・モニターは以下のいずれかのイベントが起こった時点で、 データベース・システム・モニターのデータをファイルまたは名前付きパイプに書き出します。
イベント・モニターを使用すると、 データベース活動のトレースを効果的に行えます。
たとえば、あるデータベースへの接続と接続の間に起こるデッドロックを記録するよう DB2 に要求することができます。 この場合、以下のようにして、 まず DEADLOCK イベント・モニターを作成して活動化しなければなりません。
![]() |
この時点で、データベースを使用している 2 つのアプリケーションがデッドロック状態になっています。 つまり、一方が処理を続行するのに必要なロックを他方が保持している状態になっています。 最終的に、このデッドロックは DB2 のデッドロック検出構成要素によって検出され、 トランザクションのうち 1 つがロールバックされます。 次の図にこのシナリオが図示されています。
![]() |
注: | +c オプションにより CLP の自動コミットがオフになります。 |
この時点でアプリケーション 1 はスタッフ表の行に関する排他ロックを保持しています。
![]() |
この時点でアプリケーション 2 は所属部表の行に関する排他ロックを保持しています。
![]() |
カーソル固定を前提にすると、 アプリケーション 1 では所属部表の個々の行を取り出す際にその行に関する共用ロックが必要になりますが、 最後の行に関する排他ロックはアプリケーション 2 に保持されているので、 その行に関するロックを取得することはできません。 アプリケーション 1 はロックが解除されるのを待機するので、 LOCK WAIT 状態になります。
![]() |
アプリケーション 2 は、 アプリケーション 1 がスタッフ表の最後の行に関する排他ロックを解除するのを待機するので、 同様に LOCK WAIT 状態になります。
この時点で両方のアプリケーションともデッドロック状態になっています。 一方が処理を続行するのに必要な資源を他方が保持している状態になっているので、 この待機状態は絶対に解決されません。 結局デッドロック検出機能によってデッドロックが検査され (管理の手引き の dlchktime データベース・マネージャー構成パラメーターを参照)、 悪影響はあるもののロールバックが選択されます。
![]() |
この時点でイベント・モニターによりデッドロック・イベントが宛先に記録されます。 アプリケーション 1 は処理を続行できるようになります。
![]() |
イベント・モニターの出力はバッファーに入れられますが、 このシナリオで生成されたイベント・レコードによってバッファーがいっぱいにはなりませんでした。 そのため、イベント・モニターの値は強制的にイベント・モニター出力書き出しプログラムに送られます。
![]() |
イベントのトレースがバイナリー・ファイルとして作成されます。 この時点で db2evmon ツールを使用してこのトレースを形式設定できます。
![]() |
イベントのトレースが形式設定され、 stdout に印刷されます。 このトレースは以下のようになります。
-------------------------------------------------------------------------- EVENT LOG HEADER Event Monitor name: DLOCKMON Server Product ID: SQL05000 Version of event monitor data: 6 Byte order: BIG ENDIAN Number of nodes in db2 instance: 1 Codepage of database: 850 Country code of database: 1 Server instance name: bourbon -------------------------------------------------------------------------- -------------------------------------------------------------------------- Database Name: SAMPLE Database Path: /home/bourbon/bourbon/NODE0000/SQL00002/ First connection timestamp: 06-03-1997 13:31:13.607548 Event Monitor Start time: 06-03-1997 13:32:11.676071 -------------------------------------------------------------------------- 3) Connection Header Event ... Appl Handle: 0 Appl Id: *LOCAL.bourbon.970603173114 - Monitor session Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.bourbon.970603173113 Program Name : db2bp_32 Authorization Id: BOURBON Execution Id : bourbon Codepage Id: 850 Country code: 1 Client Process Id: 63590 Client Database Alias: sample Client Product Id: SQL05000 Client Platform: AIX Client Communication Protocol: Local Client Network Name: Connect timestamp: 06-03-1997 13:31:13.607548 4) Connection Header Event ... Appl Handle: 1 - Application 1 Appl Id: *LOCAL.bourbon.970603173330 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.bourbon.970603173329 Program Name : db2bp_32 Authorization Id: BOURBON Execution Id : bourbon Codepage Id: 850 Country code: 1 Client Process Id: 119710 Client Database Alias: sample Client Product Id: SQL05000 Client Platform: AIX Client Communication Protocol: Local Client Network Name: Connect timestamp: 06-03-1997 13:33:29.518568 5) Connection Header Event ... Appl Handle: 2 Appl Id: *LOCAL.bourbon.970603173409 - Application 2 Appl Seq number: 0001 DRDA AS Correlation Token: *LOCAL.bourbon.970603173408 Program Name : db2bp_32 Authorization Id: BOURBON Execution Id : bourbon Codepage Id: 850 Country code: 1 Client Process Id: 33984 Client Database Alias: sample Client Product Id: SQL05000 Client Platform: AIX Client Communication Protocol: Local Client Network Name: Connect timestamp: 06-03-1997 13:34:08.972643 6) Deadlock Event ... Number of applications deadlocked: 2 - Deadlock Deadlock detection time: 06-03-1997 13:36:48.817786 Rolled back Appl Id: : *LOCAL.bourbon.970603173409 Rolled back Appl seq number: : 0001 7) Deadlocked Connection ... Appl Id: *LOCAL.bourbon.970603173409 Appl Seq number: 0001 Appl Id of connection holding the lock: *LOCAL.bourbon.970603173330 Seq. no. of connection holding the lock: Lock wait start time: 06-03-1997 13:36:43.251687 Deadlock detection time: 06-03-1997 13:36:48.817786 Table of lock waited on : STAFF Schema of lock waited on : BOURBON Tablespace of lock waited on : USERSPACE1 Type of lock: Row Mode of lock: X Lock object name: 39 8) Deadlocked Connection ... Appl Id: *LOCAL.bourbon.970603173330 Appl Seq number: 0001 Appl Id of connection holding the lock: *LOCAL.bourbon.970603173409 Seq. no. of connection holding the lock: Lock wait start time: 06-03-1997 13:35:32.227521 Deadlock detection time: 06-03-1997 13:36:48.817786 Table of lock waited on : DEPARTMENT Schema of lock waited on : BOURBON Tablespace of lock waited on : USERSPACE1 Type of lock: Row Mode of lock: X Lock object name: 15
このイベント・モニターのトレースは、 イベント・モニターが活動化された時点で 1 つのアプリケーションがデータベースに接続していたことを示しています。 このことは、出力中の最初の Connection Header Event レコード (レコード番号 3) に示されています。 活動状態のそれぞれの接続に関する Connection Event Header が、 イベント・モニターをオンにした時点で生成されます。 その後の接続に関する Connection Event Header は、 それぞれの接続が活動状態になった時点で生成されます。 2 つ目と 3 つ目の Connection Header (レコード 4 および 5) は、 2 つのアプリケーションが接続された時点で生成されたものです。
また、デッドロックが起きたこともトレースに示されています (レコード番号 6)。 デッドロックの原因になっている表とロックが示され (レコード番号 7 および 8)、 デッドロック検出機能によりロールバックされたアプリケーションも示されています (レコード番号 6)。
db2eva グラフィック・ツールを使用してトレースを形式設定することもできます。 この処理は、ファイル・トレースが大き過ぎるために db2evmon で読み取れない場合に特に効果的です。 このツールは収集された情報を表形式で表示します。 このツールには様々な視点オプションが多数組み込まれているので、 不要なレコードをフィルターにかけて、 トレース対象の期間にわたって間引くことができます。 たとえば、指定の接続に関するトランザクション・イベントだけを表示するよう指定できます。 また、DB カタログから自動的に取り出した静的 SQL のステートメントのテキストを表示することもできます (イベント・モニターのトレースでは動的 SQL のテキストだけが表示されます)。
このツールを呼び出すには、 db2eva コマンド を使用します (コマンド解説書 を参照してください)。
注: | db2eva 呼び出しを行うマシンでトレース・ファイルが使用できるようになっていなければなりません。 |
db2eva ツールは OS/2 システムと Windows システムで使用できます。
データベースに関するイベント・モニターを定義して使用するには、 少なくともそのデータベースに対する DBADM 権限がなければなりません。
シナリオ例に示されていたように、 イベント・モニターを使用してシステム・モニター・データを収集するには、 以下の 3 つのステップがあります。
モニター対象のイベントを指定します。 イベント・モニターを作成して活動化するには SQL ステートメントを使用します。 スナップショット・モニターの場合、 データベース・マネージャーのレベルで収集できるのに対して、 イベント・モニターでは、1 つのデータベースのデータのみを収集します。
イベント・モニターを作成すると、以下のように、 その定義がそのイベント・モニターのデータベース・システム・カタログに格納されます。
イベント・モニターを定義する際には、データベースに接続する必要があります。
イベント・モニターを活動化すると、プロセスまたはスレッドが開始します。 これは、イベントが発生すると、 モニター・データを名前付きパイプまたはファイルに記録します。 データベースを開始すると同時にイベント・モニターを活動化して、 初めからすべての活動をモニターすることもできます。 このようにするには、AUTOSTART イベント・モニターを作成します。
![]() |
ACTIVATE DATABASE コマンドを使用したり、 初めてアプリケーションを接続したりしてデータベースを活動化するたびに、 このイベント・モニターは自動的に開始されます。 AUTOSTART イベント・モニターを作成しても活動化されるわけではないことに注意してください。 このイベント・モニターが活動化されるのは、次回データベースが停止して再活動化された時点です。 イベント・モニターが自動的に開始されていない場合は手操作で開始しなければなりません。
![]() |
データベースが非活動化されると、 そのデータベースに関するイベント・モニターはすべて停止します。
トレースを読み取るには、db2evmon アプレットを使用するか、 または独自のアプリケーションを作成します (イベント・モニター出力を参照)。 コントロール・センターとイベント・アナライザー (DB2 GUI の一部) を使用して、 イベント・モニターを作成して活動化したり、 FILE イベント・モニターが作成したトレースを読み取ったりすることができます。
図 2 は、イベント・モニターを使用するためのプロセスとインターフェースを図示しています。
![]() |
図 2 に図示されているように、 イベント・モニターを作成して操作するには、 以下の SQL ステートメントを使用します。
イベント・モニターが活動状態かどうかを判別するには、 SQL 関数 EVENT_MON_STATE を使用します。
![]() |
戻り値 0 は、イベント・モニターが非活動であることを示します。
イベント・モニターによって戻される情報は、 スナップショット API を使用して得られる情報と似ています。 つまり、スナップショットが取られる時点を制御するイベントに関する情報が戻されます。 たとえば、接続イベント・モニターの場合は、 基本的には接続が終了する直前にアプリケーションのスナップショットが取られます。
イベント・モニターを定義する際には、
モニターされるイベント・タイプを宣言しなければなりません。
次の表に、サポートされているイベント・タイプをリストし、
戻される情報を示します。 注: 1
つのイベント・モニターで複数のイベント・タイプを定義できます。
イベント・タイプ | データが収集される時点 | 戻される情報 |
---|---|---|
デッドロック | デッドロック検出時 | 関係しているアプリケーションおよび競合しているロック。 |
ステートメント | SQL ステートメント終了時 | ステートメントの開始 / 停止時刻、使用されている CPU、動的 SQL のテキスト、 SQLCA (SQL ステートメントの戻りコード)、 およびその他のメトリック (取り出しカウントなど)。 |
サブセクション終了時 | 区分データベースの場合、使用されている CPU、実行時間、表、 および表待ち行列に関する情報。 | |
トランザクション | 作業単位の終了時 | 作業単位の開始 / 停止時刻、直前の UOW 時刻、使用されている CPU、 ロック、およびログ記録のメトリック。 XA で実行している場合は、 トランザクション・レコードは生成されない。 |
接続 | 接続終了時 | すべてのアプリケーション・レベルのカウンター。 |
データベース | データベース非活動化時、または前回の接続リセット時 | すべてのデータベース・レベルのカウンター。 |
バッファー・プール | バッファー・プールのカウンター、プリフェッチ機能、 ページ・クリーナー、および個々のバッファー・プールの直接 I/O。 | |
表スペース | バッファー・プールのカウンター、プリフェッチ機能、 ページ・クリーナー、および個々の表スペースの直接 I/O。 | |
表 | 個々の表の、読み取り / 書き込みが行われる行。 |
注: | 上の情報に加えて、 すべてのイベント・モニターはデータベースへの接続の確立をトレースします。 つまり、イベント・モニターが ON になった時点で活動状態にあるそれぞれの接続ごとに connection header record を生成して、 その後は接続が確立されるたびにこれを生成します。 |
イベント・タイプ別の生成されるレコードのリストについては、 出力レコードを参照してください。
パイプ・イベント・モニターを使用すると、 リアルタイムでイベント・レコードを処理できます。 別の利点として、パイプ・イベント・モニターを使用すると、 アプリケーションが不要データを読み取った場合にパイプを介さずにそのデータを無視できるので、 記憶域の所要量を相当減らせる可能性があります。 また、アプリケーションがイベント・モニターのデータをリアルタイムで SQL データベース内に格納できるようになります。
データをパイプに送ると、入出力は必ずブロック化され、 バッファリングだけがパイプによって実行されます。 イベント・モニターがイベント・データを書き込んですぐにデータをパイプから読み取るのは、 モニター・アプリケーションの責任です。 イベント・モニターがデータをパイプに書き込めない場合 (たとえばパイプがいっぱいになっている場合) は、 モニター・データは失われます。
パイプ・イベント・モニターを使用するためのステップは、 基本的にはどのオペレーティング・システムでも同じです。 しかし、実行方法には違いがあります。 基本的なステップについて以下で説明します。特に、 UNIX ベースのシステム、Windows NT、および OS/2 の間で違う点を強調します。
db2 connect to sample On AIX, and other UNIX platforms: db2 create event monitor STMT2 for statements write to PIPE '/tmp/evmpipe1' On Windows NT: db2 create event monitor STMT2 for statements write to PIPE '\\.\pipe\evmpipe1' On OS/2: db2 create event monitor STMT2 for statements write to PIPE '\pipe\evmpipe1'
UNIX (AIX 環境を含む) では、mkfifo() 関数か mkfifo コマンドを使用します。 OS/2 では、DosCreateNPipe() 関数を使用します。 Windows NT では、CreateNamedPipe() 関数を使用します。 パイプ名は、CREATE EVENT MONITOR ステートメントで指定された目標パスと同じでなければなりません。
UNIX では、open() 関数を使用します。 OS/2 では、DosConnectNPipe() 関数を使用します。 Windows NT では、ConnectNamedPipe() 関数を使用します。
db2evmon アプリケーションを使用することもできます。 その際データベースとパイプの名前を指定します。次に例を示します。
db2evmon -db sample -evm STMT2
このように指定すると、名前付きパイプがオープンし、 イベント・モニターによる書き込みを待機します。
イベント・モニターが自動的に開始される場合は、 特定の開始処置を行う必要はありません。ただし、 データベースがすでに活動状態になっていて、 パイプがすでにオープンされていなければなりません。
db2 set event monitor stmt2 state 1
UNIX では、read() 関数を使用します。 OS/2 では、DosRead() 関数を使用します。 Windows NT では、ReadFile() 関数を使用します。 アプリケーションでは、パイプからのデータの読み取りをいつでも停止することができます。 EOF を読み取ったら、それ以上モニター・データはありません。 イベント・モニター・データを読み取る方法については、 イベント・モニター出力を参照してください。
db2 set event monitor stmt2 state 0
このステートメントは、 任意のイベント・モニター (自動的に始動されたものも含む) を停止するために使用できます。 イベント・モニターを明示的に停止しない場合は、以下の時点で停止されます。
UNIX では、close() 関数を使用します。 OS/2 では、DosDisConnectNPipe() 関数を使用します。 Windows NT では、DisconnectNamedPipe() 関数を使用します。
UNIX では、unlink() 関数を使用します。 OS/2 では、DosClose() 関数を使用します。 Windows NT では、CloseHandle() 関数を使用します。
UNIX ベースのオペレーティング・システムの場合、 名前付きパイプはファイルと類似しているため、それらを削除したり、 それぞれの使用の前に再び作成したりする必要はありません。
さらに、名前付きパイプには十分なスペースがなければなりません。 アプリケーションが十分な速さで名前付きパイプからデータを読み取らないと、 パイプは満杯になり、オーバーフローが発生します。 パイプのオーバーフローは、 パイプの作成者が名前付きパイプ・バッファーのサイズを定義できるようなプラットフォーム (OS/2 など) でも起こり得ます。 バッファーが小さいほど、オーバーフローの発生する可能性が大きくなります。 パイプのオーバーフローが発生すると、 モニターはオーバーフローが発生していることを示すオーバーフロー・イベント・レコードを作成します。 イベント・モニターはオフになりませんが、モニター・データは失われます。 モニターが非活動化されるときに未解決のオーバーフロー・イベント・レコードがある場合は、 診断メッセージが記録されます。 それ以外の場合、オーバーフロー・イベント・レコードは、 可能なときにパイプに書き込まれます。
オペレーティング・システムでパイプ・バッファー・サイズを定義できる場合は、 少なくとも 32K のパイプ・バッファーを使用してください。 大ボリュームのイベント・モニターの場合、モニター・アプリケーションの処理優先順位を、 エージェント処理優先順位以上の値 (AIX では低くてもよい) に設定する必要があります (管理の手引き のエージェントの優先度のセクションを参照してください)。