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

「重いSQL」と一口に言っても、Elapsed Timeが長いのかGetsが多いのか、原因はSQLごとに違います。ランキングの使い分けを誤って的外れなチューニングをしてしまった反省から書いています。

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チューニングよくある失敗パターン

SQL Statisticsで対象SQLを特定した後、チューニングで陥りやすい誤りと正しいアプローチを整理する。

失敗パターン	なぜ問題か	正しいアプローチ
Elapsed Timeだけ見てインデックスを追加する	Gets（論理読み込み）が多い場合はインデックスが役立つが、Readsが多い場合はストレージ性能の問題かもしれない	CPU/Gets/Readsの比率で原因を切り分けてから対処を決める
実行計画を見ずにSQLを書き直す	書き直し後に別の非効率が生まれる。フルスキャンが意図的な場合もある	DBMS_XPLANで現在の実行計画を確認し、どのオペレーションがコストを占めるかを把握してから修正
統計情報の更新を忘れる	Optimizerが古い統計を使うと全件スキャンを選択することがある。インデックス追加だけでは解消しない	DBMS_STATSで対象テーブルの統計情報を更新し、実行計画が変わることを確認
Parse Callsが多いのを見逃す	Executions ≒ Parse Callsならバインド変数未使用。共有プール競合が常態化している	アプリ側でバインド変数を使うよう修正。CURSOR_SHARINGは応急処置

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

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

優先順位付けの考え方