なぜ最重要セクションなのか
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は何か、何セッションが待っているかを次のセクションで掘り下げていきます。