パーティション・データベースおよび Db2 pureScale 環境のデータベースにおけるイベント・モニター

一般的に、パーティション・データベース・システムまたは Db2 pureScale 環境のイベント・モニターは、非パーティション単一メンバー・データベースで実行されるイベント・モニターと同様に動作します。ただし、注意すべき相違点もいくつかあります。

パーティション・データベース環境

通常表および未フォーマット・イベント (UE) 表に書き込むイベント・モニター

特定のパーティション上の通常表および UE 表に書き込みを行うイベント・モニターを作成することはできません。そうではなく、パーティション・データベース環境では、 イベント・モニター処理は各パーティション上で実行されます。 より正確に言えば、イベント・モニター処理は、 ターゲット表が存在するデータベース・パーティション・グループに属する各パーティションのメンバー上で実行されます。

イベント・モニター処理を実行するそれぞれのパーティションに、 特定のイベント・モニター用の同じセットのターゲット表があります。 それらの表の中のデータは、パーティションごとに異なります。 ある特定のパーティションにおけるデータは、 そのパーティション上で発生したイベントのみを反映するからです。 表イベント・モニターの場合は、 各パーティションからイベント・モニター表のデータを収集する SQL ステートメントを実行することによって、全パーティションの集約値を取得できます。 UE 表イベント・モニターの場合は、 EVMON_FORMAT_UE_TO_TABLE ストアード・プロシージャーに指定する SQL ステートメントを使用するか、 または EVMON_FORMAT_UE_TO_XML 表関数を使用することによって、パーティション間でデータを集約できます。

各イベント・モニター表の最初の列は PARTITION_KEY という名前で、 これは表のパーティション・キーとして使用されます。 各イベント・モニター処理は、 この列の値を選択し、処理を実行中のデータベース・パーティションにデータを挿入します。 つまり、挿入操作は、そのイベント・モニター処理が実行されているデータベース・パーティション上でローカルに実行されます。 任意のデータベース・パーティションで、PARTITION_KEY フィールドは同じ値を含みます。このため、データ・パーティションをドロップしてデータの再配分を行う場合、 ドロップされたデータベース・パーティション上のすべてのデータは均等に配分されるのではなく、 他の 1 つのデータベース・パーティションに移動することになります。 したがって、データベース・パーティションをドロップする前に、 そのデータベース・パーティション上のすべての表の行を削除することを検討してください。

また、 パーティション・データベース環境では、PARTITION_NUMBER または MEMBER という名前の列が各表に定義されます。 この列には、データが挿入されたパーティションまたはメンバーの番号が含まれます。

イベントは、ターゲット表用の表スペースが存在するパーティション上のイベント・モニター・ターゲット表に書き込まれます。 イベント・モニターのターゲット表用の表スペースが、イベント・モニターを実行するパーティション上に存在しない場合、 そのようなパーティションではデータは収集されませんが、 エラーは戻されません。 さらには、表スペースが存在しない場合、イベントに関するログ・レコードも書き込まれません。この動作を利用すると、ユーザーは、 特定のパーティションにのみ存在する表スペースを作成することにより、 モニター用にパーティションのサブセットを選択できることになります。

表書き込みイベント・モニターの活動化の際、 FIRST_CONNECT および EVMON_START に対するコントロール表の各行は、 ターゲット表用の表スペースが存在するすべてのデータベース・パーティション上で挿入されます。

イベント・モニターの活動化の際にパーティションがまだアクティブでない場合は、そのパーティションが次回活動化された時にイベント・モニターは活動化されます。

ファイルおよび名前付きパイプに書き込むイベント・モニター

ファイル・イベント・モニターおよびパイプ・イベント・モニターは、1 つの例外を除き、 それらのイベント・モニターが実行されているデータベース・パーティション (モニター・パーティション) 上で発生したイベントのみをキャプチャーします。このようなイベント・モニターは、ローカル・イベント・モニター と呼ばれます。前述の例外とは、 DEADLOCK イベント・モニターの場合です。これは、ローカル・イベント・モニターとしても、グローバル・イベント・モニターとしても作成できます。グローバル・イベント・モニターとして作成すると、 すべてのデータベース・パーティションでデッドロック情報が収集され、 イベント・モニター処理を実行している特定のデータベース・パーティションに報告されます。 1

パーティション・データベース環境でファイル・イベント・モニターまたはパイプ・イベント・モニターを作成する場合、 イベント・モニターを実行するパーティションを CREATE EVENT MONITOR ステートメントの一部として指定できます。 パーティション番号を省略すると、 イベント・モニターの作成時に接続していたデータベース・パーティション上でイベント・モニターは実行されます。

イベント・モニターは、モニター・パーティションがアクティブである場合にのみ活動化できます。 イベント・モニターを活動化するために SET EVENT MONITOR ステートメントを使用したものの、 モニター・パーティションがまだアクティブではなかった場合、 イベント・モニターの活動化は、モニター・パーティションが次回開始される時に行われます。 また、このイベント・モニターの活動化は、 明示的にイベント・モニターまたはインスタンスを非アクティブ化しない限り、自動的に行われます。例えば、以下の一連のステートメントを考慮してみましょう。 
Db2 CONNECT TO PAYROLL
Db2 CREATE EVENT MONITOR ABC ... ON DBPARTITIONNUM 2
Db2 SET EVENT MONITOR ABC STATE 1
上記のステートメントを実行した後、イベント・モニター ABC は、 データベース PAYROLL がデータベース・パーティション 2 でアクティブになると、必ず自動的にアクティブになります。 この自動活動化は、ステートメント Db2 SET EVENT MONITOR ABC STATE 0 を実行するか、あるいはパーティション 2 が停止するまで行われます。
データベース・パーティションを追加した場合に、 既存のグローバルな表イベント・モニターまたは UE 表イベント・モニターが、 その新しく作成されたパーティションのデータ収集を自動的に開始することはありません。 新しいパーティションに関するデータを収集して記録するには、以下のいずれかの手順を実行する必要があります。
  • グローバル・イベント・モニター (つまり DEADLOCKS イベント・モニター) の場合は、 イベント・モニターの再始動。
  • 表または UE 表イベント・モニターの場合は、イベント・モニターのドロップ、再作成、および再始動。

Db2 pureScale 環境

Db2 pureScale 環境では、 実質的に 1 つのデータ・パーティションと、データを処理する 2 つ以上のメンバーが存在します。 したがって、イベント・モニターを作成すると、 書き込み先がファイル、パイプ、表、または UE 表のいずれであろうと、 イベント・モニター処理はすべてのメンバー上で実行されます。

イベント・データの報告は、メンバー単位で行われます。この結果、 total_cpu_time モニター・エレメントのような、あるメンバーに関連するモニター・エレメントまたはメトリックは、 そのメンバー固有のデータを報告します。ただし、 tablespace_total_pages モニター・エレメントのような、 データそのものに関連する他のモニター・エレメントは、どのメンバーが報告するかにかかわらず同じ値を示します。

例

例 1: ファイル書き込みイベント・モニターをパーティション・データベース環境で作成する
以下の例は、 パーティション 3 で実行され、バッファー・プール関連イベントに関するデータを収集し、 その出力をファイルに書き込むイベント・モニターを作成する方法を示しています。 
CREATE EVENT MONITOR bpmon FOR BUFFERPOOLS
                     WRITE TO FILE '/tmp/dlevents'
                     ON DBPARTITION 3
例 2: 表イベント・モニターをパーティション・データベース環境で作成する
以下の例は、 アクティビティー関連イベントに関するデータを収集し、 その出力を表に書き込む表モニターを作成する方法を示しています。 
CREATE EVENT MONITOR myacts FOR ACTIVITIES
                     WRITE TO TABLE
この例では、 イベント・モニターに対して論理データ・グループを指定していないため、 このタイプのイベント・モニターに関連付けられているすべての論理データ・グループに関して表が作成されます。 それらの表はどれも、各パーティションのデフォルトの表スペースに作成されます (各パーティションにデフォルトの表スペースが存在する場合)。 各データベース・パーティション上の表に収集されるデータは、 そのパーティションで発生したイベントに関連するデータです。
特定のパーティションのイベント・モニター・データを表示するには、そのパーティションを照会する SELECT ステートメントを実行します。
SELECT TOTAL_CPU_TIME FROM myacts WHERE PARTITION_NUMBER = 3
1 このイベント・モニターは推奨されなくなりました。ロックおよびデッドロックのイベント情報をキャプチャーするための推奨イベント・モニターは、LOCKING イベント・モニターです。