演習 6: WLM 表関数を使用した遅延の調査

ステップ 1: アクティビティーの実行

この演習では、app1.db2 と app2.db2 の 2 つのアプリケーションを使用します。 両方のアプリケーションとも SAMPLE データベースに対して DML 操作を実行します。 app1.db2 スクリプトを 1 つのウィンドウで実行し、その直後に 2 番目のウィンドウで app2.db2 スクリプトを実行します。

db2 -tvf app1.db2
db2 -tvf app2.db2

ステップ 2: 現在アクティブなワークロード・オカレンスの表示

これで、app2.db2 スクリプトがハングするはずです。 3 つ目のウィンドウから、表関数 WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES を発行して、データベース上で実行しているすべてのアプリケーションの状態を検索します。 この例では、ワークロード・オカレンスをアプリケーションと同じものと見なしてかまいません。 この表関数は、サービス・クラス内のワークロード・オカレンスすべてに関する情報を表示します。 データベース中のすべてのワークロード・オカレンスを表示したいので、入力パラメーター service_superclass_name および service_subclass_name には、'' で表されるワイルドカードを使用します。

CONNECT TO SAMPLE

SELECT INTEGER(APPLICATION_HANDLE) APPL_HANDLE,
   VARCHAR(CLIENT_APPLNAME, 15) AS APPL_NAME,
   VARCHAR(SYSTEM_AUTH_ID, 20) AS USER_ID
   FROM TABLE
   (WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES('', '', -2))

出力は、以下のようになります。

APPL_HANDLE APPL_NAME       USER_ID                    
----------- --------------- --------------------
         12 CLP app1.db2    DB2USR1
         17 CLP app2.db2    DB2USR1
         18 -               DB2USR1
         19 -               DB2USR1

  4 record(s) selected.

出力から、app2.db2 のアプリケーション・ハンドルが 17 であることがわかります。

ステップ 3: アプリケーションのエージェントの検索

app2.db2 のエージェントが何を実行しているかを調べるには、WLM_GET_SERVICE_CLASS_AGENTS 表関数を使用します。 この表関数は、サービス・クラス内で作動しているエージェントに関する情報を表示します。 アプリケーション・ハンドル 17 に関する作動中のエージェントを表示するので、このハンドルを application_handle 入力パラメーターで指定します。 この例の場合、特定のサービス・クラスのエージェントは対象ではないので、service_superclass_name および service_subclass_name 入力パラメーターにワイルドカードを指定します。

SELECT INTEGER(APPLICATION_HANDLE) AS APPL_HANDLE,
   UOW_ID, ACTIVITY_ID,
   VARCHAR(AGENT_TYPE, 15) AS AGENT_TYPE,
   VARCHAR(AGENT_STATE, 10) AS AGENT_STATE,
   VARCHAR(EVENT_TYPE, 10) AS EVENT_TYPE,
   VARCHAR(EVENT_OBJECT, 10) AS EVENT_OBJ,
   VARCHAR(EVENT_STATE, 10) AS EVENT_STATE
FROM TABLE
   (WLM_GET_SERVICE_CLASS_AGENTS('', '', 17, -2))

出力は、以下のようになります。

APPL_HANDLE UOW_ID      ACTIVITY_ID AGENT_TYPE      AGENT_STATE EVENT_TYPE
EVENT_OBJ  EVENT_STATE
----------- ----------- ----------- --------------- ----------- ----------
---------- -----------
         17           1           2 COORDINATOR     ACTIVE      ACQUIRE   
LOCK       IDLE       

  1 record(s) selected.

この出力から、アプリケーション 17 のコーディネーター・エージェントがアイドル状態で、ロックの獲得を待っていることが分かります。 これが、app2.db2 がハングしているように見える理由です。

ステップ 4: 問題アプリケーションの検索と問題の解決

アプリケーションがハングしている理由が分かったので、状態に対処できます。 アプリケーションがロックを待っていることが分かっています。 このアプリケーションが待っているロックと、そのロックを保持しているアプリケーションを検出するには、db2pd ツールを使用できます。 最初にハングしているアプリケーションの現行トランザクション番号を検出する必要があります。アプリケーション・ハンドル 17 を対象に db2pd -transactions を発行します。

db2pd -db sample -transactions app=17

出力は、以下のようになります。

Address            AppHandl [nod-index]  TranHdl    Locks      State  
Tflag      Tflag2     Firstlsn       Lastlsn        LogSpace       
SpaceReserved   TID            AxRegCnt   GXID
    
0x07000000302A7080 17       [000-00017] 7          5          READ 
0x00000000 0x00000000 0x000000000000 0x000000000000 0              
0               0x000000000AC3 1          0

この出力から、アプリケーション 17 にトランザクション・ハンドル 7 があることが分かります。 トランザクション・ハンドル 7 を対象に db2pd -locks コマンドを発行すると、このトランザクションが待っているロックを検索できます。

db2pd -db sample -locks 7 wait

出力は、以下のようになります。

Address            TranHdl    Lockname                   Type       Mode Sts
Owner      Dur HoldCount  Att  ReleaseFlg
0x07000000304013F0 7          00020010000000000640002D52 Row        .NS  W  
2          1   0          0x00 0x00000002

この出力は、アプリケーションが行ロックを待っていることを示しています。 ロックの所有者は、トランザクション・ハンドル 2 を持っています。 このトランザクションがロックを保持していて、ハングの原因になっています。 最後のステップは、トランザクション・ハンドル 2 に対応するアプリケーション・ハンドルを確認することです。 トランザクション・ハンドル 2 に対して db2pd -transactions コマンドを実行します。

db2pd -db sample -transactions 2

出力は、以下のようになります。

Address            AppHandl [nod-index] TranHdl    Locks      State  
Tflag      Tflag2     Firstlsn       Lastlsn        LogSpace       
SpaceReserved   TID            AxRegCnt   GXID    
0x07000000302A2080 12       [000-00012] 2          6          WRITE 
0x00000000 0x00000000 0x000002EE000C 0x000002EE005E 232            
396             0x000000000ABB 1          0

この出力から、トランザクション・ハンドル 2 がアプリケーション・ハンドル 12 に対応していることが分かります。 表関数 WLM_GET_SERVICE_CLASS_WORKLOAD_OCCURRENCES の結果を確認すると、アプリケーション 12 が app1.db2 を参照していることが分かります。 このアプリケーションは、 app2.db2が必要とする行ロックを保持しています。  app2.db2 を続行するには、 app1.db2を実行しているウィンドウから、作業単位またはプロセスをコミット、ロールバック、または終了することができます。  あるいは、アプリケーション・ハンドル 12 で FORCE APPLICATION を発行して、 app1.db2 を強制的にオフにすることもできます。

db2 force application (12)

追加情報: ロック競合のためにハングしているアプリケーションを診断する別の方法として、モニター表関数の MON_GET_APPL_LOCKWAIT と MON_FORMAT_LOCK_NAME を使用できます。 これらの表関数は、ロックの保持者と待機者に関する情報を提供します。