db file sequential readとlog file syncが同時にランクインしたAWRを前に、どちらが本当のボトルネックか判断できず唸ったことがあります。Top 5 Timed Eventsの読み分け方を、そのときの反省を踏まえてまとめました。
なぜ最重要セクションなのか
図1: Top 5 Timed Eventsセクションの見方
Top 5 Timed Events は、レポート期間中にDBが「最も時間を費やした待機イベント」のランキングです。ボトルネックの方向性をひと目で示してくれるため、AWR分析はまずここから始めます。
サンプルランキング
典型的なランキングは次のような形式で表示されます。
# 待機イベント名 待機時間(秒) % of DB Time
1 db file sequential read 1,234 32%
2 CPU time 980 25%
3 log file sync 540 14%
4 db file scattered read 320 8%
5 enq: TX - row lock contention 180 5%代表的な待機イベントと対処
db file sequential read
意味: インデックス経由の単一ブロック読み込み。
対処: 索引効率を確認。バッファヒット率が低ければBuffer Cacheの増強、不要なI/Oが多ければインデックス設計を見直す。
CPU time
意味: CPUが実際に処理している時間。
対処: 多ければCPU負荷が高い。重いSQLや過剰なハードパースを疑い、CPU増強やSQL最適化を検討。
log file sync
意味: COMMIT待ち（LGWRがREDOログをディスクに書くのを待っている）。
対処: コミット頻度・I/O性能を確認。アプリ側で1行1commitになっていないか、REDOログ用ディスクが遅くないかを調査。
db file scattered read
意味: フルテーブルスキャンに伴う複数ブロックの読み込み。
対処: 不要なFull Scan SQLを特定し、インデックス追加やSQL改善を検討。
enq: TX - row lock contention
意味: 行ロック競合（他セッションが保持している行ロックの解放待ち）。
対処: ロック保持時間の長いSQLを調査。トランザクション分割、コミット粒度の見直しを検討。
判断のセオリー
「CPU time」が1位 ⇒ CPU処理が主因。重いSQLや過剰なパースを疑う。
I/O 待機（db file sequential/scattered read）が多い ⇒ ディスク性能やSQL改善を検討。
ロック待ち（enq:）が多い ⇒ アプリ側のトランザクション設計の見直しを検討。
1位の待機イベントを起点に、そのイベントを引き起こしているSQLは何か、何セッションが待っているかを次のセクションで掘り下げていきます。
待機イベント診断でよくある誤り
| 誤り | 何が起きるか | 正しい読み方 |
|---|---|---|
| CPU timeが1位なのでCPU問題と断定してスペックアップ | 原因がハードパース多発やSQL非効率な場合、CPUを増やしても改善しない | Hard Parsesの数値とSQL Statisticsを確認してCPU消費源のSQLを特定する |
| Top 5 に idle wait（SQL*Net message from client）がある | これはクライアント待ち（アプリ側の処理時間）であり、DB側のボトルネックではない | idle waitは除外して残りの実際の待機イベントをボトルネック判断に使う |
| 1位の待機イベントだけ解消して調査終了 | 1位が解消されると2位以下の問題が顕在化し、改善効果が見えにくくなることがある | Top 5 全体のパターンを把握してから対処の優先順位を決める |
Top 5 Timed Eventsを読む際の注意点
Top 5 Timed Events を見る際に覚えておきたいポイントが3つあります。
① 「% of DB Time」の数値で深刻度を判断する
Top 5 の順位だけでなく「% of DB Time」（DB Time全体に占める割合）が重要です。例えば「db file sequential read が 80%」であれば、DBの処理時間の大半がI/O待ちに費やされていることを意味します。一方で、「1位でも % of DB Time が 10%」であれば、そこまで深刻ではない可能性があります。
② 「idle wait」は無視してよい
待機イベントの中には「SQL*Net message from client」のようなidle wait（アイドル待機）が混入することがあります。これはクライアントからの次のSQL到着を待っている時間であり、DBのパフォーマンス問題ではありません。Top 5 に idle wait が入っている場合はそれを除外して実質的なボトルネックを探します。
③ 複数の問題が同時に起きている場合もある
Top 5 の2位以下も確認してください。1位のI/O問題を解決すると2位のロック問題が顕在化するケースがあります。「1位だけ直せば終わり」ではなく、上位全体のパターンを把握してから対策を立てることが重要です。
よく見かける待機イベント早見表
| 待機イベント | 意味 | 主な対処 |
|---|---|---|
| buffer busy waits | 同一ブロックへの競合（多セッションが同じブロックを読み書き） | HOT BLOCK となっているオブジェクトの分散・パーティション化 |
| latch: cache buffers chains | バッファキャッシュのラッチ競合（高頻度アクセスによるメモリ内競合） | HOT TABLE の洗い出し・Result Cache の活用 |
| direct path read | バッファキャッシュを経由しない直接読み込み（主にパラレルクエリ・大規模フルスキャン） | 一般的には正常動作。I/O スループット不足なら物理ディスクを確認 |
| enq: HW - contention | セグメント拡張（エクステント割り当て）の競合 | AUTOEXTEND の設定見直し・事前に十分な領域を確保 |