イベント・モニターの出力スレッドは、2 つの内部バッファーを使って、 レコードをディスクに書き出す前にそれをバッファーに入れます。 バッファーがいっぱいのときだけ、レコードがトレースに書き込まれます。 イベント・モニターにそのバッファーをフラッシュさせるには、 それをオフにするか、または FLUSH EVENT MONITOR コマンドを使用してバッファーを空にする必要があります。 これらのバッファーのサイズは、BUFFERSIZE 引き数を指定して、 CREATE EVENT MONITOR ステートメントで指定することができます。 指定するバッファーを大きくすると、ディスク・アクセスの回数が減り、 大量のスループットがあるイベント・モニターでは、 モニターのパフォーマンスが向上します。
図 4 では、 FILE ステートメント・イベント・モニターのイベント・レコードを生成する方法を示しています。 2 つのアプリケーションがデータベースに接続され、 各アプリケーションにはそれ自身のために作動するエージェントが 1 つずつあります。
![]() |
この例では、それぞれのアプリケーション・エージェントはステートメントの実行を終了したばかりで、 ステートメントについて収集したモニター・データをイベント・モニターの出力スレッドに報告しています。 出力スレッドはレコードをフォーマットし、 その 2 つのバッファーのうちのいずれかにそれを書き込みます。 バッファーがいっぱいになると、ファイルに書き込みます。 バッファーを 2 つ持つことにより、バッファーが書き込まれている間に、 出力スレッドはデータベース・エージェントからデータの受信を続けることができます。
ブロック化されたイベント・モニターは、両方のバッファーがいっぱいのとき、 バッファーが書き込まれるまで、モニター・データを送信しているエージェントを中断します。 これは、作業負荷の種類や入出力装置の速度によっては、 パフォーマンス上の大きなオーバーヘッドとなることがあります。 しかし、 ブロック化されたイベント・モニターが実行されているかぎりは、 イベント・レコードが廃棄されることはありません。 これは省略時の値です。
ブロック化されていないイベント・モニターは、 エージェントから着信するモニター・データを書き込む際、 書き込み速度よりデータの着信速度が速いと、 そのままモニター・データを廃棄してしまいます。 これにより、 イベント・モニターが他のデータベース活動に及ぼす影響は小さくなります。 ブロック化されていないイベント・モニターを作成する DLL の例を以下に示します。
![]() |
イベント・レコードを廃棄したイベント・モニターは、 オーバーフロー・イベントを生成します。 これは、モニターがイベントを廃棄する開始時刻と停止時刻、 およびその期間に廃棄されたイベントの数を指定します。
イベント・モニターは、 保留中のオーバーフローがあることを報告して、 終了または非活動化することがあります。 その場合、次のメッセージが db2diag.log に書き込まれます。
DIA1603I Event Monitor monitor-name had a pending overflow record when it was deactivated.
イベント・モニターのすべての出力は、 CREATE EVENT MONITOR ステートメントの FILE 引き数に対して提供されたディレクトリーに入れられます。
ファイル・イベント・モニターが最初に活動化されるとき、 このディレクトリーに制御ファイルが作成されます。 このバイナリー・ファイルには制御情報が含まれており、これを使って、 2 つのイベント・モニターが同じ宛先に同時に書き込もうとするのを防いだり、 次のレコードをイベント・モニターが書き込む宛先ファイルやファイル場所を把握したりします。 この名前は db2event.ctl です。 このファイルを除去したり修正しないでください。
省略時値では、イベント・モニターはそのトレースを 00000000.evt と呼ばれる単一のファイルに書き込みます。 このファイルは、ファイル・システム上にスペースがあるかぎり大きくなります。 イベント・モニター作成ステートメントの MAXFILESIZE および MAXFILES 引き数を使って、トレースの最大サイズを制限できます。
イベント・モニターによって作成されるトレースはかなり大きくなることがあるため、 それを固定サイズのいくつかのファイルに分割することができます。 また、こうすると、イベント・モニターがまだ実行している間でも、 ファイルの処理後にそれを除去することができます。
ファイルの番号は 00000000.evt から順番に付けられます。 複数のファイルを使用する場合、1 つのファイルがいっぱいになると、 出力は自動的に次の番号のファイルに書き込まれます。 たとえば、次のイベント・モニターはそのトレースを 4MB のファイルに分割します。 ファイル・システム上にスペースがあるかぎりファイルの作成が続きます。
![]() |
この結果、ターゲット・ディレクトリーに以下のファイルが作成されます。
![]() |
一番大きい番号のファイルは常に活動ファイルです。 ファイルの数が MAXFILES で定義された最大値を超えると、 イベント・モニターは自らを非活動化し、 以下のメッセージが DB2DIAG.LOG に書き込まれます。
DIA1601I Event Monitor monitor-name was deactivated when it reached its preset MAXFILES and MAXFILESIZE limit
すべてのファイルを除去することにより、 この状況を避けることができます (モニターが活動状態のときにデータを処理するを参照してください)。 イベント・モニターがまだ実行している間に、 活動ファイルを除くすべてのイベント・ファイルを除去することができます。
ファイル・イベント・モニターがディスク・スペースを使い尽くした場合、 システム・エラー・レベル・メッセージをエラー・ログ db2diag.log および db2err.log に記録した後、 自動的にシャットダウンします。
すべてのイベントを残らず追跡するために、 イベント・モニターがデータを継続的に収集するようにすることができます。 たとえば、データを収集するためにイベント・モニターを使用する 使用状況アカウント・システムがある場合、 毎晩午前 2:00 にデータ処理を開始し、 処理の終わったファイルをこの時点で削除することができます。
イベント・モニターを停止して再始動しないかぎり、 次のファイルに強制的に切り替えることはできません。 また、APPEND モードでなければなりません。 活動ファイル内でどのイベントの処理が終わったかを把握しておくために、 処理された最後のレコードのファイル番号およびファイル場所だけを追跡するアプリケーションを作成することができます。 次回トレースを処理するときには、 アプリケーションはそのファイルの位置を検索するだけで済みます。
パイプ・イベント・モニターを使用すると、 活動状態のイベント・モニターによって作成されたデータを簡単に読み取ることができます (パイプ・イベント・モニターの使用法を参照してください)。
ファイル・イベント・モニターを再始動する場合、既存のデータを消去するか、 またはそれに追加することができます。
APPEND イベント・モニターは、 最後に使用していたファイルの終わりで書き込みを開始します (ファイル番号は db2evmon.ctl 制御ファイルで示されます)。 そのファイルを除去したら、次の順番のファイル番号が使用されます。 たとえば、上記の例では、 すべての .evt ファイルを除去して、 イベント・モニターを再始動すると、 イベント・レコードは 00000003.evt に書き込まれます。 ファイルを除去しなかった場合は、 イベント・レコードは 00000002.evt に入れられるか、 またはそれに追加されます。 追加のイベント・モニターが再始動されると、start_event だけが生成されます。 イベント・ログ・ヘッダーとデータベース・ヘッダーは、 最初の活動化のときだけ生成されます。
REPLACE イベント・モニターは常に既存のイベント・ファイルを削除し、 00000000.evt で書き込みを開始します。