CPU使用率90%というアラートだけでは、Oracle内部で何が起きているかは分かりません。Time Model StatisticsとWait Eventを突き合わせて原因を切り分けた際の手順を記録しています。
CPU高負荷の症状
図1: CPU高負荷時のAWR分析フロー
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（定義書） のハードパース件数ランキングを参照。
CPU高負荷 診断でよくある誤り
CPU負荷が高いときに取りがちな誤った対処と、正しい切り分けのポイントを整理する。
| 誤りのパターン | なぜ誤りか | 正しい確認方法 |
|---|---|---|
| OS側のCPU100%を見て「サーバースペックが不足」と判断する | ハードパース多発やフルスキャンが原因の場合、ハードウェア増強では解決しない | AWRのTime Model Statistics でDB CPU % と Hard Parse比率を先に確認する |
| Hard Parsesが多いのでshared_pool_sizeを増やす | バインド変数未使用が原因の場合、Shared Pool増加は一時凌ぎでしかなく根本解決にならない | SQL ordered by Parse CallsでParse Callsが多いSQLを特定。バインド変数化が先決 |
| CPU timeが1位なのでCPU関連の待機イベントだけを調査する | CPU timeは「CPUが使われている」状態であり、それ自体が悪いわけではない。過剰なSQLの問題が本質 | SQL ordered by CPU Timeで消費の多いSQLを特定し、実行計画を確認する |
| library cache mutexがあるのでShared Poolを増やす | mutex競合はハードパース多発が直接原因であることが多く、Shared Pool増加だけでは解消しない | Hard Parse比率を確認し、バインド変数の使用とsession_cached_cursorsを見直す |