症状ごとにAWRのどこを見ればよいか、毎回同僚に口頭で説明していたのですが、そろそろ一枚のフローチャートにまとめておこうと思い立ちました。全10回の内容を凝縮しています。
読み方ガイドのまとめ
図1: AWR症状別診断フローチャート
本シリーズでは、AWRレポートを実際に受け取ってから診断・対処の方向性を特定するまでの 実践的な手順をカバーしました。 AWRの各セクションが「何を意味するか」を知るだけでなく、 「症状からどう読み進めるか」というフローで解説しています。
| PART | テーマ | カバーする問題 |
|---|---|---|
| PART 01 | 全体読み方フロー | AWRを開いたときの最初の3ステップ |
| PART 02 | ヘルスチェック指標 | 問題の有無を短時間で判断する |
| PART 03 | CPU高負荷 | Time Model / ハードパース / CPU待機 |
| PART 04 | Wait Eventドリルダウン | I/O系・競合系・アプリ系待機の分類と診断 |
| PART 05 | チューニング対象SQL特定 | SQL Statistics / 実行計画へのドリルダウン |
| PART 06 | I/Oボトルネック | Tablespace / Datafile / Segment I/O |
| PART 07 | メモリ問題 | Buffer Cache / PGA / Shared Pool / Advisory |
| PART 08 | Latch・Lock競合 | Latch Activity / Enqueue / Buffer Busy Waits |
| PART 09 | 比較読み | 正常時 vs 問題発生時の差分分析 |
症状別 診断フローチャート
| 症状 | 最初に確認すること | 読むPART |
|---|---|---|
| 全体的にDBが重い | DB Time比率 → Top 5 Events | PART 01 → PART 02 |
| CPU使用率が高い | Time Model Statistics → DB CPU % | PART 03 |
| 特定のWait Eventが上位 | Wait Event名でカテゴリ判定 | PART 04 |
| 特定SQLが遅い | SQL Ordered by Elapsed Time | PART 05 |
| ディスクI/Oが高い | db file sequential/scattered read | PART 06 |
| メモリ不足の疑い | Buffer Cache Hit % / PGA % Optimal | PART 07 |
| 競合・デッドロック | Latch / Enqueue Stats | PART 08 |
| 昨日まで速かった | 正常時AWRと比較 | PART 09 |
記事インデックス
AWR基礎シリーズ（7記事） — AWRとは何か・基本的な見方の入門
- PART 01 - AWRレポートとは
- PART 02 - AWRレポートの全体構成
- PART 03 - DB Time と Elapsed Time
- PART 04 - Top 5 Timed Events
- PART 05 - SQL Statistics
- PART 06 - メモリ・I/O統計の見方
- PART 07 - 分析チェックリストとまとめ
AWRセクション定義書（10記事） — 各セクションの詳細な項目定義
更に詳細なシナリオは PART 10 — 読み方シナリオ集（AWRセクション定義書） も参照してください。
診断を効率化するための実践Tips
AWRを継続的にチューニングツールとして活用するには、単に読む技術だけでなく「どの状況でどのPARTを参照するか」の判断パターンを身につけることが重要だ。
| 状況 | 優先して確認するセクション | 診断の起点 |
|---|---|---|
| 定期レビュー（問題なし） | DB Time / Top 5 Events / Buffer Cache Hit % | ベースラインと比較して異常値がないか確認 |
| バッチ処理が想定より遅い | SQL Statistics（Elapsed Time順）/ I/O統計 | バッチ実行時間帯のAWRスナップショットを絞り込む |
| 夜間バッチ後に翌朝が重い | Buffer Cache Advisory / PGA Advisory | バッチによるバッファフラッシュの影響を確認 |
| 特定ユーザーからのみ遅いと報告 | SQL Statistics（特定SQLの実行計画）/ Segment統計 | そのユーザーが実行するSQLをSQL IDで追跡 |
| 月末・月初に毎回重くなる | Top 5 Events / CPU時間 / I/O統計 | 定期バッチとOLTPが競合していないか確認 |
AWR活用でよくある落とし穴
AWR分析を継続運用に組み込む際に、形骸化しがちなポイントをまとめる。
| 落とし穴 | 何が起きるか | 防止策 |
|---|---|---|
| 障害時だけAWRを見る「後追い運用」 | ベースラインがないため障害時の差分が判断できず、原因特定に時間がかかる | 定常時に週次でAWR差分レポートを確認し、ベースライン傾向を把握しておく |
| スナップショット間隔を変更せずにバッチ調査を試みる | デフォルト1時間間隔ではバッチ実行の前後が1レポートに混在し、バッチだけの特性が見えない | バッチ実行前後に手動スナップショットを取得し、バッチ実行時間帯のみのレポートを作成する |
| AWRレポートだけでSQL最適化を完結させようとする | AWRはSQL IDを特定するツール。実行計画の詳細はAWRでは確認できない | SQL IDが特定できたらDBMS_XPLAN.DISPLAY_AWRで実行計画を確認し、実行計画ベースでチューニングする |
次のステップ
✅ AWRの次は実行計画
AWRでボトルネックSQLが特定できたら、次は実行計画の分析です。Oracle 実行計画 セクション定義書 では、EXPLAIN PLANの各行・アクセスパス・結合方式・述語情報の読み方を詳しく解説しています。