[Lab [Lab 6 666]]]] モモモモニタリングニタリング実行例 _表の作成下記のコマンドを実行して、表及び索引を作成します。表及び索引のDDL

[Lab [Lab [Lab [Lab 6666]]]]

モモモモニタリングニタリングニタリングニタリング

2

Contents

CONTENTS ............................................................................................................. 2

1. はじめにはじめにはじめにはじめに .................................................................................................... 3

2. データの投入と抽出データの投入と抽出データの投入と抽出データの投入と抽出 ................................................................................... 3

2.1 ハンズオン用データベースの作成 .......................................................... 3

2.2 表スペース、表、索引の作成 .................................................................. 4

2.3 データの投入 ......................................................................................... 6

2.4 投入したデータの EXPORT ..................................................................... 7

3. 統計情報の収集と再編成統計情報の収集と再編成統計情報の収集と再編成統計情報の収集と再編成 .......................................................................... 8

3.1 統計情報の収集 .................................................................................... 8

3.2 表の再編成 ........................................................................................... 9

4. データベースのモニタリングデータベースのモニタリングデータベースのモニタリングデータベースのモニタリング ..................................................................... 12

4.1 負荷ツールの起動 ............................................................................... 12

4.2 db2top によるモニタリング ..................................................................... 12

4.3 Snapshot によるモニタリング ................................................................. 15

4.3.1 手動による Snapshotの取得 .......................................................... 15

4.3.2 スクリプトによる Snapshot の取得 ............................................. 17

5. 問題判別：問題判別：問題判別：問題判別：ロック・タイムアウトロック・タイムアウトロック・タイムアウトロック・タイムアウト .................................................................. 19

5.1 準備 .................................................................................................... 19

5.2 ロック・タイムアウト発生 ....................................................................... 19

5.3 問題判別 ............................................................................................. 21

5.3.1 db2pd による問題判別 ........................................................................... 22

6. モニター表関数を使用したモニタリングモニター表関数を使用したモニタリングモニター表関数を使用したモニタリングモニター表関数を使用したモニタリング ..................................................... 25

6.1 負荷ツールの起動 ............................................................................... 25

6.2 モニター表関数によるモニタリング ........................................................ 26

3

1. はじめにはじめにはじめにはじめに

このハンズオンでは、ベンチマークツール用のデータベース構築を通じて下記のタスクを実践

します。

� データの投入・抽出

� 統計情報の収集と再編成

� データベースのモニタリング

� 問題判別：ロック・タイムアウト

� モニター表関数を使用したモニタリング

このハンズオンは、db2inst1 ユーザーで行います。下記のコマンドを実行して db2inst1

ユーザーにスイッチし、DB2 インスタンスを起動してください。パスワードは「db2inst1」です。 su – db2inst1 db2start

2. データの投入と抽出データの投入と抽出データの投入と抽出データの投入と抽出

このセクションでは、ハンズオン用データベースの作成と、データベース/オブジェクトの作成、

データの投入を行います。データの投入には LOAD ユーティリティを使用します。

2.1 ハンズオン用データベースの作成ハンズオン用データベースの作成ハンズオン用データベースの作成ハンズオン用データベースの作成

＿データベース作成

下記のコマンドでハンズオン用のデータベースを作成します。 db2 create database lab6 on /db2data1, /db2data2 dbpath on /db2

実行例

このコマンド実行例では、ON キーワードに/db2data1、/db2data2 の 2 つのディレクトリを

指定し、DBPATH ON キーワードに/db2 を指定しています。ON キーワードで指定された

/db2data1,/db2data2は自動ストレージパスとして登録され、この 2 つのディレクトリ配

下に表スペースが作成されることになります。

本番システムではディレクトリではなく、独立した物理ディスク上にファイルシステムを作成して

使用します。複数のディスク領域を自動ストレージパスとして使用する場合、それぞれの領域

db2inst1@db2V97onSLES10:/workshop/lab6> db2 create database lab6 on /db2data1, /db2data2 dbpath on /db2

DB20000I CREATE DATABASE コマンドが正常に完了しました。

4

が同等の性能となるように注意してください。性能の劣るディスク領域が含まれていた場合、全

体がそのディスク領域の性能に足並みをそろえることになります。

＿作成したデータベースの確認

下記のコマンドで、データベースが作成されていることを確認してください。また、/db2data1,

/db2data2 ディレクトリを ls コマンドで参照すると、データベース用のファイルが作成されて

いることが確認できます。 db2 list db directory

実行例

2.2 表スペース、表、索引の作成表スペース、表、索引の作成表スペース、表、索引の作成表スペース、表、索引の作成

＿表スペースの作成

下記のコマンドを実行して、表スペースを作成します。 db2 connect to lab6 db2 create tablespace ts1 db2 create tablespace its1

このセクションで使用する LAB6 データベースでは自動ストレージを使用するため、表スペース

作成時には表スペース・コンテナを指定しません。コンテナ指定なしで CREATE

TABLESPACE を実行すると、/db2data1,/db2data2 配下に DB2管理の表スペース・コ

ンテナが作成されます。

実行例

＿表スペースの確認

下記のコマンドを実行して、2 つの表スペースが正しく作成されていることを確認します。 db2 list tablespaces show detail

db2inst1@db2V97onSLES10:/workshop/lab6> db2 connect to lab6

<省略> db2inst1@db2V97onSLES10:/workshop/lab6> db2 create tablespace ts1

DB20000I SQL コマンドが正常に完了しました。 db2inst1@db2V97onSLES10:/workshop/lab6> db2 create tablespace its1

DB20000I SQL コマンドが正常に完了しました。

db2inst1@db2V97onSLES10:/workshop/lab6> db2 list db directory

システム・データベース・ディレクトリー

<省略>

データベース別名 = LAB6

データベース名 = LAB6

ローカル・データベース・ディレクトリー = /db2

データベース・リリース・レベル = d.00

<省略>

5

実行例

＿表の作成

下記のコマンドを実行して、表及び索引を作成します。表及び索引の DDLは

/workshop/lab6 ディレクトリの「01.crt_tbl.ddl」ファイルに保管されています。このス

クリプトの内容を確認後、下記のようにして実行してください。 db2 -tvf 01.crt_tbl.ddl

実行例

db2inst1@db2V97onSLES10:/workshop/lab6> db2 -tvf 01.crt_tbl.ddl connect to lab6

<省略> CREATE TABLE warehouse ( w_id INTEGER, w_name VARCHAR(10), w_street_1 VARCHAR(20), w_street_2 VARCHAR(20), w_city VARCHAR(20), w_state CHAR(2), w_zip CHAR(9), w_tax DECIMAL(4,4), w_ytd DECIMAL(12,2)) in ts1 index in its1

DB20000I SQL コマンドが正常に完了しました。 CREATE TABLE district ( d_id INTEGER, d_w_id INTEGER, d_name VARCHAR(10), d_street_1 VARCHAR(20), d_street_2 VARCHAR(20), d_city VARCHAR(20), d_state CHAR(2), d_zip CHAR(9), d_tax DECIMAL(4,4), d_ytd DECIMAL(12,2), d_next_o_id INT ) in ts1 index in its1

DB20000I SQL コマンドが正常に完了しました。 CREATE TABLE history ( h_c_id INT, h_c_d_id INT, h_c_w_id INT, h_d_id INT, h_w_id INT, h_date DATE, h_amount DECIMAL(6), h_data VARCHAR(24)) in ts1 index in its1


<省略>

db2inst1@db2V97onSLES10:/workshop/lab6> db2 list tablespaces show detail

現在のデータベースの表スペース

<省略>

表スペース ID = 3

名前名前名前名前 = TS1= TS1= TS1= TS1

タイプ = データベース管理スペース

内容 = すべての永続データ。 LARGE 表スペース。

状態 = 0x0000

詳しい説明:

正常

合計ページ数 = 8192

使用できるページ数 = 8128

使用したページ = 672

フリー・ページ = 7456

最高水準点 (ページ) = 672

ページ・サイズ (バイト) = 4096

エクステント・サイズ (ページ) = 32

プリフェッチ・サイズ (ページ) = 64

コンテナー数 = 2

<省略>

6

＿索引の作成

表と同様にして索引を作成します。 db2 -tvf 02.crt_index.ddl

実行例

＿作成済み DDL の確認

list tables コマンドを使用して、作成された表の一覧を確認します。全ての表が正常に作

成された場合、9 エントリ出力されます。 db2 connect to lab6 db2 list tables

実行例

2.3 データの投入データの投入データの投入データの投入

前セクションで表及び索引を作成しました。このセクションでは、作成した表に対してデータの

投入を行います。下記のコマンドを使用して表にデータを LOAD してください。 db2 –tvf 03.load.ddl

db2inst1@DB2V97onSLES10:/workshop/lab6> db2 connect to lab6

<省略>

db2inst1@db2V97onSLES10:/workshop/lab6> db2 list tables

表/ビュースキーマタイプ作成時刻

------------------------------- --------------- ----- --------------------------

CUSTOMER DB2INST1 T 2009-08-11-05.29.13.449259

DISTRICT DB2INST1 T 2009-08-11-05.29.13.159791

HISTORY DB2INST1 T 2009-08-11-05.29.13.230147

ITEM DB2INST1 T 2009-08-11-05.29.13.508594

NEW_ORDER DB2INST1 T 2009-08-11-05.29.13.338742

ORDERS DB2INST1 T 2009-08-11-05.29.13.305574

ORDER_LINE DB2INST1 T 2009-08-11-05.29.13.395214

STOCK DB2INST1 T 2009-08-11-05.29.13.474094

WAREHOUSE DB2INST1 T 2009-08-11-05.29.12.562558

9 レコードが選択されました。

db2inst1@db2V97onSLES10:/workshop/lab6> db2 -tvf 02.crt_index.ddl connect to lab6

<省略> CREATE UNIQUE INDEX iwarehouse ON warehouse(w_id) PCTFREE 10

DB20000I SQL コマンドが正常に完了しました。 CREATE UNIQUE INDEX idistrict ON district(d_w_id,d_id) CLUSTER PCTFREE 10

DB20000I SQL コマンドが正常に完了しました。 CREATE INDEX iorders1 ON orders(o_w_id,o_d_id,o_id) PCTFREE 10


<省略>

7

各表への LOAD に必要なデータは/data ディレクトリにあります。

ファイル名テーブル名

./data/warehouse.tbl warehouse

./data/district.tbl district

./data/customer.tbl customer

./data/stock.tbl stock

./data/item.tbl item

2.4 投入したデータの投入したデータの投入したデータの投入したデータの EXPORT

表に格納されたデータは EXPORT コマンドで抽出することができます。抽出対象のデータは

SQL で記述します。抽出条件の限定は SQLの WHERE句で行います。 db2 connect to lab6 db2 "export to low_stock.del of del select * from stock where s_quantity < 20"

例えば上記のコマンドでは、STOCK 表から S_QUANTITY（在庫量）が 20 以下となっているレ

コードのみを抽出します。

実行例


<省略>

db2inst1@db2V97onSLES10:/workshop/lab6> db2 "export to low_stock.del of del select * from

stock where s_quantity < 20"

SQL3104N エクスポート・ユーティリティーが、ファイル

"low_stock.del" へのデータのエクスポートを開始しています。

SQL3105N エクスポート・ユーティリティーが、"11063"行のエクスポートを完了しました。

8

3. 統計情報の収集と再編成統計情報の収集と再編成統計情報の収集と再編成統計情報の収集と再編成

このセクションでは、表に対する統計情報の収集と再編成の演習を行います。

3.1 統計情報の収集統計情報の収集統計情報の収集統計情報の収集

統計情報の収集には RUNSTATS コマンドを使用します。統計情報の更新が必要となる事象に

は大量データの更新や索引の追加等があげられますが、本番運用では個別に必要性を判断

するよりも、全てのテーブルに対して定期的に取得するケースが多くなります。定期的に取得

する場合の周期については、データの更新頻度から判断します。基本的な考え方は「テーブル

全体の 20%が更新・追加される前には統計情報を更新する」です。この考え方に基づいて、統

計情報収集の周期（日次・週次・月次等）を決定してください。

＿前回統計情報を収集した時刻を確認

下記のコマンドを使用して、そのテーブルに対して前回統計情報が収集された時刻を取得でき

ます。統計情報を取得したことがない表に対しては、「- （ヌル値）」が出力されます。

※すべての表で※すべての表で※すべての表で※すべての表で- （ヌル値（ヌル値（ヌル値（ヌル値））））が取得される場合があります。その場合は、次項「が取得される場合があります。その場合は、次項「が取得される場合があります。その場合は、次項「が取得される場合があります。その場合は、次項「_統計情報の統計情報の統計情報の統計情報の

収集」をご参照いただき、コマンドを実行して、各表の統計収集を行います。収集」をご参照いただき、コマンドを実行して、各表の統計収集を行います。収集」をご参照いただき、コマンドを実行して、各表の統計収集を行います。収集」をご参照いただき、コマンドを実行して、各表の統計収集を行います。 db2 "select substr(tabname,1,20) table , stats_time from syscat.tables where tabschema='DB2INST1'"

実行例

演習で使用するデータベースでは、リアルタイム RUNSTATS 及び自動 RUNSTATS が有効に

なっているため、統計情報が収集されていない表に対して SQLが実行されると、順次統計情

報の自動収集が行われます。そのため、明示的な RUNSTATS を行っていなくても、統計情報

の収集時刻は更新されることになります。

db2inst1@db2V97onSLES10:/workshop/lab6> db2 "select substr(tabname,1,20) table , stats_time from syscat.tables where tabschema='DB2INST1'" TABLE STATS_TIME -------------------- -------------------------- WAREHOUSE 2009-08-11-07.11.23.168924 DISTRICT 2009-08-11-07.11.23.304731 HISTORY - ORDERS 2009-08-11-07.07.49.655276 NEW_ORDER 2009-08-11-07.07.49.922659 ORDER_LINE 2009-08-11-07.07.50.032274 CUSTOMER 2009-08-11-07.27.51.829330 STOCK 2009-08-11-07.27.50.759330 ITEM 2009-08-11-07.11.30.126756


9

＿統計情報の収集

上記の実行例では、HISTORY 表に対しては統計情報が収集されていないため、下記のコマン

ドを使用して収集を行います。 db2 runstats on table db2inst1.history and indexes all

実行例

＿更新された統計情報を確認

再度、統計情報の収集時刻を取得し、RUNSTATSが行われたことを確認します。 db2 "select substr(tabname,1,20) table , stats_time from syscat.tables where tabschema='DB2INST1'"

実行例

3.2 表の再編成表の再編成表の再編成表の再編成

＿REORGCHK コマンドによる表の状態確認

REORGCHK は表のフラグメントの状態や、データの物理的な並び順を取得することで、再編成

の必要性を確認するためのコマンドです。デフォルトオプションで REORGCHK コマンドを実行す

ると、内部的に RUNSTATS を実行して統計情報を更新します。本番環境等で、統計情報の更

新が望ましくない場合、CURRENT STATISTICS オプションを追加して実行してください。

今回のハンズオンではデフォルトオプションで実行し、統計情報を更新します。 db2 reorgchk on table db2inst1.customer

（参考）統計情報を更新しない REORGCHK コマンド db2 reorgchk current statistics on table db2inst1.customer

db2inst1@db2V97onSLES10:/workshop/lab6> db2 "select substr(tabname,1,20) table , stats_time from syscat.tables where tabschema='DB2INST1'" TABLE STATS_TIME -------------------- -------------------------- WAREHOUSE 2009-08-11-07.11.23.168924 DISTRICT 2009-08-11-07.11.23.304731 HISTORY 2009-08-11-09.46.21.451662 ORDERS 2009-08-11-07.07.49.655276 NEW_ORDER 2009-08-11-07.07.49.922659 ORDER_LINE 2009-08-11-07.07.50.032274 CUSTOMER 2009-08-11-07.47.49.607305 STOCK 2009-08-11-07.27.50.759330 ITEM 2009-08-11-07.11.30.126756


db2inst1@db2V97onSLES10:/workshop/lab6> db2 runstats on table db2inst1.history and indexes all

DB20000I RUNSTATS コマンドが正常に完了しました。

10

実行例

REORGCHK コマンドの出力には、F1 から F8 までの公式に基づいた算出結果から、再編成を

推奨するかどうかが含まれます。公式の算出結果が実線（赤線）で囲まれた部分、その結果再

編成を推奨するかどうかが、波線（青線）で囲まれた部分です。CUSTOMER表の結果からは、

ICUSTOMER 表の F4（クラスター率）が 6%と低く、再編成が推奨されています。

参考：主な表の公式

公式 F1 ：オーバーフロー行の合計数。

5%を越える場合、再編成が推奨される。

公式 F3 ：割り当てられたページの内、使用されていないページの割合。

20%を上回る場合、再編成が推奨される。

db2inst1@db2V97onSLES10:/workshop/lab6> db2 reorgchk on table db2inst1.customer

RUNSTATS 中....

表統計:

<省略> SCHEMA.NAME CARD OV NP FP ACTBLK TSIZE F1 F2 F3 REORG ----------------------------------------------------------------------------------

表: DB2INST1.CUSTOMER 30000 0 4937 4938 - 18150000 0 91 100 --- ----------------------------------------------------------------------------------

索引統計:

<省略> SCHEMA.NAME INDCARD LEAF ELEAF LVLS NDEL KEYS LEAF_RECSIZE --------------------------------------------------------------------------------

表: DB2INST1.CUSTOMER

索引: DB2INST1.ICUSTOMER 30000 484 0 3 0 30000 45 --------------------------------------------------------------------------------

右上より 1→ NLEAF_RECSIZE LEAF_PAGE_OVERHEAD NLEAF_PAGE_OVERHEAD PCT_PAGES_SAVED

右上より 1→ ----------------------------------------------------------------------

右上より 1→

右上より 1→

右上より 1→ 45 416 416 0

右上より 1→ ----------------------------------------------------------------------

右上より 2→ F4 F5 F6 F7 F8 REORG

右上より 2→ ------------------------

右上より 2→

右上より 2→

右上より 2→ 6 91 11 0 0 *----

右上より 2→ ------------------------

<省略>

11

＿表の再編成

索引 ICUSTOMER の公式 F4（クラスター率）が 6%と低いことがわかったので、下記のコマンド

を使用して再編成を行います。下記の例では、INDEX キーワードで ICUSTOMER 索引を指定

しています。これは、再編成時の基準となる並び順を、ICUSTOMER 索引を用いて決定するこ

とを意味します。 db2 reorg table db2inst1.customer index icustomer

実行例

＿索引の再編成

再編成の完了後に、再度 REORGCHK コマンドを実行し、ICUSTOMER 索引のクラスター率

（F4）が向上していることを確認します。

実行例

SCHEMA.NAME INDCARD <省略> F4 F5 F6 F7 F8 REORG

-------------------------------- <省略> ---------------------------

表: DB2INST1.CUSTOMER <省略>

索引: DB2INST1.ICUSTOMER <省略>

30000 <省略> 100 91 11 0 0 -----

-------------------------------- <省略> ---------------------------

db2inst1@db2V97onSLES10:/workshop/lab6 > db2 reorg table db2inst1.customer index icustomer

DB20000I REORG コマンドが正常に完了しました。

参考：主な索引の公式

公式 F4 ：索引のクラスター率（索引キーの値の順番に物理的に並んでいるかどうか）

一つの表に複数の索引が存在する場合、一方のクラスター率が上がると、

他の索引のクラスターリングが下がる関係にある場合が多い。

重要な索引のクラスター率が高いことを確認する。80%を下回る場合、

再編成が推奨される。

公式 F6 ：再編成によって索引の階層が下げられる可能性がある。

F6 にフラグが立っている場合、対象索引の再編成が推奨される。

公式 F7,F8：物理削除により疑似削除ページや疑似削除キーがどの程度存在しているか。

再編成により索引サイズが縮小できるため、

20%を越えている場合は再編成が推奨される。

12

4. データベースのモニタリングデータベースのモニタリングデータベースのモニタリングデータベースのモニタリング

このセクションでは、データベースのモニタリングに関するハンズオンを行います。ハンズオン

の対象は、「db2top によるリアルタイムでのモニタリング」及び、テキストベースでの網羅的な

取得が可能な「Snapshot コマンドによる Snapshot monitor のデータ取得」の 2 種類で

す。

4.1 負荷ツールの起動負荷ツールの起動負荷ツールの起動負荷ツールの起動

一定の負荷がかかった状態でモニタリングを行うため、データベースに対して負荷を与えるツ

ールを稼働させます。このツールは約 5 分間稼働します。モニタリングのハンズオンを行って

いる途中で負荷ツールが終了した場合、再度起動してください。ツールの稼働中にハンズオン

が終了した場合、Ctrl+C によって途中で終了することが可能です。

＿下記のコマンドを実行し、負荷ツールを起動してください。 cd /workshop/lab6/java ./go.sh tpcc.cfg

実行例

「Stress Start」のメッセージの後ハイフン記号が出力され始めたら、データベースへの負荷が開

始されています。

4.2 db2top によるモニタリングによるモニタリングによるモニタリングによるモニタリング

＿db2top の起動

新しいターミナルを起動し、db2inst1 ユーザーにスイッチし、db2inst1下記のコマンドを

実行してください。正しく実行できると db2topが起動します。 su – db2inst1 db2top –d lab6

db2inst1@db2V97onSLES10:/workshop/lab6> cd /workshop/lab6/java db2inst1@db2V97onSLES10:/workshop/lab6/java> ./go.sh tpcc.cfg STRESSARG=-clients 5 -minutes 5 -tm_scenario 0 -tm_transaction 0 -tm_query 0 -url jdbc:db2:lab6 -userid db2inst1 -password db2inst1 TPCCClient Logdir = log/0811_2206 TARGETHOST=db2V97onSLES10 Waiting 5 seconds OLTPStress - OLTP type stress tool using JDBC Version 1.30 2003/05/16 [Stress Start 2009/08/11 22:06:10] -------------------------------------------------------

13

起動画面例

＿データベース活動のモニタリング

db2top の起動画面で「d」を入力し、データベース活動のモニタリング画面へ移動してください。

下記のような情報が出力されます。

データベース活動のモニタリング

負荷が正常にかかっている場合、複数の項目で値の変動が見られます。

14

主な出力項目とその意味

主な出力項目とその意味

・Buffers

バッファープールの合計容量を表します。STMM 環境下では、バッファープールのサイズ

は動的に変動します。

・L_Reads、P_Reads、HitRatio：

L_Reads はバッファープールからの論理的な読み込みを指し、P_Reads はディスクか

らバッファープールへの物理的な読み込みを指します。この比率が「バッファープール・ヒ

ット率」と呼ばれ、データベースの性能を維持するために重要な指標です。上の例では、

ヒット率が約 95.7%と効率の良い読み込みが行われています。

・LockUsed、LockEscals、Deadlocks、Lock Wait

この 4 点はロック関連の指標を表します。LockEscals はロックエスカレーション（行ロ

ックから表ロックへの変換）の発生回数、Deadlocksはデッドロックの発生回数、Lock

Wait はロック待ちの発生回数を表します。ロックエスカレーションやデッドロックが発生し

ている場合、アプリケーションの並行性に問題がある可能性があるため、注意してくださ

い。

・AvgPRdTime、AvgDRdTime、AvgPWrTime、AvgDWrTime

これらの指標は、ディスク I/O に要した時間を表します。PRd が物理読み込み

（Physical Reads）、DRd が直接読み込み（Direct Reads）、PWr が物理書き込み

（Physical writes）、DWrが直接書き込み（Direct write）を指します。直接読み

込み、直接書き込みとは、バックアップやラージオブジェクトのアクセス等、バッファープー

ルを経由しない I/O 活動を指します。

＿その他のモニタリング項目

db2topはデータベース全体以外にも、様々な切り口でデータベースの活動をモニタリング可

能です。代表的な切り口としてアプリケーション・セッション（「l」で選択）、バッファープール

（「b」で選択）、テーブルスペース（「t」で選択）等があります。「h」を選択すると選択可能なオプ

ションが表示されるため、それを参考にしながら様々な切り口を試してください。

Start Date Start Time Status Shthres Buffers FCMBuf OtherMem 2009/08/11 19:57:05 Active 0 26.0M 768.0K 51.9M Sessions ActSess LockUsed LockEscals Deadlocks LogReads LogWrites 16 6 0% 0 0 0 9 L_Reads P_Reads HitRatio A_Reads Writes A_Writes Lock Wait 813 34 95.71% 0.00% 0 0 4 Sortheap SortOvf PctSortOvf AvgPRdTime AvgDRdTime AvgPWrTime AvgDWrTime 16.0K 0 0.00% 100.78 0.00 0.00 0.00

15

4.3 Snapshot によるモニタリングによるモニタリングによるモニタリングによるモニタリング

前のセクションでは db2top によるリアルタイムでのモニタリングを行いましたが、このセクショ

ンでは Snapshot による蓄積的なモニタリングを行います。蓄積的なモニタリングの目的とし

ては、「通常稼働時から定期的に取得し問題が発生した場合に平常稼働時との差異を迅速に

特定すること」や、「システム構築時のテスト等でデータベースのパフォーマンス情報を詳細に

解析すること」などが挙げられます。

4.3.1 手動による手動による手動による手動による Snapshot の取得の取得の取得の取得

Snapshot 情報の取得は、下記のような流れで実施します。Snapshot情報はデータベース

が活動を開始してからの累積値として出力されるため、そのままでは目的とする期間の情報の

みを取り出すことが困難です。そのため、モニターのリセットを行い、一定期間待ってから

Snapshot を取得します。Snapshot にはモニターのリセットから Snapshot取得までの期

間の活動が出力されることになります。

モニタースイッチの活動化

モニターのリセット

WAIT

Snapshotコマンドによる

情報の取得

db2 update monitor switches using bufferpool on

db2 reset monitor all

sleep 60 (1分間のWait）

db2 get snapshot for database on lab2

この間

の活

動が記

録され

る

＿負荷状況の確認

負荷ツールがまだ稼働していることを確認し、稼働していない場合は再度負荷ツールを起動し

てください。

＿モニタースイッチの設定

下記のコマンドを使用して、全てのモニタースイッチを有効にしてください。 db2 get monitor switches db2 update monitor switches using bufferpool on lock on sort on statement on table on uow on db2 get monitor switches

モニタースイッチとは DB2のモニタリング項目について、情報を収集するかどうかを決定する

ためのパラメーターです。設定に関わりなく収集される BASE に加えて、属性ごとにグルーピン

グされたモニタースイッチが 7 項目あります（バッファープール、ロック、ソート、動的 SQL、テー

ブル、時刻、UOW）。DBM構成パラメーターを使用してインスタンス単位で有効にすることも可能

16

ですが、この演習で UPDATE MONITOR SWITCH コマンドを使用してセッション単位で有効に

します。

実行例

＿モニターのリセットと Sleep、Snapshot の取得

RESET MONITOR コマンドで、一旦 Snapshot Monitor の指標をリセットします。その後

30 秒間 sleep し、30 秒分の活動情報が蓄積された時点で Snapshot を取得します。 db2 reset monitor all sleep 30 db2 get snapshot for database on lab6

実行例

db2inst1@db2V97onSLES10:~> db2 reset monitor all

DB20000I RESET MONITOR コマンドが正常に完了しました。

db2inst1@db2V97onSLES10:~> sleep 30

db2inst1@db2V97onSLES10:~> db2 get snapshot for database on lab6

データベース・スナップショット

データベース名 = LAB6

データベース・パス = /db2/db2inst1/NODE00 00/SQL00005/

入力データベース別名 = LAB6

データベース状況 = アクティブ

<省略>

db2inst1@db2V97onSLES10:~> db2 get monitor switches

モニター記録スイッチ

DB パーティション番号 0 のスイッチ・リスト

バッファー・プール・アクティビティー情報 (BUFFERPOOL) = OFF

ロック情報 (LOCK) = OFF

ソート情報 (SORT) = OFF

SQL ステートメント情報 (STATEMENT) = OFF

表アクティビティー情報 (TABLE) = OFF

タイム・スタンプ情報を取る (TIMESTAMP) = ON 2009-08-11 19:55:19.130673

作業単位情報 (UOW) = OFF

db2inst1@db2V97onSLES10:~> db2 update monitor switches using bufferpool on lock on sort on statement on

table on uow on

DB20000I UPDATE MONITOR SWITCHES コマンドが正常に完了しました。

db2inst1@db2V97onSLES10:~> db2 get monitor switches



バッファー・プール・アクティビティー情報 (BUFFERPOOL) = ON 2009-08-11 23:19:54.623408

ロック情報 (LOCK) = ON 2009-08-11 23:19:54.623408

ソート情報 (SORT) = ON 2009-08-11 23:19:54.623408

SQL ステートメント情報 (STATEMENT) = ON 2009-08-11 23:19:54.623408

表アクティビティー情報 (TABLE) = ON 2009-08-11 23:19:54.623408


作業単位情報 (UOW) = ON 2009-08-11 23:19:54.623408

17

4.3.2 スクリプトによるスクリプトによるスクリプトによるスクリプトによる Snapshot の取得の取得の取得の取得

本番運用での Snapshot の取得は、オペレーションの単純化や取得の自動化のため、スクリ

プトで行うケースが多くなります。このハンズオンでは、シンプルなサンプルスクリプトによる自

動取得を行います。

＿負荷状況の確認

負荷ツールがまだ稼働していることを確認し、稼働していない場合は再度負荷ツールを起動し

てください。

＿スクリプトの起動

下記のコマンドを実行し、サンプルスクリプトを起動してください。 cd /workshop/lab6/snapshot ./snapshot.sh lab6 10 3

サンプルスクリプトの書式は下記の通りです。

./snapshot.sh <DB名称> [取得間隔（秒）] [取得回数]

上記のコマンドでは、10 秒間隔で 3回取得することになります。

実行例

db2inst1@db2V97onSLES10:/workshop/lab6/snapshot> ./snapshot.sh lab6 10 3

Target DB :lab6

interval :10

Repeat Count :3

Snapshot Mode :ALL

Monitor switches:

DB20000I UPDATE MONITOR SWITCHES コマンドが正常に完了しました。



バッファー・プール・アクティビティー情報 (BUFFERPOOL) = ON 2009-08-11 23:46:57.705511

ロック情報 (LOCK) = ON 2009-08-11 23:46:57.705511

ソート情報 (SORT) = ON 2009-08-11 23:46:57.705511

SQL ステートメント情報 (STATEMENT) = ON 2009-08-11 23:46:57.705511

表アクティビティー情報 (TABLE) = ON 2009-08-11 23:46:57.705511


作業単位情報 (UOW) = OFF


Repeat count :1/3 Interval :10





18

＿出力ファイルの確認

スクリプトが出力したファイルを確認します。このサンプルスクリプトは、実行時のタイムスタン

プが付加されたファイルを 2 種類出力します。1 つめはデータベース・マネージャー・スナップ

ショットの出力ファイル、もう一つはデータベース・スナップショットです。複数回の取得を行った

場合、複数回分の出力が一つのファイルに出力されます。

実行例

db2inst1@DB2V97onSLES10:/workshop/lab6/snapshot> ls -l

合計 1722 -rw-r--r-- 1 db2inst1 staff 1734836 2010-02-09 10:49 snapshot.20100209_104819.all.log -rw-r--r-- 1 db2inst1 staff 15585 2010-02-09 10:49 snapshot.20100209_104819.dbm.log -rwxr-xr-x 1 db2inst1 staff 288 2010-02-09 10:39 snapshot.cfg -rwxr-xr-x 1 db2inst1 staff 1859 2010-02-09 10:39 snapshot.sh

19

5. 問問問問題判別：題判別：題判別：題判別：ロック・タイムアウトロック・タイムアウトロック・タイムアウトロック・タイムアウト

このセクションでは、意図的にロック・タイムアウトを発生させ、どのアプリケーションのどの

SQL がロック競合になっているかの問題判別を行います。

5.1 準備準備準備準備

まず、ロック対象となる表を作成し数件データを挿入します。 db2 connect to lab6 db2 “create table locktbl (c1 int, c2 char(10))” db2 “insert into locktbl values(1,’DATA1’),(2,’DATA2’),(3,’DATA3’)” db2 “select * from locktbl”

実行例

5.2 ロック・タイムアウトロック・タイムアウトロック・タイムアウトロック・タイムアウト発生発生発生発生

このセクションでは 2 つのアプリケーションによりロック・タイムアウトを発生させるため、アプリ

ケーション用のターミナルを 2 つ用意してください。また問題判別のためのターミナルを 1 つ用

意してください。


データベース接続情報

データベース・サーバー = DB2/LINUX 9.7.0

SQL 許可 ID = DB2INST1

ローカル・データベース別名 = LAB6 db2inst1@DB2V97onSLES10:/workshop/lab6> db2 "create table locktbl(c1 int, c2 char(10))"

DB20000I SQL コマンドが正常に完了しました。 db2inst1@DB2V97onSLES10:/workshop/lab6> db2 "insert into locktbl values(1,'DATA1'),(2,'DATA2'),(3,'DATA3')"

DB20000I SQL コマンドが正常に完了しました。 db2inst1@DB2V97onSLES10:/workshop/lab6> db2 "select * from locktbl" C1 C2 ----------- ---------- 1 DATA1 2 DATA2 3 DATA3


20

各ターミナルを以下のように呼ぶことにします。

アプリケーション１ ⇒ ターミナル１

アプリケーション２ ⇒ ターミナル２

問題判別 ⇒ ターミナル３

＿ロック・タイムアウト時間の設定

まずは、ロック・タイムアウトになることを確認するために、ターミナル２においてロック・タイムア

ウト時間を短めに 5 秒を設定します。 db2 connect to lab6 db2 set current lock timeout 5

実行例@ターミナル２

＿ロック競合を発生させる

ターミナル１にて、未コミットでデータを 1 件 DELETE します。 db2 connect to lab6 db2 +c “delete from locktbl where c1=1”

実行例@ターミナル１

ターミナル 2 にて、未コミットでデータを全件 UPDATE します。 db2 +c “update locktbl set c2=’APPL2’”

この SQL を実行すると応答が無くなり、5 秒後にロック・タイムアウトのエラーが出力されます。


SQL0911N Readon Code = 68 は、ロック・タイムアウトによりトランザクションがロールバ

ックされたエラーであることが分かります。 db2 ? sql0911

db2inst1@DB2V97onSLES10:/workshop/lab6> db2 +c "update locktbl set c2='APPL2'"

<5 秒後>

DB21034E コマンドが、有効なコマンド行プロセッサー・コマ

ンドでないため、SQL

ステートメントとして処理されました。SQL

処理中に、次のエラーが返されました。

SQL0911N デッドロックまたはタイムアウトのため、現在のト

ランザクションがロールバックされました。理由コード “68” SQLSTATE=40001


<省略> db2inst1@DB2V97onSLES10:/workshop/lab6> db2 +c "delete from locktbl where c1=1"



<省略> db2inst1@DB2V97onSLES10:/workshop/lab6> db2 set current lock timeout 5


21


ターミナル 1 で処理をロールバックさせてください。 db2 rollback


5.3 問題判別問題判別問題判別問題判別

前セクションと同じ状況を再現させ、ロック競合に関する問題判別を行います。

＿ロック・タイムアウト時間を変更する＠ターミナル２

問題判別の便査上、ロック・タイムアウトの時間を無限に設定します。 db2 set current lock timeout -1


＿ロック競合を発生させる

ターミナル１にて、未コミットでデータを 1 件 DELETE します。 db2 +c “delete from locktbl where c1=1”


ターミナル 2 にて、未コミットでデータを全件 UPDATE します。 db2 +c “update locktbl set c2=’APPL2’”

db2inst1@DB2V97onSLES10:/workshop/lab6> db2 rollback


db2inst1@DB2V97onSLES10:/workshop/lab6> db2 +c "delete from locktbl where c1=1"


db2inst1@DB2V97onSLES10:/workshop/lab6> db2 set current lock timeout -1


db2inst1@DB2V97onSLES10:/workshop/lab6> db2 ? sql0911

SQL0911N デッドロックまたはタイムアウトのため、現在のトランザ

クションがロールバックされました。理由コード "<reason-code>"

説明:

現在の作業単位が、オブジェクトの使用について、未解決競合状になったた

ために、ロールバックされました。

理由コードは以下のとおりです。

＜省略＞ 68

ロック・タイムアウトのために、トランザクションがロールバックされました。

＜省略＞

22


ターミナル２ではプロンプトが返ってこないため、この間、問題判別を行います。

5.3.1 db2pd による問題判別による問題判別による問題判別による問題判別

ターミナル３にて db2pd コマンドを実行して、ロック状況を分析します。

出力が多いため、ターミナル・ウィンドゥを横に長くしてください。

＿取得されているロック情報を参照します。 db2pd –d lab6 –lock showlocks

実行例@ターミナル３

TranHdl 列：トランザクションのハンドル

Sts ：ロックのステータス(G：保有している W：Wait している)

Owner ：ロックを保持している所有者

db2inst1@DB2V97onSLES10:~> db2pd -d lab6 -lock showlocks Database Partition 4294967295 -- Database LAB6 -- Active -- Up 0 days 00:06:00 Locks: Address TranHdl Lockname Type Mode Sts Owner Dur HoldCount Att ReleaseFlg rrIID 0xA09FE180 9 01000000010000000100A04E56 Internal V ..S G 9 1 0 0x00000000 0x40000000 0 Anchor 629 Stmt 1 Env 1 Var 1 Loading 0 0xA09F3A80 2 00000100040000000000000052 Row ..X G 2 1 0 0x00000000 0x40000000 0 TbspaceID 0 TableID 1 PartitionID 0 Page 0 Slot 4 0xA09B7500 2 01000000010000000100C05256 Internal V ..S G 2 1 0 0x00000000 0x40000000 0 Anchor 662 Stmt 1 Env 1 Var 1 Loading 0 0xA09B5080 2 41414141415A425A7F4760B841 Internal P ..S G 2 1 0 0x00000000 0x40000000 0 Pkg UniqueID 41414141 5a425a41 Name b860477f Loading = 0 0xA09FE380 9 41414141415A425A7F4760B841 Internal P ..S G 9 1 0 0x00000000 0x40000000 0 Pkg UniqueID 41414141 5a425a41 Name b860477f Loading = 0 0xA09C5580 2 04000D00040000000000000052 Row ..X G 2 1 0 0x00000020 0x40000000 0 TbspaceID 4 TableID 13 PartitionID 0 Page 0 Slot 4 0xA09FE280 9 04000D00040000000000000052 Row ..X W 2 1 0 0x00000000 0x40000000 0 TbspaceID 4 TableID 13 PartitionID 0 Page 0 Slot 4 0xA09B3580 2 434F4E544F4B4E3128DD630641 Internal P ..S G 2 1 0 0x00000000 0x40000000 0 Pkg UniqueID 544e4f43 314e4b4f Name 0663dd28 Loading = 0 0xA09F3880 2 04000D00000000000000000054 Table .IX G 2 1 0 0x00002000 0x40000000 0 TbspaceID 4 TableID 13 0xA09FE300 9 04000D00000000000000000054 Table .IX G 9 1 0 0x00003000 0x40000000 0 TbspaceID 4 TableID 13 0xA09B7080 2 00000100000000000000000054 Table SIX G 2 1 0 0x00002010 0x40000000 0 TbspaceID 0 TableID 1

db2inst1@DB2V97onSLES10:/workshop/lab6> db2 +c "update locktbl set c2='APPL2'"

23

TranHdl:9 のトランザクションは、TranHdl:2 のトランザクションが保持している X ロックに

よって、wait になっていることが分かります。

＿ロックを保持視しているアプリケーションを調査します。 db2pd –d lab6 –transactions


AppHandl 列：アプリケーションハンドル

TranHdl=2,AppHandl=13のアプリケーションによって、ロックが保持されていることが

分かります。ロック待ちになっているのは TranHdl=9,AppHandl=32 のアプリケーションで

す。

＿アプリケーションがロックウェイト時に実行していたステートメントを調査します。 db2pd –d lab6 –applications –dynamic

db2inst1@DB2V97onSLES10:~> db2pd -d lab6 -transactions Database Partition 4294967295 -- Database LAB6 -- Active -- Up 0 days 00:11:16 Transactions: Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2 Firstlsn Lastlsn LogSpace SpaceReserved TID AxRegCnt GXID ClientUserID ClientWrkstnName ClientApplName ClientAccntng 0xA0854A80 13 [000-00013] 2 7 WRITE 0x00000000 0x00000000 0x0000000002C297D4 0x0000000002C2B0CD 250 2118 0x000000000A74 1 0 n/a n/a n/a n/a

＜省略＞ 0xA085A580 32 [000-00032] 9 4 READ 0x00000000 0x00000000 0x0000000000000000 0x0000000000000000 0 0 0x000000000AA6 1 0 n/a n/a n/a n/a

24


AnchID ：アンカーID

L-AnchID ：現時点から最後に実行されたアンカーID

C-AnchID ：現在実行中のステートメントのアンカーID

以上より、ロック・タイムアウトの原因は、AppHandl:13 のアプリケーションが実行した

「delete from locktbl where c1=1」であったことがわかります。

Lab 終了時には、ターミナル１の処理をロールバックし、ターミナル２もロールバックしてくださ

い。

db2inst1@DB2V97onSLES10:~> db2pd -d lab6 -applications -dynamic Database Partition 4294967295 -- Database LAB6 -- Active -- Up 0 days 00:16:36 Applications: Address AppHandl [nod-index] NumAgents CoorEDUID Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid WorkloadID WorkloadOccID 0x204C8730 13 [000-00013] 1 16 UOW-Waiting 0 0 574 1 *LOCAL.db2inst1.100209044258 1 1 0x209B7690 19 [000-00019] 1 30 ConnectCompleted 0 0 0 0 *LOCAL.DB2.100209044308 0 0 0x20A10060 32 [000-00032] 1 32 Lock-wait 629 1 0 0 *LOCAL.db2inst1.100209044753 1 2 0x209B0060 18 [000-00018] 1 29 ConnectCompleted 0 0 0 0 *LOCAL.DB2.100209044307 0 0

<省略> Dynamic SQL Statements: Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text

＜省略＞ 0xA5A72170 574 1 1 1 1 1 delete from locktbl where c1=1 0xA5A72690 629 1 1 1 1 1 update locktbl set c2='APPL2'

<省略>

25

6. モニター表関数を使用したモニタリングモニター表関数を使用したモニタリングモニター表関数を使用したモニタリングモニター表関数を使用したモニタリング

このセクションでは DB2 V9.7 より提供された新しいモニタリング表関数を使用してアプリケー

ションの処理時間や待ち時間について調査します。

モニタリング表関数によって取得される情報の詳細度はデータベース構成パラメーターで決定

されます。以下がモニタリング表関数に関連したデータベースパラメータです。

MON_REQ_METRICS ：リクエスト処理に関する情報を取得

MON_ACT_METRICS ：アクティビティに関する情報を取得

MON_OBJ_METRICS ：オブジェクトに関する情報を取得

デフォルトは全て BASE ですが、十分モニタリングに必要なデータを取得することが可能です。

以下のコマンドで確認することができます。 db2 get db cfg for lab6 | grep METRICS

6.1 負荷ツールの起動負荷ツールの起動負荷ツールの起動負荷ツールの起動

一定の負荷がかかった状態でモニタリングを行うため、データベースに対して負荷を与えるツ

ールを稼働させます。このツールは約 5 分間稼働します。モニタリングのハンズオンを行って

いる途中で負荷ツールが終了した場合、再度起動してください。ツールの稼働中にハンズオン

が終了した場合、Ctrl+C によって途中で終了することが可能です。

＿下記のコマンドを実行し、負荷ツールを起動してください。 cd /workshop/lab6/java ./go.sh tpcc.cfg

実行例

「Stress Start」のメッセージの後ハイフン記号が出力され始めたら、データベースへの負荷が開

始されています。

db2inst1@db2V97onSLES10:/workshop/lab6> cd /workshop/lab6/java db2inst1@db2V97onSLES10:/workshop/lab6/java> ./go.sh tpcc.cfg STRESSARG=-clients 5 -minutes 5 -tm_scenario 0 -tm_transaction 0 -tm_query 0 -url jdbc:db2:lab6 -userid db2inst1 -password db2inst1 TPCCClient Logdir = log/0811_2206 TARGETHOST=db2V97onSLES10 Waiting 5 seconds OLTPStress - OLTP type stress tool using JDBC Version 1.30 2003/05/16 [Stress Start 2009/08/11 22:06:10] -------------------------------------------------------

26

6.2 モニター表関数によるモニタモニター表関数によるモニタモニター表関数によるモニタモニター表関数によるモニタリングリングリングリング

このセクションではモニター表関数を用いて、データベース全体での処理時間と待ち時間や、

各アプリケーションにおける処理時間や待ち時間などを調査します。また、後半では、処理時

間が最も長いパッケージの SQL ステートメントの出力を試みます。

＿アプリケーションの処理時間と待ち時間を調査

下記のコマンドを実行して、モニタリング情報を取得します。スクリプトの内容を確認し、どの表

関数に対して、どのような SELECT 文が実行されているかを確認してください。

なお、出力のカラム数が多いため、ターミナルの画面を横長にして実行してください。 cd /workshop/lab6 cat 04.monget.sql db2 –tvf 04.monget.sql

実行例

上記はアプリケーションごとに待ち時間と処理時間を出力しています。

TOTAL_WAIT_TIME ：合計待ち時間（単位：ミリ秒）

TOTAL_RQST_TIME ：処理時間（単位：ミリ秒） ⇒ 待ち時間含む

この時間を利用して、「TOTAL_WAIT_TIME/TOTAL_RQST_TIME」すると待ち時間の割合を

計算することができます。

db2inst1@DB2V97onSLES10:/workshop/lab6> db2 -tvf 04.monget.sql

connect to lab6

<省略>

SELECT SUBSTR(APPLICATION_NAME,1,10) AS APPL_NAME, APPLICATION_HANDLE, TOTAL_WAIT_TIME,

TOTAL_RQST_TIME FROM TABLE(MON_GET_CONNECTION(NULL,NULL))

APPL_NAME APPLICATION_HANDLE TOTAL_WAIT_TIME TOTAL_RQST_TIME

---------- -------------------- -------------------- --------------------

java 243 15669 16886

java 256 14148 14517

java 255 14716 15198

java 254 14781 15634

db2bp 260 0 0

java 253 13996 14529

java 259 13895 15193

java 252 14407 15210

java 258 14129 14650

java 251 14792 15288

java 257 14317 15180


27

実行例（つづき）

上記はまず、データベース全体で実行されている各コンポーネントの時間を出力しています。

WAIT ：待ち時間

COMPILE ：コンパイル時間

IMP_COMPILE ：暗黙的コンパイル時間

SECTION ：セクション時間

COMMIT ：コミット時間

REORG ：再編成時間

RUNSTATS ： RUNSTATS 時間

ROLLBACK ：ロールバック時間

LOAD ：ロード時間

その下の出力はアプリケーションごとに各コンポーネントの時間を出力しています。こうすること

で、どのアプリケーションが、どのコンポーネントで時間を費やしているかがわかります。上記

の例の場合、アプリケーション・ハンドル 260 は、コンパイルに最も時間を費やしていることが

分かります。

今回は、接続レベルで情報を取得するため MON_GET_CONNECTION表関数を利用しました

が、DB2 には同様に MON_GET_*で始まるモニター表関数が多く用意されています。例えばワ

ークロード管理レベルで情報を取得するためには MON_GET_WORKLOAD 表関数を利用します。

その他のモニター表関数に関しては、実際に利用される際にマニュアルをご参考ください。

SELECT SUM(TOTAL_WAIT_TIME) AS WAIT, SUM(TOTAL_COMPILE_PROC_TIME) AS COMPILE,

SUM(TOTAL_IMPLICIT_COMPILE_PROC_TIME) AS IMP_COMPILE, SUM(TOTAL_SECTION_PROC_TIME) AS

SECTION, SUM(TOTAL_COMMIT_PROC_TIME) AS COMMIT, SUM(TOTAL_REORG_PROC_TIME) AS REORG,

SUM(TOTAL_RUNSTATS_PROC_TIME) AS RUNSTATS, SUM(TOTAL_ROLLBACK_PROC_TIME) AS ROLLBACK,

SUM(TOTAL_LOAD_PROC_TIME) AS LOAD FROM

TABLE(MON_GET_SERVICE_SUBCLASS( 'SYSDEFAULTUSERCLASS','SYSDEFAULTSUBCLASS',NULL))

WAIT COMPILE IMP_COMPILE SECTION COMMIT REORG RUNSTATS ROLLBACK LOAD

-------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------

147024 422 0 4654 480 0 0 0 0


SELECT APPLICATION_HANDLE, SUM(TOTAL_WAIT_TIME) AS WAIT, SUM(TOTAL_COMPILE_PROC_TIME) AS

COMPILE, SUM(TOTAL_IMPLICIT_COMPILE_PROC_TIME) AS IMP_COMPILE, SUM(TOTAL_SECTION_PROC_TIME)

AS SECTION, SUM(TOTAL_COMMIT_PROC_TIME) AS COMMIT, SUM(TOTAL_REORG_PROC_TIME) AS REORG,

SUM(TOTAL_RUNSTATS_PROC_TIME) AS RUNSTATS, SUM(TOTAL_ROLLBACK_PROC_TIME) AS ROLLBACK,

SUM(TOTAL_LOAD_PROC_TIME) AS LOAD FROM TABLE(MON_GET_CONNECTION(NULL,NULL)) GROUP BY

APPLICATION_HANDLE ORDER BY WAIT

APPLICATION_HANDLE WAIT COMPILE IMP_COMPILE SECTION COMMIT REORG RUNSTATS ROLLBACK LOAD

-------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------

260 288 395 0 224 0 260 288 395 0 224 0 260 288 395 0 224 0 260 288 395 0 224 0 0 0 0 00 0 0 00 0 0 00 0 0 0

258 14129 0 0 309 45 0 0 0 0

256 14148 5 0 187 24 0 0 0 0

257 14317 4 0 631 75 0 0 0 0

252 14407 0 0 626 5 0 0 0 0

259 14560 0 0 946 168 0 0 0 0

255 14716 0 0 274 16 0 0 0 0

254 14781 0 0 624 56 0 0 0 0

251 14792 74 0 119 55 0 0 0 い

253 15285 16 0 326 16 0 0 0 0

243 15669 35 0 384 16 0 0 0 0


28

＿処理時間が最も長いパッケージの SQL ステートメントを出力

下記のコマンドを実行して、処理時間が最も長いパッケージの SQL ステートメントを出力します。

スクリプトの内容を確認し、どの表関数に対して、どのような SELECT 文が実行されているかを

確認してください。

なお、出力のカラム数が多いため、ターミナルの画面を横長にして実行してください。また、負

荷ツールが終了している場合は、再度実行してください。 cd /workshop/lab6

cat 05.pkgstmt.sh ./05.pkgstmt.sh

実行例

上記では、まず MON_GET_PKG_CACHE_STMT より、実行時間が最も長い上位 5 つの処理に

関して EXECUTABLE_ID（実行 ID）を取得しています。その後、最も実行時間が長かったもの

に関して、どのような SQL ステートメントが実行されているかを、

MON_GET_PKG_CACHE_STMT から取得しています。

MON_GET_*モニター表関数で取得できる時間や情報は沢山用意されていますので、要件に

応じて様々な方向から分析し、モニタリングにお役立てください。

db2inst1@DB2V97onSLES10:/workshop/lab6> ./05.pkgstmt.sh

データベース接続情報

データベース・サーバー = DB2/LINUX 9.7.1

SQL 許可 ID = DB2INST1

ローカル・データベース別名 = LAB6

TOTAL_EXEC_TIME TOTAL_WAIT_TIME EXECUTABLE_ID

-------------------- -------------------- -------------------------------------------------------------------

75692 75661 x'0100000000000000030000000000000000000000020020100210165255503793'

45501 45237 x'0100000000000000070000000000000000000000020020100210165255885117'

39456 39270 x'0100000000000000060000000000000000000000020020100210165255739482'

15491 13788 x'0100000000000000010000000000000000000000020020100210165255126523'

2392 2351 x'0100000000000000040000000000000000000000020020100210165255547490'


Statement for EXECUTABLE_ID= x'0100000000000000030000000000000000000000020020100210165255503793' is

STMT_TEXT

--------------------------------------------------------------------------------

UPDATE district SET d_next_o_id=?+1 WHERE d_w_id=? AND d_id=?


29

（参考）

＿データのグラフ化

なお、取得したデータをもとに各自でグラフ化するとより解釈しやすくなります。

例１．アプリケーション処理時間と待ち時間（APPLICATION_HANDLE=243）

例２．アプリケーション処理時間の内訳（APPLICATION_HANDLE=243）

以上です。

30

© Copyright IBM Corporation 2011 All Rights Reserved.

本書に含まれている情報は、正式なIBMのテストを受けていません。また、明記にしろ、暗黙的にしろ、なんらの保証もなしに配布されるものです。

この情報の使用またはこれらの技術の実施は、いずれも、使用先の責任において行われるべきものであり、それらを評価し、実際に使用する環境に

統合する使用先の判断に依存しています。それぞれの項目は、ある特定の状態において正確であることがIBMによって調べられていますが、他のと

ころで同じまたは同様の結果が得られる保証はありません。これらの技術を自身の環境に適用することを試みる使用先は、自己の責任において行う

必要があります。

Documents

[Lab [Lab 6 666]]]] モモモモニタリングニタリング 実行例 _表の作成 下記のコマンドを実行して、表及び索引を作成します。表及び索引のDDL

[Lab [Lab 6 666]]]] モモモモニタリングニタリング実行例 _表の作成下記のコマンドを実行して、表及び索引を作成します。表及び索引のDDL