SQL Statistics の概要と AWR との差異
STATSPACK の SQL Statistics は AWR と同様に8種類のランキングを提供しますが、AWR との主な違いが2点あります。
- SQL識別子が Old Hash Value（数値）。AWRの SQL ID（英数字）とは異なる。Old Hash Value から V$SQL で実際のSQL文を検索可能。
- Unoptimized Read Requests（非最適読み）ランキングがない。AWRには「SQL ordered by Unoptimized Read Requests」があるが STATSPACK にはない。
1. SQL ordered by CPU— CPU時間順
何を表すか: スナップ期間中に最もCPUを消費したSQL。CPU負荷の主因を特定する。
- 読み方: CPU Time(s) / Total DB CPU の %Total で相対的な重さを判断。CPU per Exec で1回あたりのCPUコストも確認。
- 閾値・注意点: Executions = 0 の SQL は並列実行（子カーソル分散）や STATSPACK 収集漏れを意味する。Module 列でアプリ種別（JDBC / SQL*Plus等）を確認。
- 関連セクション: SQL ordered by Elapsed / Time Model System Stats
- 使うシーン: CPU飽和時の原因SQL特定
項目の意味と着目点 — SQL ordered by CPU
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| CPU Time (s) | スナップ期間中の累積CPU時間（秒） | 総CPU消費量の規模感。Top 5 Timed Events の DB CPU と照合 |
| Executions | 実行回数（スナップ期間中の差分） | 0 は並列実行の子カーソル分散または収集対象外を示す |
| %Total | Total DB CPU に占める割合 | 相対的な重み。1位が突出していればそのSQLが主因 |
| Elapsed Time (s) | CPU+待機の合計経過時間 | CPU Time との差が大きいほど待機比率が高い |
| CPU per Exec (s) | 1実行あたりのCPU消費時間 | 高頻度×高CPUコストの組み合わせに注意 |
| Elapsed per Exec (s) | 1実行あたりの応答時間 | エンドユーザが体感するレスポンスタイムの近似 |
| Old Hash Value | SQL文のハッシュ識別子（数値） | V$SQL の HASH_VALUE 列で実際のSQL文を確認 |
| Module | SQL発行元のモジュール名 | JDBC / SQL*Plus / DBMS_STATS 等でアプリ種別を判断 |
2. SQL ordered by Elapsed Time— 経過時間順
何を表すか: スナップ期間中の累積経過時間（CPU+待機）が最大のSQL。レスポンスタイム問題の主因を特定する。
- 読み方: Elapsed Time(s) / Total DB Time の %Total。Elap per Exec で1回あたりの応答時間を確認。CPU Time との差が大きいほど待機比率が高い（I/O or 競合待ち）。
- 閾値・注意点: Physical Reads が多いSQLは I/O 性能に強く依存。Executions=0 は並列クエリの分散で正確な1実行あたりコストが出ない。
- 関連セクション: SQL ordered by Reads / Foreground Wait Events
- 使うシーン: 応答時間問題の原因SQL特定
項目の意味と着目点 — SQL ordered by Elapsed Time
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Elapsed Time (s) | CPU時間＋待機時間の合計（秒） | レスポンスタイム問題の主因を示す最重要指標 |
| Executions | 実行回数 | 0 は並列実行。Elap per Exec が算出不可 |
| Elap per Exec (s) | 1実行あたりの経過時間 | 高い場合はフルスキャン・大量 I/O・競合の可能性 |
| %Total | Total DB Time に占める割合 | このSQLが全体 DB Time を何%占めているか |
| CPU Time (s) | CPU処理に費やした時間 | Elapsed との差＝待機時間。差が大きければ I/O or 競合 |
| Physical Reads | ディスクから読み込んだブロック数 | 大きい場合はキャッシュ不足またはフルスキャン |
| Old Hash Value | SQL識別子（数値） | 複数ランキングで同一 Hash が出現すればチューニング優先度が高い |
3. SQL ordered by Gets— 論理読込（バッファGets）順
何を表すか: バッファキャッシュへのアクセス（論理読込）が最も多いSQL。Buffer Cache を圧迫するSQLを特定する。
- 読み方: Buffer Gets / Total Buffer Gets の %Total。Gets per Exec で1実行あたりのキャッシュアクセスコストを確認。Gets が多くても Physical Reads が少ないなら Cache 効率は高い。
- 閾値・注意点: Gets per Exec が10,000超はフルスキャンや非効率アクセスの可能性。CPU Time と合わせて読む。
- 関連セクション: Instance Efficiency (Buffer Hit%) / Buffer Pool Statistics
- 使うシーン: Buffer Cache 圧迫源の特定
項目の意味と着目点 — SQL ordered by Gets
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Buffer Gets | 論理読込ブロック数（バッファキャッシュアクセス） | Buffer Cache 圧迫の主因。Load Profile の Logical reads/Txn と照合 |
| Executions | 実行回数 | Gets per Exec の算出に使用 |
| Gets per Exec | 1実行あたりの論理読込数 | 10,000 超はフルスキャンや非効率インデックスの可能性 |
| %Total | Total Buffer Gets に占める割合 | このSQLがキャッシュアクセスの何%を占めるか |
| CPU Time (s) | CPU処理時間 | Gets が多く CPU も高い場合は CPU バウンドのフルスキャン |
| Physical Reads | 実際のディスク読込数 | Gets に対して少なければキャッシュ効率が高い |
| Old Hash Value | SQL識別子 | Reads・Elapsed ランキングにも登場していれば優先度高 |
4. SQL ordered by Reads— 物理読込順
何を表すか: 物理ディスク読込が最も多いSQL。I/O 性能問題の主因となるSQLを特定する。
- 読み方: Physical Reads / Total Disk Reads の %Total。Rds per Exec で1実行あたりのディスク読込量を確認。
- 閾値・注意点: 同じSQLが Elapsed / Gets / Reads の複数ランキングに登場する場合はチューニング優先度が高い。
- 関連セクション: Tablespace IO Stats / Segments by Physical Reads
- 使うシーン: I/O 問題の原因SQL特定
項目の意味と着目点 — SQL ordered by Reads
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Physical Reads | ディスクから読み込んだブロック数 | I/O 負荷の主因。Tablespace IO Stats の Reads 合計と照合 |
| Executions | 実行回数 | Rds per Exec の算出に使用 |
| Reads per Exec | 1実行あたりの物理読込数 | 高い場合はキャッシュに乗らないフルスキャンまたは大量結果セット |
| %Total | Total Disk Reads に占める割合 | このSQLが I/O 負荷の何%を占めるか |
| CPU Time (s) | CPU処理時間 | Physical Reads が多く CPU が低い場合は I/O バウンド |
| Elapsed Time (s) | 合計経過時間 | Reads ランキング上位かつ Elapsed も大きければ I/O が支配的 |
| Old Hash Value | SQL識別子 | Gets・Elapsed ランキングとのクロスチェックに使用 |
5. SQL ordered by Executions— 実行回数順
何を表すか: 最も多く実行されたSQL。高頻度 OLTP SQL のコスト最適化に使う。
- 読み方: Rows per Exec で1実行あたりの処理行数を確認。CPU per Exec / Elap per Exec が小さくても実行回数が多ければトータルコストは大きい。
- 閾値・注意点: STATSPACK は End Executions Threshold（デフォルト100）未満のSQLはキャプチャされない。
- 関連セクション: SQL ordered by CPU / Parse Calls
- 使うシーン: 高頻度SQLのチューニング優先度付け
項目の意味と着目点 — SQL ordered by Executions
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Executions | スナップ期間中の実行回数 | 高頻度ほど1回あたりのコスト改善効果が大きい |
| Rows per Exec | 1実行あたりの処理行数 | 0〜1 は単一行処理。大きい場合はバルク操作 |
| CPU per Exec (s) | 1実行あたりのCPU時間 | 小さくても Executions が多ければ合計CPUコストは大 |
| Elap per Exec (s) | 1実行あたりの経過時間 | 0.001秒でも10万回実行なら合計100秒 |
| Physical Reads | 期間中の累積物理読込 | 高頻度×高Physical Readsの組み合わせは I/O 負荷の主因 |
| Old Hash Value | SQL識別子 | Parse Calls ランキングと照合してカーソル再利用率を確認 |
6. SQL ordered by Parse Calls— パース呼び出し順
何を表すか: パース（構文解析）が最も多く発生したSQL。カーソル再利用効率を判定する。
- 読み方: % Total Parses で全パースに占める割合を確認。Parse Calls ≈ Executions なら毎回パースされている（カーソル再利用なし）。
- 閾値・注意点: Execute to Parse % が低い原因がここで特定できる。Parse Calls = Executions の場合はコネクションプールやカーソルキャッシュの設定を確認する。
- 関連セクション: Instance Efficiency (Soft Parse % / Execute to Parse %) / Library Cache Activity
- 使うシーン: パース問題の根本原因SQL特定
項目の意味と着目点 — SQL ordered by Parse Calls
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Parse Calls | パース呼び出し回数 | Executions と同数ならカーソルキャッシュが機能していない |
| Executions | 実行回数 | Parse Calls / Executions ≒ 1.0 が問題パターン |
| % Total Parses | 全パース呼び出しに占める割合 | 上位SQLのパース負荷の集中度を把握 |
| CPU Time (s) | CPU処理時間 | パース起因のCPU消費を Elapsed と比較 |
| Elapsed Time (s) | 経過時間 | パース処理そのものによる遅延が含まれる |
| Old Hash Value | SQL識別子 | session_cached_cursors や カーソルキャッシュ設定の見直しに |
7. SQL ordered by Sharable Memory— 共有メモリ使用量順
何を表すか: Shared Pool のライブラリキャッシュで最もメモリを消費しているSQL（カーソル）。
- 読み方: Max Sharable Memory と End Sharable Memory の差が大きいものは実行計画が多数キャッシュされている可能性。% Total で占有割合を確認。
- 閾値・注意点: 大きな SQL（複数JOIN・サブクエリ）は自然にメモリを消費する。Version Count が多いと計画が増殖してメモリを食いやすい。
- 関連セクション: SQL ordered by Version Count / Shared Pool Advisory
- 使うシーン: Shared Pool 逼迫の原因SQL特定
項目の意味と着目点 — SQL ordered by Sharable Memory
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Sharable Memory (bytes) | ライブラリキャッシュ上のカーソルメモリ消費量 | Shared Pool 逼迫時の主因SQL特定に使う |
| Max Sharable Mem | スナップ期間中の最大消費量 | End との差が大きければ期間中に増殖 |
| End Sharable Mem | スナップ終了時点の消費量 | 現在のカーソルメモリ占有量 |
| % Total | 全 Shared Pool 消費に占める割合 | このSQLの相対的な重さ |
| Parse Calls | パース呼び出し回数 | 頻繁にパースされているほどメモリ確保が繰り返される |
| Executions | 実行回数 | 低頻度で大メモリ消費は非効率な大きなSQLの特徴 |
| Module | SQL発行元モジュール名 | 内部処理（MMON 等）か業務SQLかを区別 |
8. SQL ordered by Version Count— バージョン数順
何を表すか: 同一SQL文に対して複数の実行計画（子カーソル）が生成された数。バインド変数のデータ型不一致やオプティマイザ設定の差異で増殖する。
- 読み方: Max Version Count が大きいほど計画増殖の問題あり。Delta Version Count でスナップ期間中の増加分を確認。
- 閾値・注意点: 通常 Version Count は 1〜5 で安定するべき。20超は要調査。増殖したカーソルは cursor_sharing / バインドピーク / 適応共有カーソルが影響することが多い。
- 関連セクション: Shared Pool Advisory / Library Cache Activity
- 使うシーン: カーソル増殖問題の調査
項目の意味と着目点 — SQL ordered by Version Count
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Max Version Count | スナップ期間中の最大子カーソル数 | 20 超は cursor_sharing / バインドピーク / オプティマイザ設定を確認 |
| End Version Count | スナップ終了時点の子カーソル数 | 現在のカーソル増殖状況 |
| Delta Version Count | スナップ期間中に増加した子カーソル数 | 増加中かどうかを判断。大きければ現在進行系の増殖 |
| Executions | 実行回数 | 高頻度かつバージョン多数は Shared Pool・CPU 双方に影響 |
| Parse Calls | パース呼び出し回数 | 多数の子カーソルが存在するほどパース時の候補探索コストが増加 |
| Old Hash Value | SQL識別子 | V$SQL で子カーソルの child_number と is_shareable を確認 |
クロスリファレンス読み
複数ランキングに登場するSQLはチューニング優先度が高い。同一 Old Hash Value が CPU・Elapsed・Gets・Reads など複数のランキングに出現した場合、そのSQLはシステム全体のボトルネックである可能性が高い。
クロスリファレンス — 読み方ガイド
| 出現パターン | 意味 | 推奨アクション |
|---|---|---|
| Elapsed + Reads + Gets 上位 | I/O バウンドの非効率SQL。多量ディスク読込がレスポンスタイムを悪化させている | 実行計画確認・インデックス設計・アクセスパス最適化 |
| CPU + Gets 上位（Reads 低） | CPU バウンド。キャッシュには乗っているが論理読込コストが高い | インデックス効率化・バッファキャッシュ最適化 |
| Executions + Parse 上位 | 高頻度かつカーソルキャッシュ未使用。毎回パースが発生している | session_cached_cursors 増加・コネクションプール設定確認 |
| Version Count 上位 + Shared Memory 上位 | カーソル増殖による Shared Pool 消費圧迫 | cursor_sharing・バインド変数データ型・適応共有カーソルの設定確認 |
| CPU 上位のみ（他ランキング低位） | 特定SQLが CPU を集中消費しているが I/O は少ない。計算処理または統計処理系の可能性 | 並列度・スケジュール調整。業務SQLか内部処理かを Module 列で確認 |