Wait Eventの一覧をただ上から眺めても、FGとBGが混在していると本当のボトルネックは見えてこないもので、カテゴリ分類とHistogramを組み合わせて読む方法を、待機イベントの分類に苦労した経験をもとにまとめました。
FGとBG — Wait Eventの2種類
図1: STATSPACKからのWait Event原因特定
STATSPACKのWait Eventsセクションは Foreground（FG） と Background（BG） に分離されています。 これがAWRと異なる重要な点です。
| 種類 | 対象プロセス | 診断の意義 |
|---|---|---|
| Foreground Wait Events | ユーザーセッション | ユーザーが体感する遅延の直接原因 → 最優先で分析 |
| Background Wait Events | DBWn/LGWR/ARCnなどOracleバックグラウンドプロセス | ディスクI/O・REDO書き込みのボトルネック把握 |
| Wait Events (fg and bg) | FG+BG合算 | 全体俯瞰には使えるが、個別診断はFG/BG分離で行う |
全体フローは PART 01。Wait Eventsセクションの定義は PART 04 — Wait Events Statistics 詳細（定義書） を参照。
Wait Eventのカテゴリ分類
Foreground Wait Eventsに現れるイベントを4カテゴリに分類します。
| カテゴリ | 代表的なイベント | 次のアクション |
|---|---|---|
| User I/O | db file sequential read, db file scattered read | PART 06 I/O分析 |
| System I/O | log file parallel write, db file parallel write | Background Wait Events も確認 |
| Concurrency | buffer busy waits, latch系, enqueue系 | PART 08 Latch/Lock |
| Commit | log file sync | コミット頻度・LGWR性能を確認 |
I/O系待機イベント
| Wait Event | 意味 | 対処の方向性 |
|---|---|---|
| db file sequential read | インデックスを使ったシングルブロック読み込み | インデックス不適切 / I/O性能不足 → PART 06 |
| db file scattered read | フルスキャンのマルチブロック読み込み | 不要なフルスキャン → PART 05 |
| direct path read temp | 一時セグメントからの読み込み | ソート/ハッシュのメモリ不足 → PART 07 |
競合系待機イベント
| Wait Event | 意味 | 対処の方向性 |
|---|---|---|
| buffer busy waits | バッファブロックの競合 | ホットブロック → PART 08 |
| latch: cache buffers chains | バッファキャッシュのLatch競合 | ホットブロック → PART 08 |
| enq: TX - row lock contention | 行ロック競合 | トランザクション設計見直し → PART 08 |
| log file sync | COMMITのREDOログ書き込み待ち | コミット頻度削減 / LGWR I/O改善 |
Wait Event Histogramの活用
Wait Event Histogram（STATSPACKのWait Events内）はイベントの待機時間分布を示します。 AVG値だけでは見えない「少数の極端に長い待機」を検出するのに有効です。
| Histogramの見方 | 診断のポイント |
|---|---|
| 1ms以下に集中 | 通常はメモリアクセス。問題なし |
| 8ms〜32msにピーク | HDD相当のI/O遅延 |
| 1秒以上の待機がある | ロック待ち・ネットワーク問題の可能性 |
STATSPACKならではのWait診断のポイント
AWRと共通の分析手順に加え、STATSPACKのFG/BG分離とHistogramを活かした診断のポイントを整理する。
| ポイント | 具体的な確認方法 | AWRとの違い |
|---|---|---|
| FG/BGを分けて原因を切り分ける | Foreground Wait Eventsでユーザー体感の遅延原因を確認してからBackground Wait Eventsでシステム側の問題を確認する | AWRは合算表示が基本。STATSPACKはFG/BG分離が標準のため、バックグラウンドノイズにより診断がブレにくい |
| Wait Event Histogramで外れ値を検出する | 平均待機時間が短くても、1秒超の待機が数件あればロック競合やストレージ瞬断の可能性がある | AWRのHTMLレポートも分布を表示するが、STATSPACKのHistogramはテキスト表形式で扱いやすい |
| log file syncのFG比率を確認する | Foreground側にlog file syncが多ければアプリのコミット頻度が高い。Background側に多ければLGWRのI/O性能の問題 | AWRは合算のため、どちらの問題かが1画面では判断しにくい |
| Snap Level 5以上が必要なイベントを把握する | Snap Level 5未満ではWait Eventsのセクション自体が取得されないため、比較前にスナップのレベルを確認する | AWRはデフォルトで全イベントを取得。STATSPACKはSnap Levelの設定によって取得内容が変わる |
ドリルダウン手順
1
Top 5 Timed Events で上位イベントを確認
Wait Event名と % DB Time を記録する
2
Foreground Wait Events でFGの詳細を確認
ユーザーへの影響が大きいFGイベントを優先的に分析
3
カテゴリを判定して専門PARTへ
I/O系 → PART 06 / 競合系 → PART 08 / SQL問題 → PART 05
4
Wait Event Histogramで待機時間分布を確認
ロング待機が少数ある場合は特定イベントの詳細を調査
Wait分析でよくある誤り
Wait Eventの名称だけで原因を決めつけると対策が的外れになる。
| 誤り | 何が起きるか | 正しい読み方 |
|---|---|---|
| 「db file sequential read」が上位なので「索引アクセスが遅い＝ストレージ増強」と判断する | 実際はSQL側の非効率（索引が選択されすぎるFull Index Scan等）が原因のことがあり、ストレージ増強では改善しない | I/O分析（PART 06）でAv Rd(ms)を確認し、ストレージ遅延かSQL非効率かを分離する |
| Idle Wait（SQL*Net message from client等）をWait分析の対象に含める | Idleイベントはアプリの待ち時間であり、DB側の問題ではない。含めると「待機イベントが多い」と誤解する | Non-Idle Wait ClassのForeground Wait EventsのみをWait分析の対象にする |
| Wait Event Histogramを省略する | 平均待機時間が低くても間欠的なスパイク（>1秒ビン）を見逃し、断続的な障害を早期発見できない | 主要Wait EventのHistogramで>1sビンの有無を必ず確認する |