「DB全体が遅い」という漠然とした報告を受けるたび、どこから調査すればいいのか一から考え直していました。症状別に調査の起点をまとめておけば同じ思考を繰り返さずに済むと考え、シナリオ集として整理しました。

本シリーズの締めくくりとして、症状別に「最初に見るセクション」「次に見るセクション」「原因特定後の確認」を整理したシナリオ集です。困ったときの早見表として使ってください。

1. DB全体が遅い（体感重い）

読み方シナリオ集図

図1: AWRシナリオ別読み方ガイド

  • 最初に見る: Report Summary（Load Profile / Top 10 Foreground Events / Instance Efficiency）
  • 次に見る: Foreground Wait Events（全件）/ Time Model / Top SQL by Elapsed
  • 原因特定後: Segment Statistics で対象セグメント特定 → 該当SQLレビュー

2. CPU使用率が高い

  • 最初に見る: Report Summary（Instance CPU / Host CPU）
  • 次に見る: OS Statistics - Detail（時系列）/ Time Model（DB CPU）
  • 原因特定後: Top SQL by CPU Time → CPU per Exec の大きいSQL特定

3. I/O 待ちが多い（User I/O Class が支配的）

  • 最初に見る: Top 10 Foreground Events（db file sequential read 等）
  • 次に見る: Wait Event Histogram（Avg だけでなく分布確認）/ Top SQL by Reads
  • 原因特定後: Tablespace IO Stats / File IO Stats / Segments by Physical Reads

4. 特定 SQL が遅い（SQL_ID既知）

  • 最初に見る: Complete List of SQL Text で本文確認
  • 次に見る: 各 Top SQL ランキング（Elapsed / CPU / Reads / Parse）で SQL_ID を縦串で確認
  • 原因特定後: 実行計画は AWR 外（DBMS_XPLAN.DISPLAY_AWR）で取得

5. ロック待ち（TX/TM enq）が出ている

  • 最初に見る: Foreground Wait Events（enq: TX-/TM-）
  • 次に見る: Enqueue Activity（lock type 別）/ Segments by Row Lock Waits
  • 原因特定後: Top SQL の Application 列が UPDATE/DELETE で多い → 該当アプリレビュー

6. Library Cache / Soft Parse 低下

  • 最初に見る: Instance Efficiency / Shared Pool Statistics
  • 次に見る: Top SQL by Parse Calls（1 SQLでパース集中?）
  • 原因特定後: Library Cache Activity（Pin Miss / Invalidations）/ Mutex Sleep

7. ハードパース大量・プラン爆発疑い

  • 最初に見る: Top SQL by Version Count / Library Cache Activity
  • 次に見る: Top SQL by Sharable Memory / Shared Pool Advisory
  • 原因特定後: 原因 SQL の V$SQL_SHARED_CURSOR で具体的な理由特定

8. Buffer Hit % が低い

  • 最初に見る: Report Summary（Instance Efficiency / Buffer Pool Statistics）
  • 次に見る: Buffer Pool Advisory（拡張効果試算）/ Top SQL by Reads
  • 原因特定後: Segments by Physical Reads でホットセグメント特定

9. REDO 同期待ち（log file sync）が大きい

  • 最初に見る: Top 10 Foreground Events: log file sync
  • 次に見る: Background Wait Events（log file parallel write）/ Checkpoint Activity / Instance Activity（Redo size）
  • 原因特定後: ストレージ性能確認（LGWR が遅いか）/ コミット頻度の見直し

10. Temp スパイル（PGA不足）疑い

  • 最初に見る: PGA Aggr Summary（Extra W/A Read/Written）
  • 次に見る: PGA Aggr Target Histogram（Multipass 件数）/ IOStat by Filetype（Temp）
  • 原因特定後: Top SQL by Elapsed の SORT/HASH 操作 SQL を特定

11. ロングクエリ → ORA-1555 リスク

  • 最初に見る: Undo Segment Summary（Max Qry Len）
  • 次に見る: Undo Segment Stats（時系列で Max Qry Len 推移）
  • 原因特定後: 該当時刻の Active Session で SQL_ID 確認

12. 夜間バッチ後に性能劣化

  • 最初に見る: init.ora Parameters（変更検知）
  • 次に見る: Memory Dynamic Components（Resize Ops）
  • 原因特定後: ADDM Task / SGA breakdown difference

13. Exadata で SmartScan が効いていない

  • 最初に見る: Top SQL by Physical Reads (UnOptimized)
  • 次に見る: Segments by UnOptimized Reads
  • 原因特定後: 対象 SQL のヒント（NO_PARALLEL/OPT_PARAM）と述語の関数使用を確認

14. ホットブロック疑い（Buffer Busy）

  • 最初に見る: Foreground Wait Events: buffer busy waits
  • 次に見る: Buffer Wait Statistics（class 別）/ Segments by Buffer Busy Waits
  • 原因特定後: 対象セグメントの PCTFREE / INITRANS / パーティション設計レビュー

15. ラッチ競合疑い

  • 最初に見る: Foreground Wait Events: latch: ...
  • 次に見る: Latch Activity（%Miss と Wait Time）
  • 原因特定後: Latch Sleep Breakdown / Latch Miss Sources で具体ラッチ特定

シリーズまとめ

AWRレポートには情報が満載ですが、本シリーズで整理した「セクションの意味」と「シナリオ別調査フロー」を組み合わせれば、必要な情報に素早くたどり着けるようになります。

慣れてくると、Report Summary → Top 10 Foreground Events → Top SQL の流れだけで多くの問題に当たりがつけられるようになります。最初は時間がかかっても、繰り返し読むことで「型」が身についていきます。

AWR読み取りシナリオでよくある落とし穴

シナリオ別調査フローを使う際によくある判断ミスを整理する。

落とし穴何が起きるか回避策
シナリオを一つに絞って他のシナリオを確認しない例：「ロック待ち疑い」で調査を進めたが、実際はSQL非効率による長時間ロック保持が原因だったケースで、SQLチューニングが後回しになるTop 5 Wait Eventsから候補を2〜3シナリオ並行して仮説立てし、相互に排除しながら絞り込む
問題発生時刻を含まないスナップショット間隔のレポートを使う「問題時間帯」のデータが1時間のスナップ平均に薄まり、ピーク時の異常値が見えにくくなる問題時刻±15分に手動スナップショット（DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT）を取得しておく
シナリオの「最初に見るセクション」だけで対策を決定する表層の症状に対して対策（例：ログサイズ拡張）を施しても、根本原因（例：大量更新バッチの分割必要性）が残る「次に見る」セクションまで確認し、対策が根本原因に作用しているかを検証してから実施する