[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
DB20000I SQL コマンドが正常に完了しました。
<省略>
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
DB20000I SQL コマンドが正常に完了しました。
<省略>
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 connect to lab6
<省略>
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 レコードが選択されました。
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
9 レコードが選択されました。
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
モニター記録スイッチ
DB パーティション番号 0 のスイッチ・リスト
バッファー・プール・アクティビティー情報 (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
タイム・スタンプ情報を取る (TIMESTAMP) = ON 2009-08-11 19:55:19.130673
作業単位情報 (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 コマンドが正常に完了しました。
モニター記録スイッチ
DB パーティション番号 0 のスイッチ・リスト
バッファー・プール・アクティビティー情報 (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
タイム・スタンプ情報を取る (TIMESTAMP) = ON 2009-08-11 19:55:19.130673
作業単位情報 (UOW) = OFF
DB20000I RESET MONITOR コマンドが正常に完了しました。
Repeat count :1/3 Interval :10
DB20000I RESET MONITOR コマンドが正常に完了しました。
Repeat count :2/3 Interval :10
DB20000I RESET MONITOR コマンドが正常に完了しました。
Repeat count :3/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 つ用
意してください。
db2inst1@DB2V97onSLES10:/workshop/lab6> db2 connect to lab6
データベース接続情報
データベース・サーバー = 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
3 レコードが選択されました。
20
各ターミナルを以下のように呼ぶことにします。
アプリケーション1 ⇒ ターミナル1
アプリケーション2 ⇒ ターミナル2
問題判別 ⇒ ターミナル3
_ロック・タイムアウト時間の設定
まずは、ロック・タイムアウトになることを確認するために、ターミナル2においてロック・タイムア
ウト時間を短めに 5 秒を設定します。 db2 connect to lab6 db2 set current lock timeout 5
実行例@ターミナル2
_ロック競合を発生させる
ターミナル1にて、未コミットでデータを 1 件 DELETE します。 db2 connect to lab6 db2 +c “delete from locktbl where c1=1”
実行例@ターミナル1
ターミナル 2 にて、未コミットでデータを全件 UPDATE します。 db2 +c “update locktbl set c2=’APPL2’”
この SQL を実行すると応答が無くなり、5 秒後にロック・タイムアウトのエラーが出力されます。
実行例@ターミナル2
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 connect to lab6
<省略> db2inst1@DB2V97onSLES10:/workshop/lab6> db2 +c "delete from locktbl where c1=1"
DB20000I SQL コマンドが正常に完了しました。
db2inst1@DB2V97onSLES10:/workshop/lab6> db2 connect to lab6
<省略> db2inst1@DB2V97onSLES10:/workshop/lab6> db2 set current lock timeout 5
DB20000I SQL コマンドが正常に完了しました。
21
実行例@ターミナル2
ターミナル 1 で処理をロールバックさせてください。 db2 rollback
実行例@ターミナル1
5.3 問題判別問題判別問題判別問題判別
前セクションと同じ状況を再現させ、ロック競合に関する問題判別を行います。
_ロック・タイムアウト時間を変更する@ターミナル2
問題判別の便査上、ロック・タイムアウトの時間を無限に設定します。 db2 set current lock timeout -1
実行例@ターミナル2
_ロック競合を発生させる
ターミナル1にて、未コミットでデータを 1 件 DELETE します。 db2 +c “delete from locktbl where c1=1”
実行例@ターミナル1
ターミナル 2 にて、未コミットでデータを全件 UPDATE します。 db2 +c “update locktbl set c2=’APPL2’”
db2inst1@DB2V97onSLES10:/workshop/lab6> db2 rollback
DB20000I SQL コマンドが正常に完了しました。
db2inst1@DB2V97onSLES10:/workshop/lab6> db2 +c "delete from locktbl where c1=1"
DB20000I SQL コマンドが正常に完了しました。
db2inst1@DB2V97onSLES10:/workshop/lab6> db2 set current lock timeout -1
DB20000I SQL コマンドが正常に完了しました。
db2inst1@DB2V97onSLES10:/workshop/lab6> db2 ? sql0911
SQL0911N デッドロックまたはタイムアウトのため、現在のトランザ
クションがロールバックされました。 理由コード "<reason-code>"
説明:
現在の作業単位が、オブジェクトの使用について、未解決競合状になったた
ために、ロールバックされました。
理由コードは以下のとおりです。
<省略> 68
ロック・タイムアウトのために、トランザクションがロールバックされました。
<省略>
22
実行例@ターミナル2
ターミナル2ではプロンプトが返ってこないため、この間、問題判別を行います。
5.3.1 db2pd による問題判別による問題判別による問題判別による問題判別
ターミナル3にて db2pd コマンドを実行して、ロック状況を分析します。
出力が多いため、ターミナル・ウィンドゥを横に長くしてください。
_取得されているロック情報を参照します。 db2pd –d lab6 –lock showlocks
実行例@ターミナル3
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
実行例@ターミナル3
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
実行例@ターミナル3
AnchID :アンカーID
L-AnchID :現時点から最後に実行されたアンカーID
C-AnchID :現在実行中のステートメントのアンカーID
以上より、ロック・タイムアウトの原因は、AppHandl:13 のアプリケーションが実行した
「delete from locktbl where c1=1」であったことがわかります。
Lab 終了時には、ターミナル1の処理をロールバックし、ターミナル2もロールバックしてくださ
い。
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
11 レコードが選択されました。
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
1 レコードが選択されました。
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
11 レコードが選択されました。
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'
5 レコードが選択されました。
Statement for EXECUTABLE_ID= x'0100000000000000030000000000000000000000020020100210165255503793' is
STMT_TEXT
--------------------------------------------------------------------------------
UPDATE district SET d_next_o_id=?+1 WHERE d_w_id=? AND d_id=?
1 レコードが選択されました。
29
(参考)
_データのグラフ化
なお、取得したデータをもとに各自でグラフ化するとより解釈しやすくなります。
例1. アプリケーション処理時間と待ち時間(APPLICATION_HANDLE=243)
例2.アプリケーション処理時間の内訳(APPLICATION_HANDLE=243)
以上です。
30
© Copyright IBM Corporation 2011 All Rights Reserved.
本書に含まれている情報は、正式なIBMのテストを受けていません。また、明記にしろ、暗黙的にしろ、なんらの保証もなしに配布されるものです。
この情報の使用またはこれらの技術の実施は、いずれも、使用先の責任において行われるべきものであり、それらを評価し、実際に使用する環境に
統合する使用先の判断に依存しています。それぞれの項目は、ある特定の状態において正確であることがIBMによって調べられていますが、他のと
ころで同じまたは同様の結果が得られる保証はありません。これらの技術を自身の環境に適用することを試みる使用先は、自己の責任において行う
必要があります。