PART 05 — チューニング対象SQLの特定
SQL Statistics — ランキング使い分け・実行計画ドリルダウン

SQL Statistics の全体像

AWRの SQL Statistics セクションには、複数の観点でSQLをランキングしたテーブルがあります。 それぞれ異なる問題を炙り出すため、目的に合わせて使い分けます。

テーブル名	ランキング基準	適した問題
SQL ordered by Elapsed Time	合計経過時間	全体的に最も重いSQL（最重要）
SQL ordered by CPU Time	合計CPU消費時間	CPU高負荷の原因SQL
SQL ordered by Gets	論理読み込みブロック数	バッファキャッシュを大量消費するSQL
SQL ordered by Reads	物理読み込みブロック数	I/Oを引き起こすSQL
SQL ordered by Executions	実行回数	頻繁に呼ばれる軽いSQL（積み重ね）
SQL ordered by Parse Calls	パース回数	バインド変数未使用SQL

SQLの基礎は PART 05 — SQL Statistics 重いSQLの特定（AWR入門） を、項目定義は PART 05 — SQL Statistics 詳細（定義書） を参照。

Elapsed Time で重いSQLを特定する

まず SQL ordered by Elapsed Time を見ます。 Elapsed Time(s)（合計実行時間）が上位のSQLが全体の負荷に最も寄与しています。

列名	意味	注目ポイント
Elapsed Time (s)	合計経過時間（秒）	最も総合的な重さを示す
Executions	実行回数	高回数 × 軽い1回 or 低回数 × 重い1回を区別
Elapsed Time / Execute	1回あたりの経過時間	1回が重いSQLを特定できる
% Total DB Time	DB Timeに占める割合	30%超のSQLは最優先でチューニング

CPU / Gets / Reads から原因を分析する

Elapsed Timeが高いSQLが特定できたら、その原因を CPU Time / Gets / Reads の比率で診断します。

状況	原因の仮説	次のアクション
CPU Time ≒ Elapsed Time	CPU使用が多い（ソート・ハッシュ結合・フルスキャン）	実行計画を確認、インデックス追加を検討
Reads が多い（Getsも多い）	物理I/O + バッファキャッシュミス	PART 06 I/O分析 へ
Gets が多い（Readsは少ない）	論理読み込みが多い（効率の悪いインデックスorフルスキャン）	実行計画の見直し
Elapsed ≫ CPU（待機が多い）	I/O待ち or 競合待ち	PART 04 Wait分析 へ

SQL_ID から実行計画へのドリルダウン

AWRレポート（HTML形式）では SQL_ID がリンクになっており、クリックするとSQL全文と実行計画（ある場合）に飛べます。 また、以下のSQLでV$SQL_PLANから実行計画を取得することも可能です。

優先順位付けの考え方