このトピックでは、日常のデータベース操作において作業単位イベント・モニターを使用する 1 つの方法が示されています。 一部のビジネス環境では、アプリケーションが使用する処理時間に応じて部門ごとに請求される場合があります。作業単位イベントを使用すると、異なるそれぞれのアプリケーション、ワークロード、またはサービス・クラスが使用する CPU 時間を記録できます。その後、この情報を、システム・リソースに関する請求を実行する会計アプリケーションで使用できます。
始める前に
CREATE EVENT MONITOR ステートメントでは、イベント・モニターによって生成される未フォーマット・イベント (UE) 表を格納するために最低 8 K のページ・サイズの表スペースが必要となります。表スペースを CREATE EVENT MONITOR ステートメントで明示的に指定しない限りは、データベースのデフォルトの表スペースが使用されます。
このタスクについて
このタスクでは、『チャージバック』アカウンティングの基本的なシナリオについて説明します。
以下に記す例では、システムで実行されるすべての作業がトラッキングされます。
収集されたデータからレポートが作成され、さまざまなアプリケーションによって使用された CPU 時間が表示されます。
組織の編成方法によっては、ワークロードに基づくシステム時間のトラッキングが適切な場合もあります。
または、特定のワークロード、または種々のユーザーごとに、異なるサービス・スーパークラスで使用された CPU 時間を調べることもできます。データがリレーショナル表に書き込まれる場合、このタスクの例が示しているように、SQL を使用するとほとんど無限に近い方法でデータを照会し、提示することができます。
注: 作業単位内のアクティビティーは、さまざまなサービス・サブクラスで実行される可能性があります。
したがって、サービス・サブクラスごとに作業単位情報を集約するのは適切ではありません。サービス・クラスごとに CPU 時間を集約する場合には、代わりにアクティビティー・イベント・モニターを使用してください。
手順
- 作業単位イベント・モニターを作成し、終了した作業単位に関する情報をキャプチャーします。
例えば、TRACKWORK というイベント・モニターを作成するには、以下の SQL を使用できます。
CREATE EVENT MONITOR TRACKWORK FOR UNIT OF WORK WRITE TO UNFORMATTED EVENT TABLE
このステートメントにより、未フォーマット・イベント (UE) 表に書き込む作業単位イベント・モニターが作成されます。UE 表の名前は、イベント・モニター TRACKWORK 自体と同じで、この表はデフォルトの表スペースに格納されます。
- 以下のコマンドを実行して、データベース上で実行されたすべての作業単位に関するイベント情報を収集することを、データベース・マネージャーに連絡します。
UPDATE DATABASE CONFIGURATION FOR dbname USING MON_UOW_DATA BASE
このコマンドにより、データ・サーバーで実行されたすべての作業単位に関する情報が、作業単位の完了時に、活動状態にある作業単位イベント・モニターに送信されます。収集される作業単位データの範囲を制御する方法について詳しくは、
データ収集の構成を参照してください。
- 次に、イベント・モニターを活動状態にします。
SET EVENT MONITOR TRACKWORK STATE 1
注: デフォルトでは、このイベント・モニターはデータベースの活動化時に自動的に開始されます。AUTOSTART オプションがデフォルトで適用されるためです。ただし、このイベント・モニターは既にアクティブなデータベースで作成されるので、SET EVENT MONITOR コマンドを使用して手動で開始する必要があります。
この時点以降、作業単位イベント・モニターは、各作業単位が実行されて完了する間に情報を収集します。それぞれの作業単位が完了すると、イベント・モニターは UE 表 TRACKWORK にイベントに関するレコードを追加します。
- レポートを作成するためにデータを収集する準備が整ったなら、TRACKWORK UE 表からレコードを抽出する必要があります。
この情報は XML 形式またはリレーショナル形式で表示できます。その際には、UE 表のデータを変換するために EVMON_FORMAT_UE_TO_XML プロシージャーまたは EVMON_FORMAT_UE_TO_TABLES プロシージャーを使用します。または、db2evmonfmt ツールを使用して、イベント・モニターによって戻される情報のテキスト・レポートを作成することも可能です。
この例では、ご自分の必要にとってどの方法が最も適しているかを確認するために、EVMON_FORMAT_UE_TO_TABLES を使用してリレーショナル表を作成する方法が取り上げられています。
CALL EVMON_FORMAT_UE_TO_TABLES
('UOW', NULL, NULL, NULL, NULL, NULL, NULL, -1, 'SELECT * FROM TRACKWORK')
EVMON_FORMAT_UE_TO_TABLES プロシージャーは、イベント・モニターによって生成された UE 表 TRACKWORK を調べます。UE 表の各レコードを選択し、その中から、作業単位イベント・モニターが収集したデータが含まれる行を以下の 2 つのリレーショナル表に作成します。
1 番目の表には、キャプチャーされた各イベントと関連する、最も頻繁に使用されるモニター・エレメントとメトリックが含まれます。2 番目の表には、各イベントの詳細メトリックが入っています。
注 :
- ステップ 2 で MON_UOW_DATA 構成パラメーターに BASE ではなく PKGLIST を指定した場合、EVMON_FORMAT_UE_TO_TABLES プロシージャーによって UOW_PACKAGE_LIST という 3 番目の表が作成されます。この表には、作業単位に関連したパッケージ・リスト情報が入っています。ただし、この例の場合、基本的なモニター・エレメントだけが収集されるので (ステップ 2 参照)、この表には何もデータが入りません (パッケージ・リスト情報の使用法について詳しくは、作業単位イベント・モニターのパッケージ・リスト情報を参照してください)。
- UOW_METRICS の列に入っている値は、UOW_EVENT 表の METRICS 列に含まれている XML 文書にもあります。列指向のアクセスを行うためにより便利な方法として、UOW_METRICS 表でも提供されています。
- 前述のステップで生成された表を照会し、種々のアプリケーションによってどれほどの CPU 時間が使用されたかを確認します。
以下のステートメントを使用すると、作業単位イベント・モニターが初期化されて以降、さまざまなユーザーがシステムで使用した合計 CPU 時間の明細が戻ります (この例では、クライアント・アプリケーションは
sqleseti API によって、または IBM® Rational® Application Developer
for WebSphere® Software などのご使用になる可能性のあるアプリケーション開発環境によって、データベースに識別されると想定しています)。
SELECT SUBSTR(E.CLIENT_USERID,1,10) AS CLIENT_ID,
SUBSTR(E.CLIENT_APPLNAME,1,80) AS CLIENT_APP,
SUBSTR(E.CLIENT_WRKSTNNAME,1,10) AS WKSTN,
SUM(M.TOTAL_CPU_TIME) AS CPU_TIME
FROM UOW_EVENT E, UOW_METRICS M
WHERE M.APPLICATION_ID = E.APPLICATION_ID
AND M.UOW_ID = E.UOW_ID
AND M.MEMBER = E.MEMBER
GROUP BY E.CLIENT_USERID, E.CLIENT_APPLNAME, E.CLIENT_WRKSTNNAME
ORDER BY CPU_TIME DESC;
この照会は、以下の結果を返します。
CLIENT_ID CLIENT_APP WKSTN CPU_TIME
---------- -------------------------------------------------------------------------------- ---------- --------------------
987770013
Db2BATCH 249375000
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003021324173 91181678
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1004201047173 66097348
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003191536588 28824420
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003191536434 27555568
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003221122075 16203116
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003221118191 15759227
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003221531062 15630121
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003221117466 15236718
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003221116141 14607249
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003251550366 14427883
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003051054311 1312500
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003051053301 1296875
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003051139066 1296875
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003051152281 1281250
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003041230283 1046875
asrisk2 1031250
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003291503479 515625
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003251506219 484375
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003221444488 453125
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003021323249 406250
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003251544498 296875
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003171431559 171875
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003041227488 156250
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003221117188 109375
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003021333329 62500
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003191502148 62500
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003191527385 62500
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003191528492 62500
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003191530518 62500
CLP C:¥DOCUME~1¥ALLUSE~1¥APPLIC~1¥IBM¥Db2¥Db2COPY1¥Db2¥TMP¥CCSCRIPT1003191533265 62500
CLP C:¥Documents and Settings¥All Users¥Application Data¥IBM¥Db2¥Db2COPY1¥Db2DAS 62500
- この時点では、作業単位イベント・モニター TRACKWORK は引き続き情報を収集しています。
さまざまなアプリケーション、ユーザー、ワークロードが使用する CPU 時間をトラッキングする方法に応じて、以下のいずれかの行動方針を選択できます。
- 毎日 CPU 使用量を計算する場合、この作業単位イベント・モニターを活動状態のままにできます。以下のように EVMON_FORMAT_UE_TO_TABLES プロシージャーを毎日実行し、前日の消費時間メトリックだけを取り出します。
CALL EVMON_FORMAT_UE_TO_TABLES
('UOW', NULL, NULL, NULL, NULL, NULL, NULL, -1,
'SELECT * FROM TRACKWORK
WHERE (DATE(EVENT_TIMESTAMP)=(CURRENT DATE - 1 DAY))'
)
この方法を使用する場合、EVMON_FORMAT_UE_TO_TABLES プロシージャーによって生成される 3 つのリレーショナル表は、時間の経過とともに CPU の使用履歴によって徐々に大きくなり続けます。ステップ 5 の照会を実行すると、これらの表が EVMON_FORMAT_UE_TO_TABLES プロシージャーによって最初に作成されて以降の CPU 時間の累積合計が戻ります。この照会に以下のように変更を加えて、前日の結果だけを表示することができます。SELECT SUBSTR(E.CLIENT_USERID,1,10) AS CLIENT_ID,
SUBSTR(E.CLIENT_APPLNAME,1,80) AS CLIENT_APP,
SUBSTR(E.CLIENT_WRKSTNNAME,1,10) AS WKSTN,
SUM(M.TOTAL_CPU_TIME) AS CPU_TIME
FROM UOW_EVENT E, UOW_METRICS M
WHERE M.APPLICATION_ID = E.APPLICATION_ID
AND M.UOW_ID = E.UOW_ID
AND M.MEMBER = E.MEMBER
AND(DATE(E.EVENT_TIMESTAMP)=(CURRENT DATE - 1 DAY))
GROUP BY E.CLIENT_USERID, E.CLIENT_APPLNAME, E.CLIENT_WRKSTNNAME
ORDER BY CPU_TIME DESC;
ヒント: 毎日 CPU 使用量をトラッキングするものの、システム上で収集するデータ量を管理する場合には、リレーショナル表を更新してから、UE 表で不要になったデータを削除します。例えば、UE 表 TRACKWORK から前日に収集したデータを削除するには、以下のような DELETE ステートメントを使用します。
DELETE FROM TRACKWORK WHERE (DATE(EVENT_TIMESTAMP)=(CURRENT DATE - 1 DAY))
イベント・モニターがアクティブの間は、情報の書き込み先のすべての表に対して意図的排他 (IX) 表ロックを保持し、使用中にそうした表がドロップされることがないようにします。
大量の行を削除している場合、DELETE ステートメントは大量の行ロックを取得します。この場合、ロック・エスカレーションが生じる可能性があります。行ロックが表ロックに変換される場合があるためです。このように表ロックが要求されると、DELETE ステートメントがハングする恐れがあります。イベント・モニターでは対象の表に既にロックがあるからです。
この状態を回避するため、DELETE ステートメントを発行する前に、以下のようにロック・タイムアウトを設定することを考慮してください。
SET CURRENT LOCK TIMEOUT 60
ロック・タイムアウト期間を増やしても問題が解決しない場合には、データの小サブセットのみ (例えば、6 時間か 12 時間などの限られた短期間のレコード) を削除してみてください。
この方法ではロックがほとんど必要ではありません。そのため、ロック・エスカレーションが生じる可能性が低くなります。
また、ストレージ要件と履歴データを表示する必要性とのバランスを考慮に入れながら、EVMON_FORMAT_UE_TO_TABLES によって生成されるリレーショナル表を整理できます。
- CPU 時間の計算が終了したら、以下のステップを実行して、イベント・モニター情報の収集を停止し、イベント・モニターとその関連表をドロップできます。
- SET EVENT MONITOR TRACKWORK STATE 0 コマンドを使用して、作業単位のこのイベント・モニター情報の収集を無効にします。
- DROP EVENT MONITOR ステートメントを使用して、イベント・モニター自体をドロップします。
- DROP TABLE ステートメントを使用して、対象のイベント・モニターに関連する表をドロップします。この場合、ドロップする表は以下のように、合計 4 つになります。
- TRACKWORK。イベント・モニターから情報を収集するのに使用した UE 表
- UOW_EVENT
- UOW_METRICS
- UOW_PACKAGE_LIST
- オプション: アクティブなイベント・モニターが全く残っていない場合には、以下のコマンドを使用して、作業単位イベント情報が収集されないようにデータベース構成を更新できます。
UPDATE DATABASE CONFIGURATION FOR dbname USING MON_UOW_DATA NONE
変化形: 特定のワークロードのメトリック収集
これまでの例では、システムで実行されたすべての作業に関する作業単位メトリックをキャプチャーする方法について示されていました。UPDATE
DATABASE CONFIGURATION コマンドを使用して収集されるデータの範囲を設定すると、必要以上の情報が収集される場合があります。例えば、特定のワークロードによって実行された 1 つの作業のみをトラッキングすることが必要な場合があるかもしれません。
この場合、ステップ 2 で示されていたようにデータベース全体に渡って作業単位情報の収集を有効にするのではなく、CREATE ステートメントまたは ALTER WORKLOAD ステートメントで COLLECT UNIT OF WORK DATA 節を指定できます。この節を使用すると、指定されたワークロードのデータだけが、イベント・モニターによって収集されます。例えば、PAYROLL というワークロードの作業単位データを収集するには、以下のステートメントを使用します。ALTER WORKLOAD PAYROLL COLLNECT UNIT OF WORK DATA BASE
ALTER WORKLOAD ステートメントを毎回実行することによって、複数のワークロードのデータを収集できます。残りのステップは同じです。ただし、ステップ 5 は例外で、照会を以下のように変更します。
SELECT E.WORKLOAD_NAME,
SUM(M.TOTAL_CPU_TIME) AS CPU_TIME
FROM UOW_EVENT E, UOW_METRICS M
WHERE M.APPLICATION_ID = E.APPLICATION_ID
AND M.UOW_ID = E.UOW_ID
AND M.MEMBER = E.MEMBER
GROUP BY E.WORKLOAD_NAME
ORDER BY CPU_TIME DESC
前述のステートメントによって、メトリック収集が有効になっていたそれぞれのワークロードの CPU 時間がレポートされます。WORKLOAD CPU_TIME
------------------------------ --------------------
PAYROLL 2143292042
MARKETING 492784916
2 record(s) selected.