AWRに慣れた状態でSTATSPACKレポートを渡されると、どこから読めばいいのか一瞬手が止まります。Top 5 Timed Eventsにたどり着くまでの3ステップを、AWR経験者がつまずきやすいポイントに絞って整理しました。
本ガイドの位置づけ
図1: Statspackレポート読み方フロー（Load Profile→Top 5 Events→SQL統計→Instance IO→Memory Summary）
本シリーズはSTATSPACKレポートを実際に受け取ったときに、どこからどう読むかを解説する実践ガイドです。 各セクションの項目定義は STATSPACKセクション定義書（全10回） を参照してください。
💡 ガイドの使い方
本記事（PART 01）で全体フローを把握した後、問題の種類に応じたPARTへ直接ジャンプしてください。各PARTは独立して読めます。
AWRとの主な違い
STATSPACKはAWRと同様のパフォーマンス情報を提供しますが、いくつかの重要な差異があります。 読み方にも影響するため、最初に把握しておきます。
| 観点 | STATSPACK | AWR |
|---|---|---|
| ライセンス | Oracle SE / EE（追加費用なし） | Oracle Diagnostics Pack（有償） |
| 全体負荷の指標 | Elapsed Time + DB CPU（Time Model） | DB Time（専用指標） |
| SQL識別子 | Hash Value（Old Hash Value） | SQL_ID |
| PGA Advisory | 限定的（post-07に一部あり） | PGA Memory Advisoryが充実 |
| SGA Advisory | post-10（SGA / Advisory） に集約 | post-07に集約 |
| Latch詳細 | Latch Sleep Breakdown（時系列あり） | Latch Activityのみ |
AWRとSTATSPACKの全体的な違いは PART 01 — STATSPACKセクション定義書 はじめに を参照。
STEP 1 — レポートヘッダで環境・期間を確認する
レポートヘッダ（Database / Instance Information · Snapshot Information）でスナップショット情報を確認します。 ここを確認しないと、誤った期間のデータを分析するリスクがあります。
| 確認項目 | どこを見るか | チェックポイント |
|---|---|---|
| スナップショット期間 | Begin / End Snapshot Id・日時 | 問題発生時刻を含む期間か |
| Elapsed Time | Elapsed: xx.xx (mins) | 期間の長さを把握（後続の計算に使う） |
| DB Time | DB Time: xx.xx (mins)（Time Model） | 全体負荷の基準値（AWRと同様） |
| インスタンス情報 | Database / Instance / Host | 対象サーバーと一致しているか |
| STATSPACKレベル | Snap Level | レベル5以上でSQL全文が収録される |
レポートヘッダの各項目詳細は PART 03 — レポートヘッダ詳細（定義書） を参照。
STEP 2 — Elapsed Timeと主要指標で全体を把握する
AWRのように単独の「DB Time」指標はありませんが、Load ProfileとInstance Efficiencyを合わせて読むことで全体の重さを判断します。
| 確認箇所 | 見る値 | 判断の目安 |
|---|---|---|
| Time Model System Stats | DB CPU / DB Time % | 80%超 → CPUボトルネック。低い → 待機が多い |
| Load Profile | Redo size / Transactions / Logical reads（/sec） | 増加傾向・突出した値がないか |
| Instance Efficiency | Buffer Nowait % / Buffer Hit % | Buffer Hit % 95%未満 → メモリ不足の可能性 |
| Load Profile | Hard Parse % | 5%超 → バインド変数未使用の可能性 |
STEP 3 — Top 5 Timed Eventsで問題の種類を特定する
Top 5 Timed Events（レポートヘッダの末尾）が問題の方向性を示す最重要指標です。
| 上位イベントの種類 | 問題の方向性 | 次に読むPART |
|---|---|---|
| CPU time が1位 | CPU使用率が高い | PART 03 CPU分析 |
| db file sequential / scattered read | I/Oボトルネック | PART 06 I/O分析 |
| buffer busy waits / latch系 | バッファ・Latch競合 | PART 08 Latch/Lock |
| log file sync | コミット過多・REDO I/O | PART 04 Wait分析 |
| enq: TX - row lock contention | 行ロック競合 | PART 08 Latch/Lock |
読み方フロー早見表
STATSPACKの読み方でよくある誤り
読み方フローを理解していても、出発点の判断を誤ると診断全体が外れる。
| 誤り | 何が起きるか | 正しい読み方 |
|---|---|---|
| スナップショット期間に問題発生時刻が含まれているか確認しない | 通常業務時間帯のレポートで夜間バッチの問題を診断しようとしても、平均値が薄まって異常が見えない | レポートヘッダのBegin/End Snap Timeが問題発生時刻をカバーしているか必ず確認する |
| STATSPACKレベルを確認せずにSQL統計がないと言う | デフォルトのLevel 5ではSQL統計が含まれないため、SQL分析できないと誤解する | SPREPORTのReport Header「Stats level」でレベルを確認。SQL分析にはLevel 6以上が必要 |
| Top 5 Timed Eventsだけで原因を断定し専門PARTを飛ばす | Top 5は入口に過ぎず、同じ「db file sequential read」でも索引設計不備・Buffer Cache不足・ストレージ遅延と原因が異なる | Top 5は方向性を絞るためのもの。必ず対応する専門PARTで詳細を確認してから結論を出す |