STATSPACKレポートを受け取って、最初の3分で「問題あり／なし」を判断しなければならない場面がよくあります。細かい数値を全部読んでいては間に合いません。Time ModelのDB CPU比率やHard Parse比率など、短時間でアタリを付けるための6つの指標に絞って解説します。
ヘルスチェックの目的
図1: STATSPACKヘルスチェック指標の読み方
STATSPACKレポートを受け取ったとき、詳細分析の前に「問題があるかどうか」を短時間で判断することが重要です。 本記事で挙げる指標を数分でスキャンするだけで、問題の有無と大まかな方向性が絞り込めます。
全体フローは PART 01 — 全体読み方フロー を参照。
Elapsed Time比率でざっくり判断
AWRのDB Timeに相当する直接指標はSTATSPACKにありません。代わりに Time Model System Stats の
DB CPU（% DB Time）と Load Profile の Logical reads/s・Transactions/s の組み合わせで全体負荷を判断します。
| Time Model DB CPU % | 判断 | アクション |
|---|---|---|
| 80%超 | CPUボトルネック | PART 03 CPU分析 へ |
| 20〜80% | CPU+待機の混在 | Top 5 Events で待機イベントを確認 |
| 20%未満 | 待機がボトルネック | PART 04 Wait分析 へ |
Time Model System Statsの詳細は PART 04 — Wait Events Statistics 詳細（定義書） を参照。
CPU使用率の目安（Time Model）
Time Model System Stats はSTATSPACKでも確認できます。
DB CPU・sql execute elapsed time・parse time elapsed の割合が診断の基点です。
| Time Model 項目 | % DB Time の目安 | 判断 |
|---|---|---|
| DB CPU | バランスを確認 | 高すぎ → SQL/ハードパース問題 |
| parse time elapsed | 10%超 | ハードパース過多の可能性 |
| PL/SQL execution elapsed time | 30%超 | PL/SQLのチューニングが必要 |
キャッシュヒット率の目安
Instance Efficiency Percentages（レポートヘッダ内）でキャッシュ効率を確認します。
| 指標 | 目安 | 問題時のアクション |
|---|---|---|
| Buffer Nowait % | 99%以上 | 低い場合 → buffer busy waitsを確認 |
| Buffer Hit % | 95%以上 | 低い場合 → PART 07 メモリ分析 |
| Library Hit % | 99%以上 | 低い場合 → ハードパース・共有プール不足 |
| Latch Hit % | 99.9%以上 | 低い場合 → PART 08 Latch分析 |
Instance Efficiencyの詳細は PART 03 — レポートヘッダ詳細（定義書） を参照。
Hard Parse比率の目安
Load Profile の Hard Parses と Parses の比率でバインド変数問題を判断します。
| Hard Parse比率 | 判断 |
|---|---|
| 5%未満 | 良好 |
| 5〜20% | 要確認 — バインド変数未使用の可能性 |
| 20%超 | 問題あり — PART 03 CPU分析 で詳細確認 |
複数指標が同時に問題の場合
複数の指標が同時に悪化している場合は、単独指標よりも組み合わせで判断することで診断の精度が上がる。
| 組み合わせパターン | 推定される原因 | 参照PART |
|---|---|---|
| DB CPU % 高 + Hard Parse比率 高 | バインド変数未使用によるハードパース過多 | PART 03 CPU分析 |
| Buffer Hit % 低 + db file sequential readが上位 | インデックスが機能していないか、データが大きすぎてキャッシュに乗らない | PART 06 I/O分析 |
| Latch Hit % 低 + enq: TX – row lock contention | ロック競合とLatch競合が同時発生（特定テーブルへの集中アクセス） | PART 08 Latch/Lock |
| Buffer Hit % 低 + バッチ直後 | 大量データを読むバッチがキャッシュを圧迫、通常クエリが物理I/Oに | PART 07 メモリ分析 |
ヘルスチェックリスト
| チェック項目 | 見る場所 | 目安 | 問題時のアクション |
|---|---|---|---|
| DB CPU % | Time Model System Stats | バランスを確認 | PART 03 |
| Top 1 Wait Event | Top 5 Timed Events | CPU timeが1位が理想 | PART 04 |
| Buffer Hit % | Instance Efficiency | 95%以上 | PART 07 |
| Latch Hit % | Instance Efficiency | 99.9%以上 | PART 08 |
| Hard Parse比率 | Load Profile | 5%未満 | PART 03 |
| 重いSQL | SQL ordered by Elapsed Time | 突出したSQLがないか | PART 05 |
ヘルスチェックでよくある誤り
ヘルスチェックの指標は「正常の入口」であり、これだけで全体を判断しようとすると見落としが生じる。
| 誤り | 何が起きるか | 正しい使い方 |
|---|---|---|
| Buffer Hit % 95%超で「キャッシュ問題なし」と判断する | 全体の命中率が高くてもHot Segmentへの集中や大量Full Scanは見逃す | ヘルスチェック後にI/O分析（PART 06）とSQL分析（PART 05）で実際のI/Oパターンを確認する |
| Hard Parse比率が低いので「SQLは問題なし」と判断する | Hard Parseが少なくてもElapsed/Execute が突出するSQLはありえる | SQL ordered by Elapsed Timeで重いSQLの有無を独立して確認する |
| チェック項目がすべて閾値内なので「問題なし」と報告する | 閾値は目安であり、業務特性（バッチ多用/OLTP中心）によって許容値は変わる | 前回比較（PART 09）で変化傾向を確認し、「正常値だが悪化傾向」を見逃さない |