PART 05 — ③ SQL Statistics 詳細

SQL Statistics は、AWR期間中に実行されたSQLを9種類の観点でランキングします。「どのSQLが悪いか」を特定するためのセクションで、原因SQL特定には縦串で複数ランキングを照合するのがコツです。

1. SQL ordered by Elapsed Time— Top SQL（Elapsed Time順）

何を表すか: AWR期間中で「経過時間」の合計が大きい SQL の上位。最も使われ最も重い SQL ランキングの定番。

• 読み方: %Total ≥10% は要注目、≥20% は1SQL集中の警告。Elapsed per Exec が大きく Executions が少ない=重い1発、逆は短時間SQL大量実行型。
• 閾値・注意点: Elapsed には待ち時間も含まれる。CPU と I/O の比率（%CPU + %IO）で性質を判別。両方とも小さいなら「内部待機」型（ロック/ラッチ等）。
• 関連セクション: SQL ordered by CPU Time / SQL ordered by Reads / Complete List of SQL Text
• 使うシーン: 原因SQL特定の第一歩

2. SQL ordered by CPU Time— Top SQL（CPU Time順）

何を表すか: CPU時間の累計が大きい SQL 上位。CPU 飽和型ワークロード時はここが起点。

• 読み方: CPU per Exec が大きければ 1実行で CPU を多く食う SQL（Full Scan / Sort / Hash Join 等）。
• 閾値・注意点: %Total は CPU 時間に対する比率なので、Elapsed Time の%とはずれる。
• 関連セクション: Top SQL by Elapsed / Time Model（DB CPU）
• 使うシーン: CPU飽和時の原因SQL特定

3. SQL ordered by User I/O Wait Time— Top SQL（I/O待ち時間順）

何を表すか: User I/O 待機時間の累計が大きい SQL。物理I/Oで時間を食っている SQL を抽出。

• 読み方: db file sequential read 系の待機が大きいなら、ここの上位が「索引アクセスで遅い」SQL の候補。
• 閾値・注意点: Smart Scan (Exadata) でオフロードされる I/O は含まれない場合がある。
• 関連セクション: Top SQL by Reads / Top SQL by Phys Reads (UnOpt) / Tablespace IO Stats
• 使うシーン: I/O ボトルネックの原因SQL特定

4. SQL ordered by Gets— Top SQL（Buffer Gets順）

何を表すか: 論理I/O（Buffer Gets）の累計が大きい SQL。キャッシュ上の参照量が大きい=処理ブロック数が多い SQL。

• 読み方: Gets per Exec が極端に大きい（数十万以上）と Full Scan や非効率プランの可能性。
• 閾値・注意点: Buffer Hit が良くてもここが高いと、キャッシュは効いているが「無駄に多く読んでいる」状態。プラン見直しが効く。
• 関連セクション: Top SQL by Reads / Buffer Pool Statistics
• 使うシーン: プラン非効率SQLの特定

5. SQL ordered by Reads— Top SQL（Physical Reads順）

何を表すか: 物理読込ブロック数（Physical Reads）の累計が大きい SQL。ストレージI/Oを最も発生させた SQL。

• 読み方: Reads per Exec が大きく、かつ Executions が多いと I/O 系の主犯。Buffer Hit % 低下と相関。
• 閾値・注意点: ASM/ストレージのキャッシュは見えない（DB から見た物理読み量）。
• 関連セクション: Top SQL by User I/O Wait / SQL by Phys Reads (UnOpt)
• 使うシーン: 物理I/O量の偏在を特定

6. SQL ordered by Physical Reads (UnOptimized)— Top SQL（UnOpt Reads順）

何を表すか: Smart Scan/Flash Cache を経由「しなかった」物理読込が多い SQL。Exadata 環境では特に重要。

• 読み方: UnOpt が突出するSQLは Smart Scan 対象外（索引アクセス・特定述語/関数使用等）。索引設計/プラン見直しの候補。
• 閾値・注意点: Exadata 以外では UnOpt Read = Physical Read と同義（Smart Scan が無いため）。
• 関連セクション: Top SQL by Reads / Segments by UnOptimized Reads
• 使うシーン: Exadata最適化漏れSQLの特定

7. SQL ordered by Executions— Top SQL（実行回数順）

何を表すか: 実行回数の累計が大きい SQL。「軽いけど大量に走る」SQL を抽出。

• 読み方: 1回が軽くても 10万回/秒走れば全体負荷大。Elapsed per Exec が極小だがトータル時間が大きい SQL を要注目。
• 閾値・注意点: 実行回数だけでは負荷は分からない。Top SQL by Elapsed Time との交差確認が重要。
• 関連セクション: Top SQL by Elapsed / Top SQL by Parse Calls
• 使うシーン: 短時間SQL大量実行型の特定

8. SQL ordered by Parse Calls— Top SQL（パース回数順）

何を表すか: Parse Calls（パース呼び出し回数）の累計が大きい SQL。ハードパース/ソフトパース合算。

• 読み方: %Total Parses ≥20% は1SQLでパース集中。Library Hit % 閾値割れと相関。プリペアド未使用・カーソル未再利用の典型サイン。
• 閾値・注意点: 実行回数 ≒ パース回数 となる場合は「実行のたびにパース」で、カーソルキャッシュが効いていない。
• 関連セクション: Soft Parse % / Library Hit % / Library Cache Activity
• 使うシーン: パース過多SQLの特定

9. SQL ordered by Sharable Memory— Top SQL（共有メモリ順）

何を表すか: Shared Pool の Library Cache 上で SQL文/プランが占有するメモリサイズ。1SQLで大量メモリを掴むSQL を抽出。

• 読み方: 大きい SQL（動的SQL/巨大IN句/長文SQL）はここに上がる。Shared Pool 圧迫の原因。
• 閾値・注意点: メモリサイズは bytes 表示。MB に換算して評価。
• 関連セクション: Shared Pool Advisory / Shared Pool Statistics
• 使うシーン: Shared Pool 圧迫の調査

10. SQL ordered by Version Count— Top SQL（バージョン数順）

何を表すか: 同じ SQL Text の複数バージョン（異なる子カーソル）を持つ SQL の上位。バインド変数値型違い/オプティマイザヒント違い等で発生。

• 読み方: Version Count ≥10 は調整候補、≥100 は明らかなプラン爆発。Library Cache に過剰なバージョンが蓄積される。
• 閾値・注意点: 原因（V$SQL_SHARED_CURSOR）はAWRからは特定できない。SQL_ID で別途確認が必要。
• 関連セクション: Shared Pool Advisory / Soft Parse %
• 使うシーン: プラン爆発の検出

11. Complete List of SQL Text— 全SQLテキスト

何を表すか: 本レポートで参照される全 SQL_ID と SQL本文の対応表。SQL_ID から実際のSQLを確認するための辞書。

• 読み方: ランキングで気になった SQL_ID をここで本文確認。改行が消えるので長文SQLは別途 V$SQLTEXT 等で取り直し推奨。
• 閾値・注意点: テキストは省略（40,000文字までなど）されることあり。完全な SQL は v$sqltext_with_newlines で取得。
• 関連セクション: 各 Top SQL セクション全般
• 使うシーン: SQL_ID → 本文確認