AWRを開いてまず何を見るべきか、新人時代の自分に教えたい内容です。スナップショット期間の確認を飛ばしていきなり細部に飛び込み、時間を無駄にしたことが何度もありました。
本ガイドの位置づけ
図1: AWRレポート読み方フロー（DB Time確認→Top 5 Events→SQL統計→Memory Advisory→Instance IO）
AWRレポートを実際に受け取ったとき、「どこから読めばよいかわからない」という状況はよく起こります。 本シリーズは、AWRの実践的な読み方・診断手順に特化したガイドです。 各セクションの定義については AWRセクション定義書 を、 AWR全体の基礎知識は AWR入門シリーズ を参照してください。
💡 ガイドの使い方
本記事（PART 01）は最初に読む全体フローです。問題の種類が特定できたら、該当するPARTに直接ジャンプしてください。
STEP 1 — スナップショット期間・環境を確認する
AWRを開いたら、まずレポートヘッダー（Report Summary）でスナップショット情報を確認します。 ここを確認せずに数値だけ見ると、比較対象の期間が異なっていて誤った判断をするリスクがあります。
| 確認項目 | どこを見るか | チェックポイント |
|---|---|---|
| スナップショット期間 | Begin Snap / End Snap の日時 | 問題発生時刻を含む期間か |
| Elapsed Time | Elapsed: xx.xx (mins) | 短すぎると統計が不安定、長すぎると薄まる |
| DB Time | DB Time: xx.xx (mins) | 後続STEPで使う基準値 |
| インスタンス情報 | Database / Instance / Host | 対象サーバーと一致しているか |
| RAC構成 | Instance Numberの有無 | RAC の場合は全インスタンスの比較も必要 |
詳細は PART 03 — Report Summary 詳細（セクション定義書） を参照。
STEP 2 — DB Timeで全体の重さを把握する
DB Time（データベース全セッションが消費した合計時間）を Elapsed Time で割った比率が、 DBの「重さ」を示す最初の指標です。
| DB Time / Elapsed Time の比率 | 状態の目安 | 判断 |
|---|---|---|
| 1未満 | セッションはほぼ待機なし | 正常 |
| 1〜5 | ある程度の負荷 | 要確認 |
| 5〜10 | 明らかに高負荷 | 問題あり |
| 10超 | 深刻な性能問題 | 緊急対応 |
DB Timeの詳細な解説は PART 03 — DB Time と Elapsed Time（AWR入門） を参照。
STEP 3 — Top 5 Timed Eventsで問題の種類を特定する
DB Timeの内訳を示すTop 5 Timed Eventsが、問題の「種類」を特定する最重要セクションです。 上位イベントを見れば、CPUボトルネック・I/Oボトルネック・競合・アプリ設計問題など方向性が絞れます。
| 上位イベントの種類 | 問題の方向性 | 次に読むPART |
|---|---|---|
| CPU time が1位 | CPU使用率が高い | PART 03 CPU分析 |
| db file sequential read / scattered read | I/Oボトルネック | PART 06 I/O分析 |
| buffer busy waits / latch: cache buffers chains | バッファ・Latch競合 | PART 08 Latch/Lock |
| log file sync / log file parallel write | REDO/コミット過多 | PART 04 Wait分析 |
| enq: TX - row lock contention | 行ロック競合 | PART 08 Latch/Lock |
Top 5 Eventsの読み方の詳細は PART 04 — Top 5 Timed Events（AWR入門） および PART 04 — Wait Events Statistics 詳細（定義書） を参照。
読み方フロー早見表
AWRを読む前によくある誤り
AWR診断で経験が浅いうちに陥りやすい落とし穴と、正しいアプローチを整理する。
| 誤りのパターン | なぜ問題か | 正しいアプローチ |
|---|---|---|
| Top 5 Eventsだけ見て問題を断定する | Top 5のイベントは症状であり原因ではない。「db file sequential read」が多い場合でもインデックス不足・ストレージ性能不足・そもそも正常なアクセスと複数の原因がある | Top 5でカテゴリを絞った後、専門PART（SQL Statistics / I/O Stats / Latch等）で根拠を確認してから判断する |
| スナップショット期間を確認せずに数値を比較する | スナップ期間が30分と4時間のレポートを比較すると、1時間あたりの数値が全く違うため誤った診断になる | 比較読みでは必ず両方のElapsed Timeを確認し、1秒あたりの数値（/s値）を見る |
| DB Time / Elapsed Timeが1以下なので「問題なし」と判断する | セッション数が少ない時間帯や夜間帯を含むスナップでは比率が低く見える。特定のバッチ処理時間帯だけを含むスナップでないと正確に判断できない | 問題が発生した時間帯を含むスナップと、正常時のスナップを比較して差分を見る |