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 ごとに、イベント・モニターがデータを書き込むターゲットに関する統計および情報も返されます。

この例の結果テキストは、db2cmd コマンド出力の読みやすくした抜粋です。

例 1: ロック待機の診断

db2pd -db databasename -locks -transactions -applications -dynamicを実行すると、結果は以下のようなものになります。
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 パラメーターの使用

db2pd -wlocks -db pdtest を実行すると、以下のような結果が生成されます。 これらの結果は、最初のアプリケーション (AppHandl 47) が表に対して挿入を実行し、 2 番目のアプリケーション (AppHandl 46) その表に対して選択を実行していることを示しています。
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: ロックに関係している表名とスキーマ名の表示

バージョン 11.5以降では、 db2pd -locks showlocks コマンドを使用して、アプリケーションが保持しているロックの表名とスキーマ名を表示できます。 この情報を使用して、アプリケーション・ロックが含まれる表とスキーマを診断することができます。 次の出力に示すように、表名は TableNm 列に表示され、スキーマ名は SchemaNm 列に表示されます。
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)
また、 db2pd -wlocks detail コマンドを使用して、待機されているロックに関する表名、スキーマ名、およびアプリケーション・ノードを以下の出力に示すように表示できます。
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 パラメーターの使用

例 2 と同じ条件では、以下のような出力例が生成されました。
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: ロッキング問題を検討するときのコールアウト・スクリプトの使用

コールアウト・スクリプトを使用するには、db2cos 出力ファイルを見つけます。 このファイルの場所は、データベース・マネージャー構成パラメーター diagpath によって制御されます。 出力ファイルの内容は、db2cos スクリプト・ファイルに入力するコマンドによって異なります。 db2cos スクリプト・ファイルに db2pd -db sample -locks コマンドが含まれている場合に提供される出力の例を以下に示します。
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
MinRecTime 列は、UTC タイム・ゾーン・フォーマットの UNIX タイム・スタンプ値を返します。 値を GMT タイム・ゾーン形式に変換するには、 Db2 タイム・スタンプ関数を使用できます。 例えば、MinRecTime が値 1369626329 を返す場合、この値を GMT フォーマットに変換するには、次のステートメントを実行します。
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 の実行で使用されます。

db2pd -agent からの出力は、アプリケーションによって読み込まれた行数 (Rowsread 列) と書き込まれた行数 (Rowswrtn 列) を示しています。 これらの値によって、以下の出力例のように、アプリケーションが何を完了し、何をまだ完了していないかがわかります。
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 の値は、ログ位置を示します。 「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
Cur Commit Disk Log Reads     0
Cur Commit Total Log Reads    0
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
Log Chain ID                  0
Extraction Status             n/a
Current Log to Extract        n/a
Current LSO                   28672000
Current LSN                   0x00000022F032

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
この出力を使用することにより、2 種類の問題を識別できます。
  • 最新のログ・アーカイブが失敗した場合、 Archive Status は値 Failureに設定されます。 進行中のアーカイブ障害があり、ログがまったくアーカイブされない場合、 Archive Status の値は First Failureに設定されます。
  • ログ・アーカイブの進行が非常に遅い場合、 Next Log to Archive 値は Current Log Number 値より小さくなります。 アーカイブ処理が非常に遅い場合には、アクティブ・ログ用のスペースがなくなり、 データベース内のデータがまったく変更されなくなる可能性があります。
注: S0000003.LOG および S0000004.LOG にはまだログ・レコードが含まれていないため、 StartLSN は 0x0 になります。

例 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: スタック・トレースの生成

db2pd -stack all コマンド (Windows オペレーティング・システムの場合) または -stack コマンド (UNIX オペレーティング・システムの場合) を使用して、現行データベース・パーティション内のすべてのプロセスのスタック・トレースを作成できます。 プロセスやスレッドがループ状態または停止状態にあると疑われる場合には、このコマンドを反復して使用できます。

以下の例に示すように、コマンド 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 を使用した方が速く動作します。

db2sysc プロセスの db2pdb -stacks コマンドの出力を、 dumpdir パラメーターを使用して特定のディレクトリー・パスにリダイレクトすることもできます。 timeout パラメーターを使用すると、特定の期間のみ出力をリダイレクトすることができます。 例えば、db2sysc プロセスのすべての EDU に関するスタック・トレースの出力を /home/waleed/mydir に 30 秒間リダイレクトするには、以下のコマンドを発行してください。

db2pd -alldbp -stack all dumpdir=/home/waleed/mydir timeout=30

例 14: データベース・パーティションのインスタンス・メモリー統計の表示

db2pd -dbptnmem コマンドは、Db2 サーバーが現在使用しているメモリーの量を表示します。また、サーバーのどの領域がそのメモリーを使用しているかの概要を表示します。 インスタンス・メモリー使用量には、実際のシステム・メモリーの消費量/コミットメントだけでなく、使用/コミットされない可能性がある構成済みの割り当て量も含まれます。 したがって、 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 (自動コントローラー)
メモリー・コントローラーの設定を示します。 「Y」に設定されている (instance_memory 構成パラメーターが AUTOMATIC に設定されている) 場合は、製品ライセンスにメモリー制限が含まれている場合にのみ、計算された限度が適用されます。 「N」に設定されている場合は、指定された限度が適用されます。
Memory Limit (メモリーの限度)
インスタンスのメモリー限度が強制される場合、instance_memory 構成パラメーターの値は、消費できるインスタンス・メモリーの上限です。
現在の使用量
サーバーが現在使用しているインスタンス・メモリーの量。
HWM usage (HWM 使用量)
データベース・パーティションがアクティブ化されたとき (db2start コマンドの実行時) 以来消費された、最高水準点 (HWM)、つまりピーク時のインスタンス・メモリー使用量。
Cached memory (キャッシュ済みメモリー)
現在の使用量のうち、再利用が可能な量。 これは、適用された限度にインスタンス・メモリーの使用量が近づき、他のコンシューマーの使用量を増加させるために 1 つ以上のコンシューマーのキャッシュ量を減らす必要が生じた場合に適用されます。

以下は、 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
Db2 サーバー内のインスタンス・メモリーのすべての登録済み コンシューマー が、消費しているインスタンス・メモリーの合計量とともにリストされます。 列の説明は以下のとおりです。
名前
インスタンス・メモリーの「コンシューマー」の簡潔な識別名。以下のものがあります。
APPL-DB 名
データベース dbname について消費されるアプリケーション・メモリー。
DBMS-名前
グローバル・データベース・マネージャーのメモリー所要量。
FMP_RESOURCES
db2fmps との通信に必要なメモリー。
PRIVATE
各種の専用メモリー所要量。
FCM_RESOURCES
高速コミュニケーション・マネージャーのリソース。
LCL-PID
ローカル・アプリケーションとの通信に使用されるメモリー・セグメント。
DB-DB 名
データベース dbname について消費されるデータベース・メモリー。
Mem Used (KB) (使用されているメモリー (KB))
コンシューマーに現在割り当てられているインスタンス・メモリーの量。
HWM Used (KB) (使用された HWM (KB))
コンシューマーが使用した最高水準点 (HWM)、つまり、ピーク時のインスタンス・メモリー。
Cached (KB) (キャッシュ済み (KB))
「Mem Used (KB) (使用されているメモリー (KB))」のうち、このコンシューマーで再利用できるインスタンス・メモリーの量。

例 15: 索引再編成の進行状況のモニター

Db2 バージョン 9.8 フィックスパック 3 以降、索引再編成の進行状況レポートには、以下の特性があります。
  • db2pd -reorgs index コマンドを使用すると、パーティション索引の索引 REORG 進行状況がレポートされます (フィックスパック 1 では、非パーティション索引に対するサポートのみが導入されました)。
  • db2pd -reorgs index コマンドを使用すると、パーティション・レベルでの索引 REORG 操作 (つまり、単一パーティションの再編成) のモニターがサポートされます。
  • 非パーティション索引とパーティション索引の REORG 進行状況は別々の出力でレポートされます。 1 つの出力では非パーティション索引の REORG 進行状況が表示され、それに続く出力ではそれぞれの表パーティションのパーティション索引に関する REORG 進行状況が示されます。各出力でレポートされるのは、1 つのパーティションだけの索引 REORG 統計です。
  • 非パーティション索引が最初に処理され、その後、順次パーティション索引が処理されます。
  • db2pd -reorgs index コマンドを使用すると、パーティション索引の出力には、以下の追加情報フィールドが表示されます。
    • MaxPartition-処理中の表のパーティションの合計数。 パーティション・レベルの REORG の場合、MaxPartition1 つのパーティションのみが再編成されるため、値は常に 1 になります。
    • PartitionID-処理中のパーティションのデータ・パーティション ID。
以下の例は、db2pd -reorgs index コマンドを使用した出力例を示し、2 つのパーティションがある範囲パーティション表の索引 REORG 進行状況がレポートされています。
注: 最初の出力では、非パーティション索引の索引 REORG 統計が報告されます。 続く出力では、各パーティションにあるパーティション索引の索引 REORG 状況がレポートされています。
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 dbName コマンドを発行して、表スペースのエクステント移動状況を表示することができます。
$ 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