ターゲット表、コントロール表、およびイベント・モニター表の管理

SQL 表にイベント・レコードを保管するように、イベント・モニターを定義することができます。 これを行うには、CREATE EVENT MONITOR ステートメントを WRITE TO TABLE 節を付けて使用します。

表書き込みイベント・モニターを作成すると、 イベント・モニターは、データを戻す論理データ・グループのそれぞれについて、レコードを保管するためのターゲット表を作成します。それぞれの表において、列名はそれが表すモニター・エレメント名と一致しています。 デフォルトでは、イベント・モニターはイベント・モニターの作成者のスキーマで表を作成し、 その表に、対応する論理データ・グループ名とイベント・モニター名を連結した名前を付けます。

例えば、以下のステートメントについて考えてみましょう。 これは、STATEMENTS イベントをキャプチャーするイベント・モニターを作成するものです。
CREATE EVENT MONITOR test FOR STATEMENTS WRITE TO TABLE
STATEMENTS イベント・タイプを使用するイベント・モニターは、 event_connheader、event_stmt、および event_subsection 論理データ・グループからデータを収集します。 個々のイベント・タイプに固有な論理データ・グループを表す各表に加えて、表書き込みイベント・モニターごとに 1 つのコントロール表が作成されます。 ユーザー riihi によって作成されたイベント・モニター test の場合、 データベース・マネージャーは以下の表を作成します。
  • riihi.connheader_test
  • riihi.stmt_test
  • riihi.subsection_test
  • riihi.control_test
最初の 3 つの表は、論理データ・グループ event_connheaderevent_stmt、および event_subsection のそれぞれに対応しています。最後の表 riihi.control_test は、コントロール表です。コントロール表には、イベント・モニター・メタデータ、具体的には event_startevent_dbheader (conn_time モニター・エレメントのみ)、および event_overflow 論理データ・グループからのイベント・モニター・メタデータが含まれます。

モニター・エレメントがオーバーフローのグループに書き込まれるのは、非ブロック化 イベント・モニターの場合のみです。非ブロック化イベント・モニターでは、イベントを生成するエージェントは、イベント・バッファーが満杯になった場合にバッファーが表に書き込まれるのを待機しません。代わりに、イベント・モニターは、自身がデータを書き込める速度よりも速くエージェントから来たモニター・データを廃棄します。 この場合、イベント・モニターは、オーバーフローが発生したことを示す情報をコントロール表に記録します。 この情報には、モニター・エレメント message が含まれます。オーバーフローが発生した場合には、このモニター・エレメントにテキスト OVERFLOW:n があります。n は、イベント・バッファーが満杯だったために廃棄されたイベント・レコードの数を表します。

表書き込みイベント・モニターはアクティブになると、 各ターゲット表に対する IN 表ロックまたは IX 表ロックを獲得します。これによって、 イベント・モニターがアクティブである間にターゲット表が変更されることを防ぎます。 この表ロックは、イベント・モニターがアクティブである間は、すべての表において維持されます。 ターゲット表に対する排他的アクセスが必要な場合 (例えば、ユーティリティーを実行する場合) には、 そのようなアクセスを試行する前に、まずイベント・モニターを非アクティブ化して表ロックを解放してください。

ターゲット表の各列名は、イベント・モニターのエレメント ID と一致しています。 対応するターゲット表の列がないイベント・モニター・エレメントは無視されます。

表書き込みイベント・モニターのターゲット表 (未フォーマット・イベント (UE) 表を含む) は、 手動で整理する必要があります。 非常にアクティブなシステムでは、イベント・モニターが大量のデータを記録するために、 ディスク・スペースをすぐに使い尽くしてしまうことがあります。 ファイルまたは名前付きパイプに書き込むイベント・モニターを定義する場合と異なり、 表書き込みイベント・モニターは、 特定の論理データ・グループまたはモニター・エレメントの情報だけを記録するように定義することができます。 このフィーチャーを使用して、目的にかなうデータだけを収集すれば、 イベント・モニターによって生成されるデータ量を削減することができます。 例えば、次のステートメントは、 event_conn 論理データ・グループだけから接続イベントをキャプチャーし、lock_waits モニター・エレメントのみを含むようイベント・モニターを定義しています。
CREATE EVENT MONITOR conn_monitor FOR CONNECTIONS WRITE TO TABLE
                     CONN(INCLUDES(lock_waits))

イベント・モニターのターゲット表を、デフォルトの表スペース内にデフォルトの表名を使用してデフォルトのスキーマで作成することが望ましくない場合があります。 大量のモニター・データが予想される場合は、ターゲット表を専用の表スペースに配置する必要があるでしょう。 スキーマ、表、および表スペースの名前は CREATE EVENT MONITOR ステートメントで指定できます。 そのスキーマ名と表名から、各表の派生名が形成されます。 表スペース名は、表名の後に、オプションの IN 節を付けて追加することができます。 データベース・マネージャーが自動的に作成するターゲット表とは異なり、表スペースをイベント・モニター定義内に指定する場合、その表スペースは既に存在していなければなりません。表スペースを指定しなかった場合は、ユーザーが USE 特権を持つ表スペースが割り当てられます。

ターゲット表を使用できるのは、単一イベント・モニターに限られます。別のイベント・モニターにターゲット表を定義している場合、 または他の理由でターゲット表を作成できない場合、CREATE EVENT MONITOR ステートメントは失敗します。

表スペース名は表名の後に、オプションの IN 節を付けて追加することができます。 データベース・マネージャーが自動的に作成するターゲット表とは異なり、表スペースがイベント・モニター定義に組み込まれている場合には、それがすでに存在していなければなりません。表スペースが指定されていない場合には、定義プログラムが USE 特権を有する表スペースが割り当てられます。

パーティション・データベース環境では、表書き込みイベント・モニターは、イベント・モニター表を含む表スペースが存在するデータベース・パーティション上でのみアクティブになります。特定のデータベース・パーティション上にアクティブ・イベント・モニターのターゲット表スペースが存在しない場合、そのデータベース・パーティションのイベント・モニターは非活動状態にされ、db2diag コマンド・ログ・ファイルにエラーが書き込まれます。

イベント・モニター・データの検索時のパフォーマンスを向上させるために、 イベント表に索引を作成することができます。 トリガー、関係保全、制約などの表属性を追加した場合、イベント・モニターはそれらを無視します。

例えば、次のステートメントは、event_connheaderevent_stmt、および event_subsection 論理データ・グループを使用して、STATEMENTS イベントをキャプチャーするイベント・モニターを定義します。3 つのターゲット表のそれぞれには、異なるスキーマ、表、および表スペースの組み合わせがあります。
CREATE EVENT MONITOR test FOR STATEMENTS
WRITE TO TABLE CONNHEADER,
STMT (TABLE mydept.statements),
SUBSECTION (TABLE subsections, IN mytablespace)
上記のステートメントをユーザー riihi が発行したとすると、 各ターゲット表の派生名および表スペースは以下のようになります。
  • CONNHEADER: riihi.connheader_test (デフォルトの表スペース)
  • STMT: mydept.statements (デフォルトの表スペース)
  • SUBSECTION: riihi.subsections (表スペース mytablespace)
イベント・モニターを活動化しているときにターゲット表が存在しない場合でも、活動化は続行しますが、ターゲット表に挿入されるはずだったデータは無視されます。 また、ターゲット表にモニター・エレメント専用の列がない場合にも、 そのモニター・エレメントは無視されます。

表書き込みイベント・モニターがアクティブな場合、 イベント・レコードを保管する表スペースがその限界に達する可能性があります。DMS 表スペースの場合、このリスクを制御するために、 イベント・モニターを非アクティブ化する表スペース容量のパーセンテージを定義することができます。 この値は、CREATE EVENT MONITOR ステートメントの PCTDEACTIVATE 節に指定できます。 SMS 表スペースの場合、この値は 100 に設定されます。 ターゲット表スペースの自動サイズ変更フィーチャーを有効化した場合は、 PCTDEACTIVATE 値を 100 に設定する必要があります。

非パーティション・データベース環境では、最後のアプリケーションが終了すると (それまでにデータベースが明示的にアクティブ化されていないと)、表書き込みイベント・モニターはすべて非アクティブ化されます。パーティション・データベース環境では、 カタログ・パーティションが非アクティブ化されると表イベント・モニターへの書き込みが非アクティブ化されます。