![](../../com.ibm.help.doc/images/IC-im-sm.gif)
db2pd コマンドを使用したモニターおよびトラブルシューティング
db2pd コマンドは、トラブルシューティングのために使用します。このツールによって、DB2® メモリー・セットからの情報を素早く即時に返すことが可能です。
概説
このツールは、ラッチを獲得したりエンジン・リソースを使用したりせずに情報を収集します。このため、db2pd が情報を収集している間に、取得対象の情報の内容が変わる可能性があります。つまり、データは完全には正確でないかもしれません (この可能性を考慮に入れる必要があります)。変更メモリー・ポインターが見つかった場合、db2pd が終了するのを防ぐために、シグナル・ハンドラーが使われます。 その結果、例えば「データ構造が変更されたためコマンドが強制終了されました (Changing data structure forced command termination)」というメッセージが出力に含まれる可能性があります。 この点を考慮に入れて使用すれば、このツールはトラブルシューティングに役立ちます。ラッチなしで情報を収集することには 2 つの利点があります (より高速な検索、エンジン・リソースとの競合がない)。
特定の SQLCODE、ZRC コードまたは ECF コードの発生時にデータベース管理システムに関する情報をキャプチャーする場合は db2pdcfg -catch コマンドを使用します。 エラーをキャッチすると、db2cos (コールアウト・スクリプト) が起動します。 任意の db2pd コマンド、オペレーティング・システム・コマンド、または問題解決のために必要なその他のコマンドを実行するために、db2cos スクリプトを動的に変更することができます。テンプレート db2cos スクリプト・ファイルは、 UNIX および Linux では、sqllib/bin にあります。 Windows オペレーティング・システムの場合、db2cos は $DB2PATH¥bin ディレクトリーにあります。
新規ノードを追加している際は、 db2pd -addnode コマンド (詳細情報を参照するには oldviewapps および detail パラメーターを指定します) を使用して、ノードを追加しているデータベース・パーティション・サーバーでの操作の進行状況をモニターできます。
現在アクティブである、または何らかの理由で非アクティブになったイベント・モニターのリストが必要な場合は、 db2pd -gfw コマンドを実行します。このコマンドでは、高速ライター EDU ごとに、イベント・モニターがデータを書き込むターゲットに関する統計および情報も返されます。
例
- 例 1: ロック待機の診断
- 例 2: 待機中のすべてのロックをキャプチャーするための -wlocks パラメーターの使用
- 例 3: ロックに関係している表名とスキーマ名の表示
- 例 4: ロック所有者およびロック待機者に関する詳細な実行時情報をキャプチャーするための -apinfo パラメーターの使用
- 例 5: ロッキング問題を検討するときのコールアウト・スクリプトの使用
- 例 6: アプリケーションと動的 SQL ステートメントのマップ
- 例 7: メモリー使用量のモニター
- 例 8: どのアプリケーションが表スペースを消費しているかの確認
- 例 9: リカバリーのモニター
- 例 10: トランザクションによって使用されているリソースの量の確認
- 例 11: ログの使用状況のモニター
- 例 12: SYSPLEX リストの表示
- 例 13: スタック・トレースの生成
- 例 14: データベース・パーティションのメモリー統計の表示
- 例 15: 索引再編成の進行状況のモニター
- 例 16: プロセッサー時間の消費別の上位 EDU の表示と EDU スタック情報の表示
- 例 17: エージェント・イベント・メトリックの表示
- 例 18: エクステント移動状況の表示
この例の結果テキストは、db2cmd コマンド出力の読みやすくした抜粋です。
例 1: ロック待機の診断
Locks:
TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att ReleaseFlg
3 00020002000000040000000052 Row ..X G 3 1 0 0x0000 0x40000000
2 00020002000000040000000052 Row ..X W* 2 1 0 0x0000 0x40000000
-db データベース名オプションを使用して指定したデータベースの場合、最初の結果はそのデータベースのロックを示します。この結果は、TranHdl 2 が、TranHdl 3 によって保持されているロックを待機していることがわかります。Transactions:
AppHandl [nod-index] TranHdl Locks State Tflag Tflag2 Firstlsn Lastlsn Firstlso Lastlso LogSpace SpaceReserved TID AxRegCnt GXID
11 [000-00011] 2 4 READ 0x00000000 0x00000000 0x000000000000 0x000000000000 0x000000000000 0x000000000000 0 0 0x0000000000B7 1 0
12 [000-00012] 3 4 WRITE 0x00000000 0x00000000 0x00000002AC04 0x00000002AC04 0x000000FA000C 0x000000FA000C 113 154 0x0000000000B8 1 0
TranHdl 2 が AppHandl 11 に関連付けられていて、TranHdl 3 が AppHandl 12 に関連付けられていることがわかります。Applications:
AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid
12 [000-00012] 1 1073336 UOW-Waiting 0 0 17 1 *LOCAL.burford.060303225602
11 [000-00011] 1 1040570 UOW-Executing 17 1 94 1 *LOCAL.burford.060303225601
AppHandl 12 は、動的ステートメント 17, 1 を最後に実行したのがわかります。AppHandl 11 は、動的ステートメント 17, 1 を現在実行中で、最後に実行ステートメント 94, 1 を実行しました。Dynamic SQL Statements:
AnchID StmtUID NumEnv NumVar NumRef NumExe Text
17 1 1 1 2 2 update pdtest set c1 = 5
94 1 1 1 2 2 set lock mode to wait 1
テキスト列は、ロック・タイムアウトに関連している SQL ステートメントを示しています。例 2: 待機中のすべてのロックをキャプチャーするための -wlocks パラメーターの使用
venus@boson:/home/venus =>db2pd -wlocks -db pdtest
Database Partition 0 -- Database PDTEST -- Active -- Up 0 days 00:01:22
Locks being waited on :
AppHandl TranHdl Lockname Type Mode Conv Sts CoorEDU AppName AuthID AppID
47 8 00020004000000000840000652 Row ..X G 5160 db2bp VENUS *LOCAL.venus.071207213730
46 2 00020004000000000840000652 Row .NS W 5913 db2bp VENUS *LOCAL.venus.071207213658
例 3: ロックに関係している表名とスキーマ名の表示
Database Member 0 -- Database PDTEST -- Active -- Up 0 days 00:00:10 -- Date 2012-11-06-10.57.18.025767
Locks:
Address TranHdl Lockname Type Mode Sts Owner Dur HoldCount Att ReleaseFlg rrIID TableNm SchemaNm
0x00002AAAFFFA5F68 3 02000400000020000000000062 MdcBlockLock ..X G 3 1 0 0x00200000 0x40000000 0 T1 YUQZHANG 02000400000020000000000062 SQLP_MDCBLOCK (obj={2;4}, bid=d(0;32;0), x0000200000000000)
0x00002AAAFFFA7198 3 41414141414A4863ADA1ED24C1 PlanLock ..S G 3 1 0 0x00000000 0x40000000 0 N/A N/A 41414141414A4863ADA1ED24C1 SQLP_PLAN ({41414141 63484A41 24EDA1AD}, loading=0)
Database Member 0 -- Database PDTEST -- Active -- Up 0 days 00:00:35 -- Date 2012-11-06-11.11.32.403994
Locks being waited on :
AppHandl [nod-index] TranHdl Lockname Type Mode Conv Sts CoorEDU AppName AuthID AppID TableNm SchemaNm AppNode
19 [000-00019] 3 02000400000000000000000054 TableLock ..X G 18 db2bp YUQZHANG *LOCAL.yuqzhang.121106161112 PDTEST YUQZHANG hotel71
21 [000-00021] 15 02000400000000000000000054 TableLock .IS W 45 db2bp YUQZHANG *LOCAL.yuqzhang.121106161114 PDTEST YUQZHANG hotel71
例 4: ロック所有者およびロック待機者に関する詳細な実行時情報をキャプチャーするための -apinfo パラメーターの使用
venus@boson:/home/venus =>db2pd -apinfo 47 -db pdtest
Database Partition 0 -- Database PDTEST -- Active -- Up 0 days 00:01:30
Application :
Address : 0x0780000001676480
AppHandl [nod-index] : 47 [000-00047]
Application PID : 876558
Application Node Name : boson
IP Address: n/a
Connection Start Time : (1197063450)Fri Dec 7 16:37:30 2007
Client User ID : venus
System Auth ID : VENUS
Coordinator EDU ID : 5160
Coordinator Partition : 0
Number of Agents : 1
Locks timeout value : 4294967294 seconds
Locks Escalation : No
Workload ID : 1
Workload Occurrence ID : 2
Trusted Context : n/a
Connection Trust Type : non trusted
Role Inherited : n/a
Application Status : UOW-Waiting
Application Name : db2bp
Application ID : *LOCAL.venus.071207213730
ClientUserID : n/a
ClientWrkstnName : n/a
ClientApplName : n/a
ClientAccntng : n/a
List of inactive statements of current UOW :
UOW-ID : 2
Activity ID : 1
Package Schema : NULLID
Package Name : SQLC2G13
Package Version :
Section Number : 203
SQL Type : Dynamic
Isolation : CS
Statement Type : DML, Insert/Update/Delete
Statement : insert into pdtest values 99
venus@boson:/home/venus =>db2pd -apinfo 46 -db pdtest
Database Partition 0 -- Database PDTEST -- Active -- Up 0 days 00:01:39
Application :
Address : 0x0780000000D77A60
AppHandl [nod-index] : 46 [000-00046]
Application PID : 881102
Application Node Name : boson
IP Address: n/a
Connection Start Time : (1197063418)Fri Dec 7 16:36:58 2007
Client User ID : venus
System Auth ID : VENUS
Coordinator EDU ID : 5913
Coordinator Partition : 0
Number of Agents : 1
Locks timeou t value : 4294967294 seconds
Locks Escalation : No
Workload ID : 1
Workload Occurrence ID : 1
Trusted Context : n/a
Connection Trust Type : non trusted
Role Inherited : n/a
Application Status : Lock-wait
Application Name : db2bp
Application ID : *LOCAL.venus.071207213658
ClientUserID : n/a
ClientWrkstnName : n/a
ClientApplName : n/a
ClientAccntng : n/a
List of active statements :
*UOW-ID : 3
Activity ID : 1
Package Schema : NULLID
Package Name : SQLC2G13
Package Version :
Section Number : 201
SQL Type : Dynamic
Isolation : CS
Statement Type : DML, Select (blockable)
Statement : select * from pdtest
例 5: ロッキング問題を検討するときのコールアウト・スクリプトの使用
Lock Timeout Caught
Thu Feb 17 01:40:04 EST 2006
Instance DB2
Database: SAMPLE
Partition Number: 0
PID: 940
TID: 2136
Function: sqlplnfd
Component: lock manager
Probe: 999
Timestamp: 2006-02-17-01.40.04.106000
AppID: *LOCAL.DB2...
AppHdl:
...
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:06:53
Locks:
Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att Rlse
0x402C6B30 3 00020003000000040000000052 Row ..X W* 3 1 0 0 0x40
この出力で、 W* はタイムアウトになったロックを示します。この場合、ロック待機が発生しています。ロック・タイムアウトは、ロックがより高いモードに変換されるときにも発生します。このことは、出力内の C* で示されています。
db2cos ファイルにある他の db2pd コマンドによって提供される出力を参照しながら、この出力結果をトランザクション、アプリケーション、エージェント、SQL ステートメントにマップすることが可能です。出力の特定部分を絞り込んだり、他のコマンドを使用することによって、必要な情報を収集できます。 例えば、db2pd -locks wait パラメーターを使用して、待機状況であるロックだけを印刷できます。-app および -agent パラメーターを使用することもできます。
例 6: アプリケーションと動的 SQL ステートメントのマップ
コマンド db2pd -applications -dynamic は、動的 SQL ステートメントの現行および最新アンカー ID と、ステートメント・ユニーク ID を報告します。 これにより、アプリケーションから動的 SQL ステートメントへの直接的なマッピングが可能になります。
Applications:
Address AppHandl [nod-index] NumAgents CoorPid Status
0x00000002006D2120 780 [000-00780] 1 10615 UOW-Executing
C-AnchID C-StmtUID L-AnchID L-StmtUID Appid
163 1 110 1 *LOCAL.burford.050202200412
Dynamic SQL Statements:
Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text
0x0000000220A02760 163 1 2 2 2 1 CREATE VIEW MYVIEW
0x0000000220A0B460 110 1 2 2 2 1 CREATE VIEW YOURVIEW
例 7: メモリー使用量のモニター
以下の出力例のようなメモリー使用量を知りたい場合は db2pd -memblock コマンドが役立ちます。
All memory blocks in DBMS set.
Address PoolID PoolName BlockAge Size(Bytes) I LOC File
0x0780000000740068 62 resynch 2 112 1 1746 1583816485
0x0780000000725688 62 resynch 1 108864 1 127 1599127346
0x07800000001F4348 57 ostrack 6 5160048 1 3047 698130716
0x07800000001B5608 57 ostrack 5 240048 1 3034 698130716
0x07800000001A0068 57 ostrack 1 80 1 2970 698130716
0x07800000001A00E8 57 ostrack 2 240 1 2983 698130716
0x07800000001A0208 57 ostrack 3 80 1 2999 698130716
0x07800000001A0288 57 ostrack 4 80 1 3009 698130716
0x0780000000700068 70 apmh 1 360 1 1024 3878879032
0x07800000007001E8 70 apmh 2 48 1 914 1937674139
0x0780000000700248 70 apmh 3 32 1 1000 1937674139
...
この後に、ソートされた「プールごとの」出力が続きます。
Memory blocks sorted by size for ostrack pool:
PoolID PoolName TotalSize(Bytes) TotalCount LOC File
57 ostrack 5160048 1 3047 698130716
57 ostrack 240048 1 3034 698130716
57 ostrack 240 1 2983 698130716
57 ostrack 80 1 2999 698130716
57 ostrack 80 1 2970 698130716
57 ostrack 80 1 3009 698130716
Total size for ostrack pool: 5400576 bytes
Memory blocks sorted by size for apmh pool:
PoolID PoolName TotalSize(Bytes) TotalCount LOC File
70 apmh 40200 2 121 2986298236
70 apmh 10016 1 308 1586829889
70 apmh 6096 2 4014 1312473490
70 apmh 2516 1 294 1586829889
70 apmh 496 1 2192 1953793439
70 apmh 360 1 1024 3878879032
70 apmh 176 1 1608 1953793439
70 apmh 152 1 2623 1583816485
70 apmh 48 1 914 1937674139
70 apmh 32 1 1000 1937674139
Total size for apmh pool: 60092 bytes
...
出力の最終セクションでは、全メモリー・セットについて、メモリー・コンシューマーをソートします。
All memory consumers in DBMS memory set:
PoolID PoolName TotalSize(Bytes) %Bytes TotalCount %Count LOC File
57 ostrack 5160048 71.90 1 0.07 3047 698130716
50 sqlch 778496 10.85 1 0.07 202 2576467555
50 sqlch 271784 3.79 1 0.07 260 2576467555
57 ostrack 240048 3.34 1 0.07 3034 698130716
50 sqlch 144464 2.01 1 0.07 217 2576467555
62 resynch 108864 1.52 1 0.07 127 1599127346
72 eduah 108048 1.51 1 0.07 174 4210081592
69 krcbh 73640 1.03 5 0.36 547 4210081592
50 sqlch 43752 0.61 1 0.07 274 2576467555
70 apmh 40200 0.56 2 0.14 121 2986298236
69 krcbh 32992 0.46 1 0.07 838 698130716
50 sqlch 31000 0.43 31 2.20 633 3966224537
50 sqlch 25456 0.35 31 2.20 930 3966224537
52 kerh 15376 0.21 1 0.07 157 1193352763
50 sqlch 14697 0.20 1 0.07 345 2576467555
...
UNIX および Linux オペレーティング・システムでは、専用メモリーのメモリー・ブロックを報告することもできます。 例えば、db2pd -memb pid=159770 を実行すると、以下のような結果が生成されます。
All memory blocks in Private set.
PoolID PoolName BlockAge Size(Bytes) I LOC File
88 private 1 2488 1 172 4283993058
88 private 2 1608 1 172 4283993058
88 private 3 4928 1 172 4283993058
88 private 4 7336 1 172 4283993058
88 private 5 32 1 172 4283993058
88 private 6 6728 1 172 4283993058
88 private 7 168 1 172 4283993058
88 private 8 24 1 172 4283993058
88 private 9 408 1 172 4283993058
88 private 10 1072 1 172 4283993058
88 private 11 3464 1 172 4283993058
88 private 12 80 1 172 4283993058
88 private 13 480 1 1534 862348285
88 private 14 480 1 1939 862348285
88 private 80 65551 1 1779 4231792244
Total set size: 94847 bytes
Memory blocks sorted by size:
PoolID PoolName TotalSize(Bytes) TotalCount LOC File
88 private 65551 1 1779 4231792244
88 private 28336 12 172 4283993058
88 private 480 1 1939 862348285
88 private 480 1 1534 862348285
Total set size: 94847 bytes
例 8: どのアプリケーションが表スペースを消費しているかの確認
db2pd -tcbstats コマンドを使用すれば、表に対する挿入の数を識別することができます。 以下の例は、TEMP1 という名前のユーザー定義グローバル一時表のサンプル情報を示しています。
TCB Table Information:
TbspaceID TableID PartID MasterTbs MasterTab TableName SchemaNm ObjClass DataSize LfSize LobSize XMLSize
3 2 n/a 3 2 TEMP1 SESSION Temp 966 0 0 0
TCB Table Stats:
TableName Scans UDI PgReorgs NoChgUpdts Reads FscrUpdates Inserts Updates Deletes OvFlReads OvFlCrtes
TEMP1 0 0 0 0 0 0 43968 0 0 0 0
その後、db2pd -tablespaces コマンドを使用することにより、表スペース 3 の情報を入手できます。 以下はその出力例です。
Tablespace 3 Configuration:
Type Content PageSz ExtentSz Auto Prefetch BufID BufIDDisk FSC RSE NumCntrs MaxStripe LastConsecPg Name
DMS UsrTmp 4096 32 Yes 32 1 1 On Yes 1 0 31 TEMPSPACE2
Tablespace 3 Statistics:
TotalPgs UsablePgs UsedPgs PndFreePgs FreePgs HWM State MinRecTime NQuiescers
5000 4960 1088 0 3872 1088 0x00000000 0 0
Tablespace 3 Autoresize Statistics:
AS AR InitSize IncSize IIP MaxSize LastResize LRF
No No 0 0 No 0 None No
Containers:
ContainNum Type TotalPgs UseablePgs StripeSet Container
0 File 5000 4960 0 /home/db2inst1/tempspace2a
db2 "values timestamp('1970-01-01-00.00.00') + 1369626329 seconds"
照会によって、GMT 値の 2013-05-27-03.45.29.000000 が返されます。再利用可能スペース有効 (RSE) 列で、再利用可能スペース・フィーチャーが有効かどうかを調べることができます。FreePgs 列は、 スペースが埋まってきていることを示しています。フリー・ページの値が減るほど、使用可能なスペースは少なくなります。FreePgs の値と UsedPgs の値の和が UsablePgs の値と等しくなっていることにも注目してください。
それが分かれば、db2pd -db sample -dyn を実行することにより、表 TEMP1 を使用している動的 SQL ステートメントを識別できます。
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:13:06
Dynamic Cache:
Current Memory Used 1022197
Total Heap Size 1271398
Cache Overflow Flag 0
Number of References 237
Number of Statement Inserts 32
Number of Statement Deletes 13
Number of Variation Inserts 21
Number of Statements 19
Dynamic SQL Statements:
AnchID StmtUID NumEnv NumVar NumRef NumExe Text
78 1 2 2 3 2 declare global temporary table temp1 (c1 char(6)) not logged
253 1 1 1 24 24 insert into session.temp1 values('TEST')
最後に、 db2pd -db sample -app を実行することによって上記の出力の情報をアプリケーション出力と付き合わせることにより、アプリケーションを識別することができます。
Applications:
AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID
501 [000-00501] 1 11246 UOW-Waiting 0 0
L-AnchID L-StmtUID Appid
253 1 *LOCAL.db2inst1.050202160426
動的 SQL ステートメントを識別したアンカー ID (AnchID) 値を使用して、 関連付けられているアプリケーションを識別することができます。この結果は、最後のアンカー ID (L-AnchID) 値 がアンカー ID (AnchID) 値と同じであることを示しています。 db2pd の 1 回の実行の結果が次回の db2pd の実行で使用されます。
AppHandl [nod-index] AgentPid Priority Type DBName
501 [000-00501] 11246 0 Coord SAMPLE
State ClientPid Userid ClientNm Rowsread Rowswrtn LkTmOt
Inst-Active 26377 db2inst1 db2bp 22 9588 NotSet
db2pd -agent コマンドを実行した結果として得られる AppHandl と AgentPid の値を、db2pd -app コマンドを実行した結果として得られる AppHandl と CoorPiid の対応値にマップできます。
内部一時表が表スペースを埋めている可能性があれば、これらのステップは若干異なります。ただし、この場合も db2pd -tcbstats を使用して、多数の挿入を持つ表を識別します。 以下は、暗黙的一時表のサンプル情報です。
TCB Table Information:
Address TbspaceID TableID PartID MasterTbs MasterTab TableName SchemaNm ObjClass DataSize ...
0x0780000020CC0D30 1 2 n/a 1 2 TEMP (00001,00002) <30> <JMC Temp 2470 ...
0x0780000020CC14B0 1 3 n/a 1 3 TEMP (00001,00003) <31> <JMC Temp 2367 ...
0x0780000020CC21B0 1 4 n/a 1 4 TEMP (00001,00004) <30> <JMC Temp 1872 ...
TCB Table Stats:
Address TableName Scans UDI PgReorgs NoChgUpdts Reads FscrUpdates Inserts ...
0x0780000020CC0D30 TEMP (00001,00002) 0 0 0 0 0 0 43219 ...
0x0780000020CC14B0 TEMP (00001,00003) 0 0 0 0 0 0 42485 ...
0x0780000020CC21B0 TEMP (00001,00004) 0 0 0 0 0 0 0 ...
この例では、命名規則 TEMP (TbspaceID, TableID) を持つ表に多数の挿入があります。 これらは暗黙的一時表です。 SchemaNm 列の値には、AppHandl の値が SchemaNm の値と連結するという命名規則があります。これにより、操作を実行しているアプリケーションを識別できます。
その後、その情報を db2pd -tablespaces からの出力にマップし、 表スペース 1 で使用されるスペースを確認できます。 以下の出力内の表スペース統計で、UsedPgs の値と UsablePgs の値の間の関係に注目してください。
Tablespace Configuration:
Id Type Content PageSz ExtentSz Auto Prefetch BufID BufIDDisk FSC RSE NumCntrs MaxStripe LastConsecPg Name
1 SMS SysTmp 4096 32 Yes 320 1 1 On Yes 10 0 31 TEMPSPACE1
Tablespace Statistics:
Id TotalPgs UsablePgs UsedPgs PndFreePgs FreePgs HWM State MinRecTime NQuiescers
1 6516 6516 6516 0 0 0 0x00000000 0 0
Tablespace Autoresize Statistics:
Id AS AR InitSize IncSize IIP MaxSize LastResize LRF
1 No No 0 0 No 0 None No
Containers:
...
その後、コマンド db2pd -app を使用して、アプリケーション・ハンドル 30 および 31 を識別することができます (これらは -tcbstats 出力で確認されたものです)。
Applications:
AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid
31 [000-00031] 1 4784182 UOW-Waiting 0 0 107 1 *LOCAL.db2inst1.051215214142
30 [000-00030] 1 8966270 UOW-Executing 107 1 107 1 *LOCAL.db2inst1.051215214013
最後に、上記の出力の情報を、db2pd -dyn コマンドを実行することによって得られた動的 SQL 出力と付き合わせます。
Dynamic SQL Statements:
AnchID StmtUID NumEnv NumVar NumRef NumExe Text
107 1 1 1 43 43 select c1, c2 from test group by c1,c2
例 9: リカバリーのモニター
コマンド db2pd -recovery を実行した場合、出力は、以下の出力例で示されているように、リカバリーの進行状況を確認するために使用できるいくつかのカウンターを示します。 「Current Log (現在のログ))」および「Current LSO (現在の LSO」の値はログの位置を示します。「CompletedWork」は、 完了済みのバイト数です。
Recovery:
Recovery Status 0x00000401
Current Log S0000005.LOG
Current LSN 0000001F07BC
Current LSO 000002551BEA
Job Type ROLLFORWARD RECOVERY
Job ID 7
Job Start Time (1107380474) Wed Feb 2 16:41:14 2005
Job Description Database Rollforward Recovery
Invoker Type User
Total Phases 2
Current Phase 1
Progress:
Address PhaseNum Description StartTime CompletedWork TotalWork
0x0000000200667160 1 Forward Wed Feb 2 16:41:14 2005 2268098 bytes Unknown
0x0000000200667258 2 Backward NotStarted 0 bytes Unknown
例 10: トランザクションによって使用されているリソースの量の確認
コマンド db2pd -transactions を実行した場合は、ロックの数、最初のログ・シーケンス番号 (LSN)、最後の LSN、最初の LSO、最後の LSO、使用されているログ・スペース、および予約済みスペースが出力に示されます。 出力には、アプリケーションのコミットの総数とアプリケーションのロールバックの総数も表示されます。 アプリケーションのコミットとロールバックの総数を知ることは、トランザクションの動作を理解するうえで役立ちます。 以下は、db2pd -transactions コマンドの出力例です。
Transactions:
Address AppHandl [nod-index] TranHdl Locks State Tflag
0x000000022026D980 797 [000-00797] 2 108 WRITE 0x00000000
0x000000022026E600 806 [000-00806] 3 157 WRITE 0x00000000
0x000000022026F280 807 [000-00807] 4 90 WRITE 0x00000000
Tflag2 Firstlsn Lastlsn Firstlso Lastlso
0x00000000 0x0000001A4212 0x0000001C2022 0x000001072262 0x0000010B2C8C
0x00000000 0x000000107320 0x0000001S3462 0x000001057574 0x0000010B3340
0x00000000 0x0000001BC00C 0x0000001X2F03 0x00000107CF0C 0x0000010B2FDE
LogSpace SpaceReserved TID AxRegCnt GXID
4518 95450 0x000000000451 1 0
6576 139670 0x0000000003E0 1 0
3762 79266 0x000000000472 1 0
Total Application commits : 23
Total Application rollbacks : 39
例 11: ログの使用状況のモニター
db2pd -logs コマンドは、データベースのログ使用状況をモニターするのに役立ちます。 「Pages Written (書き込み済みページ数)」値を使用することにより、以下の出力例で示されているように、ログの使用量が増加しているかどうかを判別できます。
Logs:
Current Log Number 2
Pages Written 846
Method 1 Archive Status Success
Method 1 Next Log to Archive 2
Method 1 First Failure n/a
Method 2 Archive Status Success
Method 2 Next Log to Archive 2
Method 2 First Failure n/a
Address StartLSN StartLSO State Size Pages Filename
0x000000023001BF58 0x00000022F032 0x000001B58000 0x00000000 1000 1000 S0000002.LOG
0x000000023001BE98 0x000000000000 0x000001F40000 0x00000000 1000 1000 S0000003.LOG
0x0000000230008F58 0x000000000000 0x000002328000 0x00000000 1000 1000 S0000004.LOG
- 最近のログ・アーカイブが失敗した場合、「Archive Status (アーカイブ状況)」は 値「Failure (失敗)」に設定されています。アーカイブ失敗が継続しているためにログがアーカイブされない場合、 「Archive Status (アーカイブ状況)」は値「First Failure (最初に失敗)」に設定されます。
- ログのアーカイブ処理が非常に遅い場合には、「Next Log to Archive (次のアーカイブ対象ログ)」の値が「Current Log Number (現在のログ番号)」の値より小さくなっています。 アーカイブ処理が非常に遅い場合には、アクティブ・ログ用のスペースがなくなり、 データベース内のデータがまったく変更されなくなる可能性があります。
例 12: SYSPLEX リストの表示
以下の出力例を示す db2pd -sysplex コマンドを使用しない場合、SYSPLEX リストを報告する他の唯一の方法は、DB2 トレースを介する方法です。
Sysplex List:
Alias: HOST
Location Name: HOST1
Count: 1
IP Address Port Priority Connections Status PRDID
1.2.34.56 400 1 0 0
例 13: スタック・トレースの生成
Windows オペレーティング・システムの場合は db2pd -stack all コマンド (UNIX オペレーティング・システムの場合は -stack コマンド) を使用すれば、 現在のデータベース・パーティションにあるすべてのプロセスのスタック・トレースを生成できます。 プロセスやスレッドがループ状態または停止状態にあると疑われる場合には、このコマンドを反復して使用できます。
db2pd -stack eduid コマンドを実行して、以下の例のように特定のエンジン・ディスパッチ可能単位 (EDU) の現在の呼び出しスタックを取得できます。
Attempting to dump stack trace for eduid 137.
See current DIAGPATH for trapfile.
DB2 プロセスに対するすべての呼び出しスタックを確認するには、db2pd -stack all コマンドを使用します。例えば、Windows オペレーティング・システムであれば、以下のようにします。
Attempting to dump all stack traces for instance.
See current DIAGPATH for trapfiles.
複数の物理ノードのあるパーティション・データベース環境では、コマンド db2_all "; db2pd -stack all" を使用することにより、すべてのパーティションから情報を取得できます。 しかし、同じマシン上の複数の論理パーティションだけから成る環境では、db2pd -alldbp -stacks を使用した方が速く動作します。
dumpdir パラメーターを指定して、db2sysc プロセスに対する db2pdb -stacks コマンドの出力を特定のディレクトリー・パスにリダイレクトすることもできます。timeout パラメーターを使用すると、特定の期間のみ出力をリダイレクトすることができます。 例えば、db2sysc プロセスのすべての EDU に関するスタック・トレースの出力を /home/waleed/mydir に 30 秒間リダイレクトするには、以下のコマンドを発行してください。
db2pd -alldbp -stack all dumpdir=/home/waleed/mydir timeout=30
例 14: データベース・パーティションのメモリー統計の表示
db2pd -dbptnmem コマンドは、DB2 サーバーが現在使用しているメモリーの量を表示します。また、サーバーのどの領域がそのメモリーを使用しているかの概要を表示します。
AIX® マシン上での db2pd -dbptnmem の実行による出力例を以下の例に示します。
Database Partition Memory Controller Statistics
Controller Automatic: Y
Memory Limit: 122931408 KB
Current usage: 651008 KB
HWM usage: 651008 KB
Cached memory: 231296 KB
- Controller Automatic (自動コントローラー)
- メモリー・コントローラーの設定を示します。instance_memory 構成パラメーターが AUTOMATIC に設定されている場合、値 Y を示します。これは、データベース・マネージャーが自動的にメモリー使用量の上限を決定することを意味します。
- Memory Limit (メモリーの限度)
- インスタンスのメモリー限度が強制される場合、instance_memory 構成パラメーターの値は、消費できる DB2 サーバー・メモリーの上限です。
- Current usage (現在の使用量)
- サーバーが現在使用しているメモリーの量。
- HWM usage (HWM 使用量)
- データベース・パーティションがアクティブ化されたとき (db2start コマンドの実行時) 以来消費された、最高水準点 (HWM)、つまりピーク時のメモリー使用量。
- Cached memory (キャッシュ済みメモリー)
- 現在の使用量のうちどの程度の量が、現在使用中でないものの、パフォーマンス上の理由で今後のメモリー要求のためにキャッシュに入れられているか。
AIX オペレーティング・システム上での db2pd -dbptnmem の実行による出力例の続きを以下に示します。
Individual Memory Consumers:
Name Mem Used (KB) HWM Used (KB) Cached (KB)
===========================================================
APPL-DBONE 160000 160000 159616
DBMS-name 38528 38528 3776
FMP_RESOURCES 22528 22528 0
PRIVATE 13120 13120 740
FCM_RESOURCES 10048 10048 0
LCL-p606416 128 128 0
DB-DBONE 406656 406656 67200
- Name
- メモリーの「コンシューマー」の簡潔な識別名。以下のものがあります。
- APPL-dbname
- データベース dbname について消費されるアプリケーション・メモリー。
- DBMS-name
- グローバル・データベース・マネージャーのメモリー所要量。
- FMP_RESOURCES
- db2fmps との通信に必要なメモリー。
- PRIVATE
- 各種の専用メモリー所要量。
- FCM_RESOURCES
- 高速コミュニケーション・マネージャーのリソース。
- LCL-pid
- ローカル・アプリケーションとの通信に使用されるメモリー・セグメント。
- DB-dbname
- データベース dbname について消費されるデータベース・メモリー。
- Mem Used (KB) (使用されているメモリー (KB))
- コンシューマーに現在割り当てられているメモリーの量。
- HWM Used (KB) (使用された HWM (KB))
- コンシューマーが使用した最高水準点 (HWM)、あるいはピーク時のメモリー。
- Cached (KB) (キャッシュ済み (KB))
- 「Mem Used (KB) (使用されているメモリー (KB))」のうち、現在使用中ではないものの、今後のメモリー割り振りのためにすぐに使用可能なメモリーの量。
例 15: 索引再編成の進行状況のモニター
- db2pd -reorgs index コマンドを使用すると、パーティション索引の索引 REORG 進行状況がレポートされます (フィックスパック 1 では、非パーティション索引に対するサポートのみが導入されました)。
- db2pd -reorgs index コマンドを使用すると、パーティション・レベルでの索引 REORG 操作 (つまり、単一パーティションの再編成) のモニターがサポートされます。
- 非パーティション索引とパーティション索引の REORG 進行状況は別々の出力でレポートされます。1 つの出力では非パーティション索引の REORG 進行状況が表示され、それに続く出力ではそれぞれの表パーティションのパーティション索引に関する REORG 進行状況が示されます。各出力でレポートされるのは、1 つのパーティションだけの索引 REORG 統計です。
- 非パーティション索引が最初に処理され、その後、順次パーティション索引が処理されます。
- db2pd -reorgs index コマンドを使用すると、パーティション索引の出力には、以下の追加情報フィールドが表示されます。
- MaxPartition - 処理されている表のパーティション総数。パーティション・レベルの REORG 操作の場合、MaxPartition の値は常に 1 です。一度に 1 つのパーティションだけが再編成されるからです。
- PartitionID - 処理中のパーティションのデータ・パーティション ID。
Index Reorg Stats:
Retrieval Time: 02/08/2010 23:04:21
TbspaceID: -6 TableID: -32768
Schema: ZORAN TableName: BIGRPT
Access: Allow none
Status: Completed
Start Time: 02/08/2010 23:03:55 End Time: 02/08/2010 23:04:04
Total Duration: 00:00:08
Prev Index Duration: -
Cur Index Start: -
Cur Index: 0 Max Index: 2 Index ID: 0
Cur Phase: 0 ( - ) Max Phase: 0
Cur Count: 0 Max Count: 0
Total Row Count: 750000
Retrieval Time: 02/08/2010 23:04:21
TbspaceID: 2 TableID: 5
Schema: ZORAN TableName: BIGRPT
PartitionID: 0 MaxPartition: 2
Access: Allow none
Status: Completed
Start Time: 02/08/2010 23:04:04 End Time: 02/08/2010 23:04:08
Total Duration: 00:00:04
Prev Index Duration: -
Cur Index Start: -
Cur Index: 0 Max Index: 2 Index ID: 0
Cur Phase: 0 ( - ) Max Phase: 0
Cur Count: 0 Max Count: 0
Total Row Count: 375000
Retrieval Time: 02/08/2010 23:04:21
TbspaceID: 2 TableID: 6
Schema: ZORAN TableName: BIGRPT
PartitionID: 1 MaxPartition: 2
Access: Allow none
Status: Completed
Start Time: 02/08/2010 23:04:08 End Time: 02/08/2010 23:04:12
Total Duration: 00:00:04
Prev Index Duration: -
Cur Index Start: -
Cur Index: 0 Max Index: 2 Index ID: 0
Cur Phase: 0 ( - ) Max Phase: 0
Cur Count: 0 Max Count: 0
Total Row Count: 375000
例 16: プロセッサー時間の消費別の上位 EDU の表示と EDU スタック情報の表示
-edus パラメーター・オプションを指定して db2pd コマンドを発行すると、すべてのエンジン・ディスパッチ可能単位 (EDU) が出力中にリストされます。EDU の出力を、インスタンス・レベルやメンバー・レベルなど、細分度のレベルを指定して戻すことができます。Linux および UNIX オペレーティング・システムに限り、interval パラメーター・サブオプションを指定して、すべての EDU のスナップショットを指定した間隔だけ空けて 2 つ取ることもできます。interval パラメーターを指定すると、出力中に 2 つの列が追加され、この間隔の前後のプロセッサー・ユーザー時間の差分 (USR DELTA 列) と、プロセッサー・システム時間の差分 (SYS DELTA 列) が示されます。
以下の例では、5 秒間のプロセッサー・ユーザー時間の差分とプロセッサー・システム時間の差分が示されます。
$ db2pd -edus interval=5
Database Partition 0 -- Active -- Up 0 days 00:53:29 -- Date 06/04/2010 03:34:59
List of all EDUs for database partition 0
db2sysc PID: 1249522
db2wdog PID: 2068678
EDU ID TID Kernel TID EDU Name USR SYS USR DELTA SYS DELTA
===================================================================================================
6957 6957 13889683 db2agntdp (SAMPLE ) 0 58.238506 0.820466 1.160726 0.014721
6700 6700 11542589 db2agent (SAMPLE) 0 52.856696 0.754420 1.114821 0.015007
5675 5675 4559055 db2agntdp (SAMPLE ) 0 60.386779 0.854234 0.609233 0.014304
3088 3088 13951225 db2agntdp (SAMPLE ) 0 80.073489 2.249843 0.499766 0.006247
3615 3615 2887875 db2loggw (SAMPLE) 0 0.939891 0.410493 0.011694 0.004204
4900 4900 6344925 db2pfchr (SAMPLE) 0 1.748413 0.014378 0.014343 0.000103
7986 7986 13701145 db2agntdp (SAMPLE ) 0 1.410225 0.025900 0.003636 0.000074
2571 2571 8503329 db2ipccm 0 0.251349 0.083787 0.002551 0.000857
7729 7729 14168193 db2agntdp (SAMPLE ) 0 1.717323 0.029477 0.000998 0.000038
7472 7472 11853991 db2agnta (SAMPLE) 0 1.860115 0.032926 0.000860 0.000012
3358 3358 2347127 db2loggr (SAMPLE) 0 0.151042 0.184726 0.000387 0.000458
515 515 13820091 db2aiothr 0 0.405538 0.312007 0.000189 0.000178
7215 7215 2539753 db2agntdp (SAMPLE ) 0 1.165350 0.019466 0.000291 0.000008
6185 6185 2322517 db2wlmd (SAMPLE) 0 0.061674 0.034093 0.000169 0.000100
6442 6442 2756793 db2evmli (DB2DETAILDEADLOCK) 0 0.072142 0.052436 0.000092 0.000063
4129 4129 15900799 db2glock (SAMPLE) 0 0.013239 0.000741 0.000064 0.000001
2 2 11739383 db2alarm 0 0.036904 0.028367 0.000009 0.000009
4386 4386 13361367 db2dlock (SAMPLE) 0 0.015653 0.001281 0.000014 0.000003
1029 1029 15040579 db2fcms 0 0.041929 0.016598 0.000010 0.000004
5414 5414 14471309 db2pfchr (SAMPLE) 0 0.000093 0.000002 0.000000 0.000000
258 258 13656311 db2sysc 0 8.369967 0.263539 0.000000 0.000000
5157 5157 7934145 db2pfchr (SAMPLE) 0 0.027598 0.000177 0.000000 0.000000
1543 1543 2670647 db2fcmr 0 0.004191 0.000079 0.000000 0.000000
1286 1286 8417339 db2extev 0 0.000312 0.000043 0.000000 0.000000
2314 2314 14360813 db2licc 0 0.000371 0.000051 0.000000 0.000000
5928 5928 3137537 db2taskd (SAMPLE) 0 0.004903 0.000572 0.000000 0.000000
3872 3872 2310357 db2lfr (SAMPLE) 0 0.000126 0.000007 0.000000 0.000000
4643 4643 11694287 db2pclnr (SAMPLE) 0 0.000094 0.000002 0.000000 0.000000
1800 1800 5800175 db2extev 0 0.001212 0.002137 0.000000 0.000000
772 772 7925817 db2thcln 0 0.000429 0.000072 0.000000 0.000000
2057 2057 6868993 db2pdbc 0 0.002423 0.001603 0.000000 0.000000
2828 2828 10866809 db2resync 0 0.016764 0.003098 0.000000 0.000000
プロセッサー時間を最も消費している EDU に関する情報のみに限定して、戻される出力の量を少なくするには、さらに top パラメーター・オプションを組み込むことができます。以下の例では、5 秒の間隔での上位 5 つの EDU のみが戻されます。スタック情報も戻され、DUMPDIR で指定されたディレクトリー・パス (デフォルトは diagpath) 内に別個に保管されることになります。
$ db2pd -edus interval=5 top=5 stacks
Database Partition 0 -- Active -- Up 0 days 00:54:00 -- Date 06/04/2010 03:35:30
List of all EDUs for database partition 0
db2sysc PID: 1249522
db2wdog PID: 2068678
EDU ID TID Kernel TID EDU Name USR SYS USR DELTA SYS DELTA
===============================================================================================================
3358 3358 2347127 db2loggr (SAMPLE) 0 0.154906 0.189223 0.001087 0.001363
3615 3615 2887875 db2loggw (SAMPLE) 0 0.962744 0.419617 0.001779 0.000481
515 515 13820091 db2aiothr 0 0.408039 0.314045 0.000658 0.000543
258 258 13656311 db2sysc 0 8.371388 0.264812 0.000653 0.000474
6700 6700 11542589 db2agent (SAMPLE) 0 54.814420 0.783323 0.000455 0.000310
$ ls -ltr
total 552
drwxrwxr-t 2 vbmithun build 256 05-31 09:59 events/
drwxrwxr-t 2 vbmithun build 256 06-04 03:17 stmmlog/
-rw-r--r-- 1 vbmithun build 46413 06-04 03:35 1249522.3358.000.stack.txt
-rw-r--r-- 1 vbmithun build 22819 06-04 03:35 1249522.3615.000.stack.txt
-rw-r--r-- 1 vbmithun build 20387 06-04 03:35 1249522.515.000.stack.txt
-rw-r--r-- 1 vbmithun build 50426 06-04 03:35 1249522.258.000.stack.txt
-rw-r--r-- 1 vbmithun build 314596 06-04 03:35 1249522.6700.000.stack.txt
-rw-r--r-- 1 vbmithun build 94913 06-04 03:35 1249522.000.processObj.txt
例 17: エージェント・イベント・メトリックの表示
db2pd コマンドは、エージェントのイベント・メトリックを返す機能をサポートします。 特定の期間にエージェントが状態を変更したかどうかを判断する必要がある場合は、event オプションを -agents パラメーターと共に使用します。 返される AGENT_STATE_LAST_UPDATE_TIME(Tick Value) 列は、エージェントによって処理されているイベントが最後に変更された時刻を示します。 AGENT_STATE_LAST_UPDATE_TIME(Tick Value) について以前取得した値と見比べて、エージェントが新しいタスクに移動したか、または長時間にわたって同じタスクを継続して処理しているか判別できます。
db2pd -agents event
Database Partition 0 -- Active -- Up 0 days 03:18:52 -- Date 06/27/2011 11:47:10
Agents:
Current agents: 12
Idle agents: 0
Active coord agents: 10
Active agents total: 10
Pooled coord agents: 2
Pooled agents total: 2
AGENT_STATE_LAST_UPDATE_TIME(Tick Value) EVENT_STATE EVENT_TYPE EVENT_OBJECT EVENT_OBJECT_NAME
2011-06-27-14.44.38.859785(5622972377924968075) IDLE WAIT REQUEST n/a
例 18: エクステント移動の表示
$ db2pd -extentmovement -db PDTEST
Database Member 0 -- Database PDTEST -- Active -- Up 0 days 00:04:33 -- Date 2012-10-26-11.19.52.056414
Extent Movement:
Address TbspName Current Last Moved Left TotalTime
0x00002AAB356D4BA0 DAVID 1168 1169 33 426 329636