CPU高負荷の症状
AWRでCPU高負荷を示すサインは複数あります。以下の指標のいずれかが引っかかったら本記事の手順で分析します。
- Top 5 Eventsの1位が CPU time
- Time Model Statistics の DB CPU / DB Time が 80%超
- Load Profile の Hard Parse / Total Parse が高い
- OS側でCPU使用率がほぼ100%に張り付いている
全体フローは PART 01 — 全体読み方フロー、ヘルスチェック指標は PART 02 — ヘルスチェック を先に確認してください。
Time Model Statistics を確認する
Time Model Statistics（AWRの Time Model セクション）は、DB Timeの内訳を示します。
DB CPUの % DB Time がまず最重要です。
| Time Model 項目 | 意味 | 高い場合の診断 |
|---|---|---|
| DB CPU | CPUで実際に処理した時間 | SQL処理・ソート・ハッシュ結合が重い |
| sql execute elapsed time | SQL実行時間（待機を含む） | 重いSQLが存在 → PART 05 |
| parse time elapsed | 解析（パース）時間 | ハードパースが多い可能性 |
| hard parse elapsed time | ハードパースのCPU時間 | バインド変数未使用の可能性 |
| PL/SQL execution elapsed time | PL/SQL実行時間 | PL/SQLロジックの最適化が必要 |
Time Model Statisticsの詳細は PART 04 — Wait Events Statistics 詳細（定義書） 内の Time Model セクションを参照。
CPU関連のWait Eventを読む
CPU高負荷の場合、Top 5 Timed Eventsに「CPU time」が高い割合で現れます。 それに加えて以下の待機イベントが見られる場合は要注意です。
| Wait Event | 意味 | 原因 |
|---|---|---|
| library cache: mutex X | ライブラリキャッシュの競合 | ハードパース過多・カーソル共有不足 |
| latch: library cache | ライブラリキャッシュのラッチ競合 | 同上 |
| cursor: pin S wait on X | カーソルの共有競合 | 同一SQLの同時実行 |
| latch: shared pool | 共有プールのラッチ競合 | 共有プールサイズ不足 |
待機イベントの詳細分析は PART 04 — Wait Eventドリルダウン を参照。
ハードパース問題を特定する
ハードパースが多いとCPU使用率が上がり、ライブラリキャッシュ競合も引き起こします。
Load Profileの Hard Parses と Parses の比率を確認します。
⚠️ ハードパース多発の主な原因
① バインド変数を使わずにリテラル値をSQLに直接埋め込んでいる（WHERE id = 123）
② cursor_sharing = EXACT（デフォルト）のままバインド変数未使用
③ セッションごとにカーソルをキャッシュしていない（session_cached_cursors が小さい）
ハードパースの原因となる重いSQLは SQL Statistics（定義書） のハードパース件数ランキングを参照。