Db2 SQL活動要約

Db2 SQL活動要約レポートは、測定対象のアプリケーションによって実行されたすべてのSQLの活動をまとめたものです。レポートに示されるデータは、Db2アカウンティングトレースから取得されます。Db2トレースデータは、IDごとに累積されます。 IDデータ項目は、アプリケーションのタイプによって異なります。

バッチの場合、相関IDごとに要約されます。
CICSの場合、トランザクションIDごとに要約されます。
RRSAFの場合、許可IDごとに要約されます。
DDFの場合、エンドユーザーのUSERID、エンドユーザーのトランザクション、およびエンドユーザーのワークステーションごとに要約されます。

複数のIDが存在する場合、この活動要約レポートには、IDごとにエントリーが示され、各IDエントリーの累積値を示す合計エントリーが示されます。複数のエントリーは折りたたまれて表示されるため、展開する必要があります。

WLMクラス名

[WLMクラス名]は、ワークロードが実行されたWLMクラスの名前です（割り当てられている場合）。これは、WLMクラス名が使用できる場合のみ表示されます。

エンドユーザーの識別

以下の1つまたは複数の項目から、エンドユーザー固有の識別情報を確立できます。

[リクエスターロケーション]
[認証ID]
[相関ID]
[エンドユーザーID]
[エンドユーザーのワークステーション]
[エンドユーザーのトランザクション]

資源の使用

CPU使用を監視して、アプリケーションのSQLステートメント変更による改善や、プロセッサータイプの移行について記録することができます。

[SQL中央プロセッサーでのCPU使用（秒）]は、中央プロセッサーで消費されたCP CPU時間を示します。
[In-Db2]は、Db2で消費された累積CP CPU時間を示します。このCPU時間には以下の時間は含まれません。
- IBMの専用エンジンで消費されたCP CPU時間
- ストアードプロシージャー、トリガー、またはユーザー定義関数（UDF）内のSQLステートメントの処理に消費されたCPU時間
[ストアードプロシージャー]は、ストアードプロシージャー内のSQLステートメントの処理に消費された、Db2内の累積CP CPU時間を示します。
この時間には、IBM専用エンジンで消費されたCPU時間は含まれません。
[トリガー]は、ネストされたタスクでトリガーのSQLステートメントの実行に消費されたCP CPU時間を示します。
この時間には、IBM専用エンジンで消費されたCPU時間は含まれません。
[UDF]は、ユーザー定義関数（UDF）の実行に消費されたCP CPU時間を示します（バージョン10の場合のみ）。
[合計]は、すべての環境で使用されたCP CPU時間を示します。
このCPU時間には、IBM専用エンジンで消費されたCPU時間は含まれません。
[SQL専用プロセッサーでのCPU使用（秒）]は、専用プロセッサー（zIIP）で消費されたCPU時間を示します。
[In-Db2]は、Db2で消費されたSP CPU時間を示します。
このSP CPU時間には、ストアードプロシージャー、トリガー、またはユーザー定義関数（UDF）内のSQLステートメントの処理に消費されたSP CPU時間は含まれません。
[ストアードプロシージャー]は、ストアードプロシージャー内のSQLステートメントの処理に消費された、Db2内の累積SP CPU時間を示します。
[トリガー]は、ネストされたタスクでトリガーのSQLステートメントの実行に消費されたSP CPU時間を示します。
[UDF]は、IBM専用エンジンでユーザー定義関数（UDF）の実行に消費されたSP CPU時間を示します（バージョン10の場合のみ）。
[合計]は、すべての環境において、IBM専用エンジンでの実行に消費されたクラス1 SP CPU時間を示します。
[SQL経過時間（秒）]を監視して、アプリケーションのSQLステートメント変更による改善を記録することができます。
[In-Db2]は、Db2に接続された他のアドレススペースから発生した関連エージェント作業要求に関して、ネストされていない活動のDb2内累積経過時間を示します。
[ストアードプロシージャー]は、関連エージェントがストアードプロシージャーのSQLステートメントの実行に費やした経過時間を示します。
[トリガー]は、トリガーのSQLステートメントの実行に消費された経過時間を示します。
[UDF]は、関連エージェントがUDFのSQLステートメントの実行に費やした経過時間を示します（V10の場合のみ）。
[SQLアクセラレーター使用（秒）]は、アクセラレーターで実行されたすべてのアプリケーションのDb2ワークロードについて、アクセラレーターのCPU時間と経過時間を示します。
[経過時間]は、アクセラレーターサービスの経過時間を示します。
[CPU時間]は、アクセラレーターサービスのCPU使用を示します。
[TCP/IP経過]は、アクセラレーターサービスのTCP/IPの経過時間を示します。
[TCP/IP CPU時間]は、アクセラレーターサービスのTCP/IPのCPU使用を示します。

バッファープール統計

[BP名]はバッファープールの名前です。

バッファープールの命名規則は以下のとおりです。
4 KBページのバッファー名は、BP0～BP49の間です。
8 KBページのバッファー名は、BP8K0～BP8K9の間です。
16 KBページのバッファー名は、BP16K0～BP16K9の間です。
32 KBページのバッファー名は、BP32K～BP32K9の間です。

[バッファープールID]は、バッファープールIDを示します。
[サイズ]は、バッファープール内のページ数を示します。
[ヒット率]は、I/O操作を必要とせずにページアクセス(getpage)が行われた頻度です。
[しきい値]
[VP Seq.]は、順次アクセスのページで占められた可能性のあるバッファープールのパーセンテージを示します。
[並列Seq.]は、並列処理をサポートするために使用された可能性のあるバッファープールの割合を示します。VP Seq.のパーセンテージとして表されます。
[遅延書き込み]は、（更新されたページと使用中のページの両方を含む）使用不可なページで占められた可能性のあるバッファープールのパーセンテージを示します。
[垂直遅延書き込み]は、遅延書き込みのしきい値と似ていますが、バッファープール内のシングルページに対する更新されたページ数に適用されます。
[非同期読み取り]は、エージェントによってトリガーされたプリフェッチのために、ハイパープールから仮想バッファープールに移動されたページの数を示します。
[動的プリフェッチ]は、（動的）PREFETCH要求の数を示します。動的プリフェッチは順次検出によってトリガーされるもので、セグメント化された表スペースのプリフェッチが含まれます。動的プリフェッチは、通常、SELECTまたはUPDATEが繰り返し実行され、アクセスのたびに索引がアクセスされる場合に使用されます。順次プリフェッチ、リストプリフェッチ、動的プリフェッチの値が大きい場合、アクセスパスを改善できないか調べてください。
[即時書き込み]は、即時（同期）書き込み入出力操作の回数を示します。即時書き込みはまれですが、小さな値であれば許容できます。大きな値の場合は、システムのチューニングが必要です。
[GET PAGE]は、GETPAGE要求の数を示します。このカウンターは、各スレッドで並列処理された照会で成功したGETPAGE要求、および並列処理されなかった照会で成功または失敗したすべてのGETPAGE要求のたびに増分されます。GETPAGE要求の数を減らすことで同期ページ読み取りの回数を削減して、Db2のパフォーマンスを改善することができます。GETPAGE要求の数が少ない場合、要求されるページは、ほとんどバッファープールから返されます。CPUの使用も減ります。SQL DMLステートメントに対するGETPAGE要求の割合をチェックし、この割合が6未満になるようにしてください。
[GETPAGE失敗]は、並列処理の照会のために要求されたページが、入出力の処理中だったため、またはバッファープールにページが見つからなかったために、使用不可だった回数を示します。エージェントは待機しませんが、制御がエージェントに戻されます。このカウンターは、照会が並列処理される場合のみ使用されます。この値が0に近い場合は、ほとんどのページがすでにバッファープールにあり、同期入出力のための待ち時間が短いことを示します。クラスター索引スキャンがあるが、実際にはデータが索引キーでクラスター化されていない場合などに、このカウンターの値が高くなることがあります。このような場合、データページは実際の順番でアクセスされず、クラスター率は無効になります。RUNSTATSユーティリティーを使って更新してください。このフィールドの値は、1つのページの順次プリフェッチがスケジュールされた回数を判断するためにも使用できます。
[リストプリフェッチ]は、リストプリフェッチ要求の数を示します。リストプリフェッチにより、必要なデータページが連続していない場合でも、Db2はデータページに効率的にアクセスできます。リストプリフェッチは、単一索引アクセス時に使用でき、複数索引アクセス時には常に使用されます。ハイブリッド結合で内部表からデータにアクセスする場合は、常にリストプリフェッチが使用されます。データページは順次プリフェッチの場合と同じ数ごとに読み取られます。この数はバッファープールサイズに依存しますが、通常は32ページです。バインド時、処理されるRIDの見積もり数がRIDプールの50%以上を占める場合、Db2はリストプリフェッチを使用しません。実行時、表内の25%以上の行にアクセスする必要があることをDb2が検出すると、リストプリフェッチ処理が終了します。リストプリフェッチが終了した場合、IFCID 125にそれが示されます。
[ページ更新]は、バッファーが更新された回数を示します。この数は、ページが更新され、DASDに書き込める状態になるたびに増分されます。たとえば同じページが2回更新された場合は、数が2増えます。この数は、データページおよび作業ファイルページを含め、すべてのページに対して保持されます。0以外の値は、以下のいずれかの活動を示します。
SQL INSERT、UPDATE、またはDELETE
マージスキャン結合
作業ファイルに対する内部ソート活動。アクセスパスを確認して、ソート活動を最小限にするか回避できないか調べてください。
[順次プリフェッチ]は、SEQUENTIAL PREFETCH要求の数を示します。この数は、PREFETCH要求ごとに増分されます。各要求の結果、入出力読み取りが発生する可能性があります。その場合、SQLの場合は32ページ、ユーティリティーの場合は64ページまで読み取りが可能です。SQLの場合、バッファープールのサイズによっては、要求されたページがすでにバッファープールにある場合、入出力が発生しないことがあります。バインド時に順次プリフェッチが要求されていない場合でも、データが順にアクセスされる場合、Db2は順次プリフェッチを使用することがあります。これは順次検出と呼ばれ、順次プリフェッチカウントには含まれません。順次検出は[動的プリフェッチ]要求フィールドに含まれます。

表スペーススキャンおよび非突き合わせ索引スキャンでは、通常、順次プリフェッチが使用されます。
[同期読み取り]は、同期読み取り入出力操作の回数を示します。Db2は、メディアマネージャーの同期物理読み取りのたびに、このカウンターを増分します。非同期入出力要求はカウントされません。

RDS SQL活動統計 - その他／例外

[DRA（直接行アクセス）試行OK]は、直接行アクセスが成功した回数を示します。
[INDEXに戻されたDRA試行]は、レコードの検索に索引が使用された回数を示します。
[表スペース走査に戻されたDRA試行]は、Db2が突き合わせ索引スキャンを使用できなかったために、直接行アクセスが表スペーススキャンに変更された回数を示します。

理想としては、この値は0であるべきです。表スペーススキャンは、ROWID列を読み取ったあと、SQLステートメントのWHERE文節内のホスト変数を使用するまでの間に、REORGが実行された場合などに発生することがあります。このような場合、ホスト変数のRID値が正しくなくなります。Db2は、表スペーススキャンを使用する前に、まず突き合わせ索引スキャンを試みます。表スペーススキャンを回避するために、成功しなかった直接行アクセスのアクセスパスで基本索引キーの突き合わせ索引スキャンを使用するよう強制することができます。このためには、WHERE ROWIDCOL=:HVROWID AND PKCOL=:HVPKのように、SQLステートメントのWHERE文節にPKCOLを追加します。
[暗黙的な準備（KEEPD=Y、キャッシュに存在しない）]は、アプリケーションのプランまたはパッケージがKEEPDYNAMIC YESでバインドされている場合に、準備済みSQLステートメントのユーザーコピーがローカル動的SQLキャッシュにもう存在しないときに発生する、暗黙のPREPAREの数を示します。準備済みSQLステートメントのスケルトンコピーがEDMプールのグローバル動的SQLキャッシュに存在する場合、短いPREPAREが実行されます。そうでない場合は、完全なPREPAREが実行されます。
[PG実行の最大範囲]は、実行されたすべての並列グループの中で最大の照会並列処理の度合いを示します。これにより、照会がどの程度並列処理されたかが示されます。
[準備なし（KEEPD=Y、キャッシュに存在）]は、アプリケーションによってSQL PREPAREまたはEXECUTE IMMEDIATEが発行されず、準備済みSQLステートメントのコピーがローカル動的SQLキャッシュに見つかった回数を示します。アプリケーションのプランまたはパッケージがKEEPDYNAMIC YESでバインドされた場合、アプリケーションスレッドの各準備済みSQLステートメントのコピーがローカル動的SQLキャッシュに入れられ、コミット境界間で保持されます。
[実行された並列グループ]は、実行された並列グループの合計数を示します。
[計画の度合いどおりに実行された並列グループ]は、計画された並列処理の度合いで実行された並列グループの合計数を示します。このフィールドは、計画された並列処理の度合いで実行された並列グループ（Db2によって判別される）ごとに1つずつ増分されます。
[度合いに満たなかった並列グループ（バッファー不足／競合）]は、記憶域の不足やバッファープールの競合のために、計画された並列処理の度合いに達しなかった並列グループの合計数を示します。

このフィールドが0以外の場合、ALTER BUFFERPOOLステートメントを使って現在のバッファープールのサイズを増やすか、ALTER TABLESPACEステートメントを使って、この照会によってアクセスされた表スペースを別のバッファープールに割り当ててください。
[SEQに戻された並列グループ（EASソート不足）]は、EASのソートサポートがなかったために順次モードになった並列グループの合計数を示します。
[SEQに戻された並列グループ（バッファー不足／競合）]は、記憶域の不足やバッファープールの競合のために順次モードになった並列グループの合計数を示します。
[SEQに戻された並列グループ（DELやUPDのカーソルあり）]は、UPDATEまたはDELETEによってカーソルが使用可能なために順次モードになった並列グループの合計数を示します。
[共用GP間データ向けの並列グループ]は、Db2がデータ共用グループ間での実行を意図した並列グループの合計数を示します。この数は、実行時に並列処理コーディネーターでのみ増分されます。
[メンバーのバイパスが行われた並列グループ（バッファー不足）]は、1つまたは複数のDb2メンバーのバッファープール記憶域が不十分だったために、並列処理コーディネーターがタスクの分散時にDb2をバイパスしなければならなかった回数を示します。このフィールドの数は、複数のDb2で並列グループに対するバッファープール記憶域が不足していた場合でも、1つの並列グループにつき1回だけ並列処理コーディネーターで増分されます。また、並列処理を許可するようにバッファープールが定義されている場合のみ、増分されます。たとえば、あるアシスタントでVPXPSEQT=0の場合、Db2はそこには並列作業を送信しないため、このフィールドの数は増分されません。
[単一上の並列グループ（調整サブシステム = NO）]は、COORDINATORサブシステム値がNOに設定されているために、単一のDb2サブシステムで実行された並列グループの合計数を示します。ステートメントのバインド時、COORDINATORサブシステム値はYESに設定されていました。このような状況は、パッケージまたはプランがCOORDINATOR=YESのDb2サブシステムでバインドされ、COORDINATOR=NOのDb2サブシステムで実行される場合にも発生します。
[単一上の並列グループ（分離レベルのため）]は、Repeatable ReadまたはRead Stability分離レベルのために、単一のDb2サブシステムで実行された並列グループの合計数を示します。
[再構成された並列グループ（BPOOL不足）]は、バッファープールの資源が不十分だったために、Db2がアクセスパスの並列部分を再構成した並列グループの合計数を示します。このカウンターは、実行時に並列処理コーディネーターでのみ増分されます。
[再構成された並列グループ（構成変更）]は、バインド時から実行時で、活動メンバーの数が変わったか、実行されているプロセッサーのモデルが変わったために、Db2がアクセスパスの並列部分を再構成した並列グループの合計数を示します。このカウンターは、実行時に並列処理コーディネーターでのみ増分されます。
[破棄された準備STMT（MAXKEEPD到達）]は、MAXKEEPDの制限に達したために、ローカル動的SQLキャッシュでステートメントが無効になり、ローカル動的SQLキャッシュ内の準備済みSQLステートメントを再要求しなければならなかった回数を示します。
[除去された準備STMT（DROP/ALTER/REVOKE）]は、SQL DDLまたは更新されたRUNSTATS情報のために、ローカル動的SQLキャッシュでステートメントが無効になり、ローカル動的SQLキャッシュ内の準備済みSQLステートメントを再要求しなければならなかった回数を示します。
[キャッシュから準備未検出]は、Db2が準備済みステートメントのキャッシュを検索したが、適切な準備済みステートメントを見つけられなかった回数を示します。
[キャッシュから準備検出]は、準備済みステートメントのキャッシュからステートメントをコピーして、PREPAREコマンドを処理できた回数を示します。
[RIDリスト処理未使用（上限を超えた）]は、1つの索引（リストプリフェッチを使った単一索引アクセス）または複数の索引（複数索引アクセス）を伴う、特定のRIDリスト（またはRIDプール）の処理中に、RIDリストが1つまたは複数の内部制限を超過したことをDb2が検出した回数を示します。内部制限には、1つのRIDリストに入れられるRID数の物理的制限や、RIDの取得、論理和、論理積のしきい値などがあります。リストプリフェッチを使った索引アクセス（単一索引）の場合、このフィールドはRIDリストの取得でのみ増分されます。複数索引アクセスの場合、このフィールドはRIDリストの取得、論理積、論理和の処理で増分されます。このカウンターは、索引から直接取得されたRIDリスト、論理積および論理和の処理で取得されたRIDリストの両方について、内部制限またはしきい値を超過した回数を示します。
RIDリストの記憶域サイズを増やす前に、統計レコードまたはパフォーマンストレースを使って障害の原因を調べてください。RIDリストのサイズは（16 KB～1000 MBの範囲で）、Db2のインストールパネルDSNTIPCで指定できます。
[RIDリスト処理未使用（記憶域不足）]は、1つの索引（リストプリフェッチを使った単一索引アクセス）または複数の索引（複数索引アクセス）を伴う特定のRIDリストの処理中に、RIDのリストを保持するための記憶域がないことをDb2が検出した回数を示します。このフィールドは、リストプリフェッチを使った索引アクセス（単一索引）の場合、RIDリストの取得、ソート、論理積、論理和の処理中に増分されます。単一索引アクセスの場合、このフィールドはアクセスごとに1回だけ増分されます。複数索引アクセスの場合、RIDリストの論理積、論理和の処理に関与する索引ごとに増分されます。
[RIDリスト処理使用]は、RIDリスト（RIDプールとも呼ばれます）の処理が使用された回数を示します。RID（RECORD ID）リストの処理中、Db2は索引を使って、候補RIDのリスト（RIDリスト）を生成します。RIDリストは、実際にデータページにアクセスする前にソートしたり、他のRIDリストと論理積／論理和処理を行うことができます。RIDリスト処理は、単一索引（リストプリフェッチを使った索引アクセス）または複数索引（複数索引アクセス）に使用できます。後者の場合は、RIDリストの論理積、論理和の処理が行われます。RIDリスト処理がリストプリフェッチを使った索引アクセス、複数索引アクセス、またはその両方に使用された場合、このフィールドは所定の表へのアクセスごとに増分されます。複数索引アクセスの場合で、最終的なRIDリストがリストの論理和、論理積により取得された場合、RIDによってすべての索引が使用されていない場合でも、カウンターは1回ずつ増分されます。

このフィールドの値が0以外の場合、Db2がリストプリフェッチを使用したことを示します。この場合は、アクセスパスのセクションを確認してください。
[削除された行数]は、削除されたデータベース行の数を示します。
[フェッチされた行数]は、フェッチされたデータベース行の数を示します。
[挿入された行数]は、挿入されたデータベース行の数を示します。
[更新された行数]は、更新されたデータベース行の数を示します。
[再最適化された回数]は、ホスト変数の値またはパラメーターマーカーが変わったために、再最適化が発生した合計回数を示します。

RDS SQL活動統計 - ステートメントカウント

[ステートメント（カウント）]は、SQLステートメントが実行された回数を示します。カウントはステートメントタイプごとに示されます。アプリケーションスレッドで実行されたすべてのパッケージの、各タイプのすべての実行回数が含まれます。