イベント・モニターの Named PIPE 管理

一部のイベント・モニターでは、イベント・データを名前付きパイプに 書き込むことができます。 以下に、名前付きパイプのイベント・モニターを より効率的に使用するためのガイドラインを示します。

パイプ・イベント・モニターでは、Named PIPE によって、 イベント・モニターのデータ・ストリームを処理することができます。 パイプ・イベント・モニターの使用は、 リアルタイムでイベント・レコードを処理する必要がある場合に有用です。 別の利点として、アプリケーションがパイプから読み取った時に不要なデータを無視できるので、 ストレージ要件を相当減らせる可能性があります。

AIX®では、mkfifoコマンドを使用して名前付きパイプを作成することができます。 Linux® およびその他の UNIX タイプでは、pipe() ルーチンを使用します。 Windowsでは CreateNamedPipe(を使用して名前付きパイプを作成することができます。

データをパイプに送ると、入出力は必ずブロック化され、 バッファリングだけがパイプによって実行されます。 イベント・モニターがイベント・データを書き込んですぐにデータをパイプから読み取るのは、 モニター・アプリケーションの責任です。 イベント・モニターがデータをパイプに書き込めない場合 (例えばパイプが満杯になっている場合) は、 モニター・データは失われます。

さらに、Named PIPE には、着信するイベント・レコードを処理するための十分なスペースがなければなりません。 アプリケーションが十分な速さで Named PIPE からデータを読み取らないと、 パイプは満杯になり、オーバーフローが発生します。 パイプ・バッファーが小さいほど、オーバーフローの発生する可能性が大きくなります。

パイプのオーバーフローが発生すると、 モニターはオーバーフローが発生していることを示すオーバーフロー・イベント・レコードを作成します。 イベント・モニターは OFF になりませんが、モニター・データは失われます。 モニターが非アクティブ化されるときに未解決のオーバーフロー・イベント・レコードがある場合は、 診断メッセージが記録されます。 それ以外の場合、パイプが書き込み可能になれば、オーバーフロー・イベント・レコードは、パイプに書き込まれます。

パイプに一度に書き込めるデータ量は、 基礎となるオペレーティング・システムによって決まります。 オペレーティング・システムでパイプ・バッファー・サイズを定義できる場合は、 少なくとも 32K のパイプ・バッファーを使用してください。 大ボリュームのイベント・モニターの場合、モニター・アプリケーションの処理優先順位を、 エージェント処理優先順位と同等かそれ以上の値に設定する必要があります。

アクティビティー・イベント・モニターまたは統計イベント・モニターの単一の書き込み操作から生じた データ・ストリームに、Named PIPE に書き込めるデータ量より多くのデータが 含まれている場合があります。 そのような場合は、バッファーに収まるように データ・ストリームがブロックに分割されます。 各ブロックはヘッダーによって識別され、一番目のブロックは、 エレメント ID SQLM_ELM_EVENT_STARTPIPEBLOCK を含む論理ヘッダーによって識別されます。 最後のブロックは、エレメント ID SQLM_ELM_EVENT_ENDPIPEBLOCK を含む論理ヘッダーによって識別されます。 間にあるブロックはすべて、 エレメント ID SQLM_ELM_EVENT_MIDPIPEBLOCK を含む論理ヘッダーによって識別されます。 パイプを読み取るモニター・アプリケーションは、これらのヘッダーを認識し、 ブロックを再組み立てして完全なデータ・ストリームに戻す必要があります。 必要な場合はブロック・ヘッダーを除去してからブロックを再組み立てして、 完全かつ有効なデータ・ストリームを形成します。 db2evmon ツールにはこの機能が備わっており、 Named PIPE に書き込むイベント・モニターによって生成されるすべてのイベントに、 必要に応じてブロックを再組み立てすることで定様式の出力を提供します。 選択したイベントまたはモニター・エレメントのみを処理するには、 そのような処理を行う独自のアプリケーションを作成します。