モニター

キューイング動作とリソース使用量について深く理解するために照会をモニターします。

現行ワークロードのリソース要求がデータベース・サーバーの構成済みリソース容量を超えるときには常に、照会はキューに入れられます。 キューイングは予期される動作であり、それ自体が問題またはエラーを示しているわけではありません。 ただし、一部のアプリケーションや照会では予期しないキューイングが発生して、不必要な遅延が生じることがあります。 例えば、データベース・リソースを 100% 近く消費する長時間実行の照会は、他の着信作業をブロックする可能性があります。 表関数を介して公開されるモニター・エレメントを使用して、キューイングの動作を理解し、リソースを最も多く消費する照会を識別できます。 必要であれば、FORCE APPLICATION コマンドを使用して、問題のある照会をサブミットしたアプリケーションを終了することにより、その照会を取り消すことができます。

一般的に使用されるいくつかのモニター照会を例として以下に示します。 モニターについて詳しくは、以下を参照してください。
モニター照会を発行する前に、モニターを実行する接続をデフォルトの管理ワークロード (SYSDEFAULTADMWORKLOAD) に配置します。 こうすることで、モニター照会自体はキューに入れられなくなります。 これを行うには、WLM_SET_CLIENT_INFO ストアード・プロシージャーを使用し、入力ワークロード名として SYSDEFAULTADMWORKLOAD を指定します。以下に例を示します。
CALL WLM_SET_CLIENT_INFO(null,null,null,null,'SYSDEFAULTADMWORKLOAD')
この接続でモニター照会が完了した後、接続をデフォルトの管理ワークロードから削除します。 これを行うには、接続をクローズするか、WLM_SET_CLIENT_INFO ストアード・プロシージャーを再発行し、入力ワークロード名として NULL を指定します。以下に例を示します。
CALL WLM_SET_CLIENT_INFO(null,null,null,null,null)
データベースでの全体的なキューイング動作を理解するには、 MON_GET_DATABASE 表関数を使用して以下の情報を表示します。
  • 正常に完了した照会の数
  • 異常終了または失敗した照会の数
  • キューに入れられたステートメント数
  • アプリケーション要求の実行に費やされた合計経過時間
  • 合計キュー時間
これらの結果を使用して、キューに入れられている照会の割合と、それぞれがキューに入れられている平均時間を計算できます。
SELECT SUM(ACT_COMPLETED_TOTAL) AS STMTS_COMPLETED, 
       SUM(ACT_ABORTED_TOTAL) AS STMTS_FAILED, 
       SUM(WLM_QUEUE_ASSIGNMENTS_TOTAL) AS STMTS_QUEUED, 
       CASE WHEN (SUM(ACT_COMPLETED_TOTAL + ACT_ABORTED_TOTAL) > 0) THEN
          DEC((FLOAT(SUM(WLM_QUEUE_ASSIGNMENTS_TOTAL))/FLOAT(SUM(ACT_COMPLETED_TOTAL + ACT_ABORTED_TOTAL))) * 100, 5, 2) 
       ELSE
          0
       END AS PCT_STMTS_QUEUED, 
       SUM(TOTAL_APP_RQST_TIME) AS RQST_TIME_MS, 
       CASE WHEN (SUM(ACT_COMPLETED_TOTAL + ACT_ABORTED_TOTAL) > 0) THEN 
          SUM(TOTAL_APP_RQST_TIME) / SUM(ACT_COMPLETED_TOTAL + ACT_ABORTED_TOTAL)
       ELSE
          0
       END AS AVG_APP_RQST_TIME_MS, 
       SUM(WLM_QUEUE_TIME_TOTAL) AS TOTAL_QUEUE_TIME_MS, 
       CASE WHEN (SUM(WLM_QUEUE_ASSIGNMENTS_TOTAL) > 0) THEN
          SUM(WLM_QUEUE_TIME_TOTAL) / SUM(WLM_QUEUE_ASSIGNMENTS_TOTAL) 
       ELSE
          0
       END AS AVG_QUEUE_TIME_MS 
FROM TABLE(MON_GET_DATABASE(-2)) AS T
出力例:
STMTS_COMPLETED      STMTS_FAILED         STMTS_QUEUED         PCT_STMTS_QUEUED RQST_TIME_MS         AVG_APP_RQST_TIME_MS TOTAL_QUEUE_TIME_MS  AVG_QUEUE_TIME_MS   
-------------------- -------------------- -------------------- ---------------- -------------------- -------------------- -------------------- --------------------
                 365                    2                    5             1.36              7040323                19183              6998224              1399644
キューイングの影響を受けているのは実行された照会の 1.36% だけですが、平均キュー時間 (1399644 ミリ秒。これは、約 23 分に相当する) はかなり長いことがこの出力からわかります。
現在実行中の照会やキューに入れられている照会の数など、データベース・アクティビティーの現在の状態をさらに理解するには、MON_GET_ACTIVITY 表関数を使用します。
  • EXECUTING 状態の照会は、現在リソースを消費していて、データベース・エンジンによって処理されています。
  • IDLE 状態の照会は、現在リソースを消費していますが、クライアント上でブロックされていて、次のクライアント要求を待機しています。
  • QUEUED 状態の照会は、リソースを待機しています。
以下のモニター照会は、照会の総数と、アダプティブ・ワークロード・マネージャーをバイパスしたためにキューに入れることのできない照会の数を戻します。
SELECT ACTIVITY_STATE, 
       SUM(ADM_BYPASSED) AS BYPASSED, 
       COUNT(*)
FROM TABLE(MON_GET_ACTIVITY(NULL,-1)) AS T
GROUP BY ACTIVITY_STATE
出力例:
ACTIVITY_STATE                   BYPASSED             COUNT                            
-------------------------------- -------------------- ---------------------------------
EXECUTING                                           1                                1
IDLE                                                0                                2
QUEUED                                              0                                1
この出力は、2 つの照会が IDLE 状態でクライアントからの要求を待っており、 1 つの照会がキューに入れられ、1 つの照会が実行中であることを示しています。 実行中の照会は、アダプティブ・ワークロード・マネージャーをバイパスしています。
最も制約の大きなリソースは、スレッド数とソート・メモリー量のどちらであるかを知るために、 SYSIBMADM.DBCFG ビューを使用して構成済みのリソースを表示し、MON_GET_ACTIVITY および MON_GET_DATABASE 表関数を使用して現在のリソース消費状況を理解してください。
  • 使用されるスレッドの数はほとんどの照会で同じなので、最も制約の大きなリソースがスレッドである場合、キューイングの原因となっているのは、並行照会のボリュームです。(単純化のため、以下の照会では、アクティビティーがデフォルトの度合いを使用していて、コアあたりのスレッド数は 1 であると想定しています。したがって、単純にアクティビティーの数をカウントすることで、コアあたりの現在の負荷がわかります。)
  • 最も制約の大きなリソースがソート・メモリーである場合は、このトピックで後述するモニター照会を使用して、ソート・メモリーを最も多く消費している照会の名前と状態を識別します。
WITH LOADTRGT(LOADTRGT) AS (SELECT MAX(VALUE) FROM SYSIBMADM.DBCFG WHERE NAME = 'wlm_agent_load_trgt'),
     SORTMEM (SHEAPTHRESSHR, SHEAPMEMBER) AS (SELECT VALUE, MEMBER FROM SYSIBMADM.DBCFG WHERE NAME = 'sheapthres_shr'),
     STMTS(NUMSTMT) AS (SELECT COUNT(*) FROM TABLE(MON_GET_ACTIVITY(NULL,-2)) 
       AS T WHERE ADM_BYPASSED = 0 AND (ACTIVITY_STATE = 'EXECUTING' OR ACTIVITY_STATE = 'IDLE') AND MEMBER=COORD_PARTITION_NUM),
     ALLOCMEM(ALLOCMEM, ALLOCMEMBER) AS (SELECT SORT_SHRHEAP_ALLOCATED, MEMBER FROM TABLE(MON_GET_DATABASE(-2)) AS T)
SELECT MAX(DEC((FLOAT(ALLOCMEM)/FLOAT(SHEAPTHRESSHR))*100, 5,2)) AS PERCENT_SORTMEM_USED, 
       MAX(DEC((FLOAT(NUMSTMT)/FLOAT(LOADTRGT))*100,5,2)) AS PERCENT_THREADS_USED
FROM LOADTRGT, SORTMEM, STMTS, ALLOCMEM
WHERE SHEAPMEMBER=ALLOCMEMBER
出力例:

PERCENT_SORTMEM_USED PERCENT_THREADS_USED
-------------------- --------------------
               76.99                11.76
この出力は、ソート・メモリーが最も制約の大きなリソースであることを示しています。
現在実行中のアクティビティーのリソース消費量と状態を理解するには、MON_GET_ACTIVITY 表関数を使用します。 次のモニター照会は、以下の情報を戻します。
  • リソース情報 (effective_query_degree、sort_shrheap_allocated、sort_shrheap_top)
  • 照会がアダプティブ・ワークロード・マネージャーをバイパスしたかどうか (adm_bypassed)
  • 現在の状態 (EXECUTING または IDLE)
  • 照会のソースを識別するために使用できる情報 (セッション許可 ID、アプリケーション名、ステートメント・テキストなど)
WITH TOTAL_MEM(CFG_MEM, MEMBER) AS (SELECT VALUE, MEMBER FROM SYSIBMADM.DBCFG WHERE NAME = 'sheapthres_shr')
SELECT A.MEMBER,
       A.COORD_MEMBER,
       A.ACTIVITY_STATE,
       A.APPLICATION_HANDLE,
       A.UOW_ID,
       A.ACTIVITY_ID,
       B.APPLICATION_NAME,
       B.SESSION_AUTH_ID,
       B.CLIENT_IPADDR,
       A.ENTRY_TIME,
       A.LOCAL_START_TIME,
       CASE WHEN (A.LOCAL_START_TIME IS NOT NULL) THEN
             TIMESTAMPDIFF(2, CHAR(A.LOCAL_START_TIME - A.ENTRY_TIME))
       ELSE
             A.WLM_QUEUE_TIME_TOTAL/1000
       END AS TOTAL_QUEUETIME_SECONDS,
       CASE WHEN (A.LOCAL_START_TIME IS NOT NULL) THEN
             TIMESTAMPDIFF(2, CHAR(CURRENT_TIMESTAMP-A.LOCAL_START_TIME))
       ELSE
             NULL
       END AS TOTAL_RUNTIME_SECONDS,
       CASE WHEN (A.LOCAL_START_TIME IS NOT NULL) THEN
             TIMESTAMPDIFF(2, CHAR(CURRENT_TIMESTAMP-A.LOCAL_START_TIME))-A.COORD_STMT_EXEC_TIME/1000
       ELSE
             NULL
       END AS TOTAL_CLIENT_WAIT_SECONDS,
       A.ADM_BYPASSED,
       A.EFFECTIVE_QUERY_DEGREE,
       A.QUERY_COST_ESTIMATE,
       A.ESTIMATED_RUNTIME,
       A.ESTIMATED_SORT_SHRHEAP_TOP AS ESTIMATED_SORTMEM_USED_PAGES,
       DEC((FLOAT(A.ESTIMATED_SORT_SHRHEAP_TOP)/FLOAT(C.CFG_MEM)) * 100, 5, 2) AS ESTIMATED_SORTMEM_USED_PCT,
       A.SORT_SHRHEAP_ALLOCATED AS SORTMEM_USED_PAGES,
       DEC((FLOAT(A.SORT_SHRHEAP_ALLOCATED)/FLOAT(C.CFG_MEM)) * 100, 5, 2) AS SORTMEM_USED_PCT,
       SORT_SHRHEAP_TOP AS PEAK_SORTMEM_USED_PAGES,
       DEC((FLOAT(A.SORT_SHRHEAP_TOP)/FLOAT(C.CFG_MEM)) * 100, 5, 2) AS PEAK_SORTMEM_USED_PCT,
       C.CFG_MEM AS CONFIGURED_SORTMEM_PAGES, 
       SUBSTR(A.STMT_TEXT, 1, 512) AS STMT_TEXT
FROM TABLE(MON_GET_ACTIVITY(NULL,-2)) AS A,
        TABLE(MON_GET_CONNECTION(NULL,-1)) AS B,
        TOTAL_MEM AS C
WHERE (A.APPLICATION_HANDLE = B.APPLICATION_HANDLE) AND (A.MEMBER = C.MEMBER)
ORDER BY MEMBER, APPLICATION_HANDLE, UOW_ID, ACTIVITY_ID, ACTIVITY_STATE
出力例 (読みやすくするために、出力列のサブセットのみが表示されています):
APPLICATION_HANDLE   TOTAL_RUNTIME_SECONDS TOTAL_WAIT_ON_CLIENT_TIME_SECONDS ACTIVITY_STATE     SORTMEM_USED_PCT STATEMENT_TEXT
-------------------- --------------------- --------------------------------- ---------------  ------------------ --------------
             64                  4364                              4364 IDLE                           32.36 select * from 
             66                  4326                              4326 IDLE                           32.36 select * from
この出力は、 実行中の 2 つの照会があり、それぞれが合計データベース・ソート・メモリーの 32% を消費していることを示しています。 どちらの照会も IDLE 状態にあり、クライアントからの次の要求を待機しています。