同じ確認漏れを何度も繰り返さないよう、自分用に作っていたメモを10項目のチェックリストとして整理し直しました。シリーズの締めくくりとして活用してもらえればと思います。
分析チェックリスト（10項目）
図1: AWRレポート分析10項目チェックリスト
AWRレポートを手にしたとき、まず確認すべき10のポイントです。順番に潰していけば、大半のパフォーマンス問題の仮説が立てられます。
| # | 確認項目 | 確認すべき値・判断基準 |
|---|---|---|
| 1 | レポート期間・スナップショット番号を確認した | 問題発生時刻がレポート範囲内に含まれているか |
| 2 | DB Time と Elapsed Time の比率（平均AAS）を確認した | AAS = DB Time / Elapsed Time。CPUコア数と比較する |
| 3 | Top 5 Timed Events の1位の待機イベントを特定した | CPU time・db file sequential read・log file sync 等の意味を把握する |
| 4 | CPU time の割合が 50% 以上か確認した | 50%以上ならCPU処理が主。50%未満は待機が支配的 |
| 5 | Elapsed Time Top 10 SQL を確認した | SQL_IDを控え、実行計画を確認する |
| 6 | Physical Reads Top 10 SQL を確認した | EXECUTIONS（実行回数）と組み合わせて判断する |
| 7 | Buffer Cache Hit Ratio が 95% 以上か確認した | 95%未満はキャッシュ不足またはフルスキャン多発の疑い |
| 8 | PGA Over-Allocation Count を確認した | 0 が理想。0より大きいとSpill to Diskが発生している |
| 9 | Tablespace I/O で偏りがないか確認した | TEMP・UNDO・REDOへの集中はそれぞれ異なる原因を示す |
| 10 | log file sync が Top 5 に含まれる場合はCOMMIT頻度を確認した | コミット頻度を下げる・REDOログディスクのI/O性能を確認する |
このチェックリストを手順通り実施すれば、大半のパフォーマンス問題の仮説を立てることができます。
代表的な問題パターンと対処の早見表
Top 5 Timed Events に現れやすい待機イベントと、その対処方針をまとめます。
| 待機イベント（Top 5 に登場） | 原因の可能性 | 最初の対処 |
|---|---|---|
| db file sequential read | インデックス読み込みのI/O遅延 | SQL Statistics → 実行計画確認 |
| db file scattered read | フルスキャン多発 | Physical Reads Top 10 → インデックス追加 |
| log file sync | COMMIT頻度過多・REDOディスク遅延 | Redo Size / commit比 → コミット頻度調整 |
| enq: TX - row lock contention | 同一行への集中UPDATE | 長時間ロックを保持するセッション特定 → ロジック見直し |
| latch: shared pool | ハードパース多発 | Parse Calls Top 10 → バインド変数化 |
シリーズまとめ
AWRレポートはOracleの「総合健康診断書」。一度に全部を読もうとせず、以下の流れで進めるのが効率的です。
- まず DB Time と Top 5 Timed Events で「何が重い」かを把握
- SQL Statistics で「どのSQLが悪い」かを特定
- Memory / I/O 統計 でインフラ側のボトルネックも確認
- チェックリストを活用して体系的に分析を進める
本シリーズでカバーした内容は入門レベルですが、このフローを習得するだけで多くの性能問題の初期調査が自力でできるようになります。大切なのは「仮説を持って読む」こと——Top 5 Timed Events で方向性を決め、その仮説を裏付けるセクションを選んで深掘りする、というアプローチです。
次のステップ
本シリーズは「入門」レベルです。実務で深掘りしていくには、以下のような領域に進んでいくと良いでしょう。
- ASHレポート（Active Session History）: 1秒単位のセッション状態履歴。AWRより細かい粒度で問題の瞬間を特定できる。
ashrpt.sqlで生成。 - SQLトレース（イベント10046）: 個別SQLの詳細な実行プロファイル。バインド変数の値や待機イベントの発生タイミングまで記録される。
- AWR差分レポート: 異なる2期間（正常時 vs 異常時）の統計差分を自動集計。性能劣化の原因切り分けに非常に有効。
awrddrpt.sqlで生成。 - SQL Tuning Advisor: Oracle が推奨するチューニング提案を自動生成する機能。SQL_IDを投入するだけでインデックス・SQL書き換えのヒントを返す。
- Statspack: Diagnostics Pack ライセンスがない環境向けのAWR代替ツール。
継続的な AWR 分析で Oracle DB を健全に保ちましょう。
AWR分析を深めるための実践ポイント
| 場面 | 活用するツール・手順 | ポイント |
|---|---|---|
| 定常監視（週次・月次） | AWR差分レポート（awrddrpt.sql） | 通常時と比較して「増えた待機イベント」「新しく現れたSQL」を素早く検出する |
| バッチ処理の調査 | バッチ前後の手動スナップショット + 専用AWR | 定時スナップショットでは1時間に埋もれるため、EXEC CREATE_SNAPSHOTで区切る |
| SQL単体の詳細調査 | ASHレポート（ashrpt.sql） | AWRは集計値のため、特定SQLの詳細なタイムライン（どのセッションが待っていたか）はASHで確認する |
| 実行計画の変化を確認 | DBMS_XPLAN.DISPLAY_AWR | 性能劣化が突然起きた場合、統計収集や再コンパイルによる実行計画変化を過去計画と比較する |