全9回を書き終えて振り返ると、結局「STATSPACKとAWRのどちらを見るべきか」という判断基準を最初にまとめておくべきだったと感じ、このPARTではシリーズ全体を症状別のフローチャートに落とし込みながら使い分けの判断基準を整理しています。
読み方ガイドのまとめ
図1: STATSPACK症状別診断フローチャート
本シリーズでは、STATSPACKレポートを実際に受け取ってから診断・対処の方向性を特定するまでの 実践的な手順をカバーしました。
| PART | テーマ | カバーする問題 |
|---|---|---|
| PART 01 | 全体読み方フロー | 最初の3ステップ・AWRとの違い |
| PART 02 | ヘルスチェック指標 | 問題の有無を短時間で判断する |
| PART 03 | CPU高負荷 | Time Model / ハードパース / CPU待機 |
| PART 04 | Wait Eventドリルダウン | FG/BG分類・Histogram活用 |
| PART 05 | チューニング対象SQL特定 | SQL Statistics / Hash Value活用 |
| PART 06 | I/Oボトルネック | IO by Function / Tablespace / File IO |
| PART 07 | メモリ問題 | Buffer Pool / Shared Pool / SGA Advisory |
| PART 08 | Latch・Lock競合 | Latch Activity / Sleep Breakdown / Enqueue |
| PART 09 | 比較読み | 正常時 vs 問題発生時の差分分析 |
症状別 診断フローチャート
| 症状 | 最初に確認すること | 読むPART |
|---|---|---|
| 全体的にDBが重い | Time Model DB CPU % → Top 5 Events | PART 01 → PART 02 |
| CPU使用率が高い | Time Model System Stats | PART 03 |
| 特定のWait Eventが上位 | Wait Event名でFG/BGカテゴリ判定 | PART 04 |
| 特定SQLが遅い | SQL ordered by Elapsed Time | PART 05 |
| ディスクI/Oが高い | IO Stat by Function / Tablespace IO Stats | PART 06 |
| メモリ不足の疑い | Buffer Hit % / Buffer Pool Advisory | PART 07 |
| 競合・デッドロック | Latch Activity / Enqueue Stats | PART 08 |
| 昨日まで速かった | 正常時STATSPACKと比較 | PART 09 |
STATSPACKとAWRの使い分け
STATSPACKとAWRは同様の情報を提供しますが、使用できる状況が異なります。
| 観点 | STATSPACK | AWR |
|---|---|---|
| ライセンス | Oracle SE / EE（追加費用なし） | Oracle Diagnostics Pack（有償） |
| 推奨バージョン | Oracle 8i〜（古いバージョンでも利用可） | Oracle 10g以降 |
| 自動収集 | 手動 or DBMS_JOBでスケジュール | 自動（デフォルト60分間隔） |
| レポート生成 | spreport.sql | awrrpt.sql |
| 診断詳細度 | 標準的 | AWR Diff Report・ADDM・SQL Monitorなど豊富 |
| PGA Advisory | 限定的 | 充実 |
✅ どちらを使うべきか
Oracle Diagnostics PackのライセンスがあればAWRを使うのが一般的です。 ライセンスがない場合・Oracle SEを使用している場合・旧バージョン環境ではSTATSPACKが唯一の選択肢となります。 診断手法は本ガイドで解説した通り、AWRと非常に近いアプローチで分析できます。
STATSPACKを最大限活かすための実践ポイント
AWRがない環境でSTATSPACKを使いこなすために、特に覚えておくべき実践的なポイントをまとめる。
| ポイント | 具体的な内容 |
|---|---|
| Snap Levelを適切に設定する | Level 5以上でWait Eventsが取得でき、Level 7以上でSQL全文が取得できる。デフォルトLevel 5を確認し、必要に応じてSTATSPACK.SNAPのi_snap_levelを設定する |
| スナップ間隔をワークロードに合わせる | デフォルトは手動。DBMS_JOBで1時間ごとに自動収集するのが基本。バッチ前後や障害発生時は手動でスナップを取得して比較読みに備える |
| FG/BG分離を活かしてノイズを排除する | LGWR・DBWnなどバックグラウンドプロセスのI/O待機はBackground Wait Eventsに分離されている。ユーザー体感の問題はForeground Wait Eventsを優先的に分析する |
| 比較読みのペアを事前に取得しておく | 問題が起きてからでは「正常時」のスナップが存在しないため比較できない。定期的なスナップ収集と、本番リリース前後のスナップ保存を習慣にする |
記事インデックス
STATSPACKセクション定義書（10記事） — 各セクションの詳細定義
- PART 01 - STATSPACKセクション定義書 はじめに
- PART 02 - STATSPACK全体構造マップ
- PART 03 - レポートヘッダ詳細
- PART 04 - Wait Events Statistics 詳細
- PART 05 - SQL Statistics 詳細
- PART 06 - Instance Activity / IO Stats 詳細
- PART 07 - Advisory / Memory Statistics 詳細
- PART 08 - Wait / Undo / Latch 詳細
- PART 09 - Segment / その他 詳細
- PART 10 - SGA / Advisory / パラメータ