PART 02 - ヘルスチェック指標の見方

CPU使用率やキャッシュヒット率の数字だけを見て「問題なし」と判断し、後で痛い目に遭ったことはないでしょうか。目安の数値を鵜呑みにして見落としをした経験から、判断基準を整理しました。

ヘルスチェックの目的

図1: AWRヘルスチェック指標の読み方

AWRを受け取って最初にすることは、詳細分析の前に「問題があるかどうか」を短時間で判断することです。ここで挙げる指標を数分でスキャンするだけで、問題の有無と大まかな方向性を絞り込めます。

全体フローは PART 01 — 全体読み方フローを参照。チェックリスト全体は PART 07 — 分析チェックリスト（AWR入門）も合わせて確認してください。

DB Time ÷ Elapsed Timeが最初の判断軸です。 DB Timeはすべてのセッションが消費したフォアグラウンド時間の合計で、 CPUコア数×Elapsed Timeを超えると明らかな過負荷サインです。

Time Model Statisticsの % DB Time を確認します。 DB CPU の % が高ければCPUボトルネック、低くてもDB Timeが大きければ待機が多いことを示します。

Buffer Cache Hit Ratio（バッファキャッシュヒット率）はメモリにデータがあった割合を示します。 90%を下回ると物理I/Oが増加し、I/Oボトルネックになります。

ハードパース（SQL解析の都度実行）が多いとCPU使用率を押し上げ、ライブラリキャッシュ競合を引き起こします。 Hard Parse / Total Parse の比率が重要です。

チェック項目	見る場所	目安	問題時の次アクション
DB Time比率	Report Summary	CPUコア数以下	全体分析へ
DB CPU %	Time Model Statistics	バランスを確認	PART 03
Top 1 Wait Event	Top 5 Timed Events	CPU timeが1位が理想	PART 04
Buffer Cache Hit	Instance Efficiency	95%以上	PART 07
Hard Parse比率	Load Profile	5%未満	PART 03
重いSQL	SQL Ordered by Elapsed Time	突出したSQLがないか	PART 05

AWRヘルスチェックは指標を読むだけでは不十分。判断の誤りが誤診につながる。

誤り	何が起きるか	正しい読み方
1つのAWRレポートだけで判断する	業務ピーク時間帯のスナップショットを見ていないと「問題なし」という誤診になる	問題が報告された時間帯のスナップショット間隔に絞ったAWRレポートで確認する
Buffer Cache Hit Ratioが95%以上なので「I/O問題なし」と判断する	大量スキャンのSQLが存在していてもHit RatioはI/O Statを見るまで分からない	Hit Ratioとともに「Av Rd(ms)」・I/O Statセクションの物理I/O量も必ず確認する
Hard Parse比率が低いので「共有プール問題なし」と判断する	Literal SQLが少ないだけで、Shared Pool Free %が枯渇している可能性がある	Memory StatisticsのShared Pool Free %も合わせて確認する

実際の障害調査では、複数の指標が同時に悪化していることが多い。その場合は「どれが根本原因でどれが結果か」を判断することが重要だ。

同時に問題が出ている指標の組み合わせ	根本原因の候補	次の診断先
DB CPU高い＋ Hard Parse高い	バインド変数未使用のSQL大量発行	PART 03 CPU分析
Buffer Cache Hit低い＋ db file sequential read が Top Wait	フルスキャン or インデックス不足でデータが毎回ディスクから読まれている	PART 06 I/O分析
DB Time高い＋ CPU低い＋待機イベント上位にlock	ロック競合（長時間のトランザクションや更新集中）	PART 08 Latch・Lock
Buffer Cache Hit低い＋夜間バッチ後	バッチによる大量読み込みがキャッシュをフラッシュした	PART 07 メモリ分析