正常時のレポートを保存していなかったせいで、問題発生時との比較ができず苦労したことがあります。変化量を正規化して比較する方法と、ベースラインを残しておく重要性を実例とともに書いています。
比較読みの目的と準備
図1: STATSPACK比較読みの手順
STATSPACKは複数スナップショットを取得・保持しているため、正常時と問題発生時の比較が非常に有効です。 1枚のレポートだけを見ていても「これが正常なのか異常なのか」判断できないケースが多くあります。
比較読みが特に有効な場面：
- 「昨日まで速かったのに今日から遅い」という突発的な性能劣化
- 定期バッチの実行時間が徐々に長くなっている
- リリース前後での性能変化の確認
- 季節変動・月次処理のピーク分析
各セクションの読み方は PART 03 〜 PART 08 およびセクション定義書 全体構造マップ（定義書 PART 02） を参照。
比較すべき指標
| 指標 | 見る場所 | 比較のポイント |
|---|---|---|
| DB CPU % / Time Model内訳 | Time Model System Stats | 全体的な負荷構成の変化 |
| Top 5 Wait Eventsの顔ぶれと割合 | Top 5 Timed Events | 新しいイベントの出現・既存イベントの急増 |
| Transactions / Logical reads（/s） | Load Profile | 処理量の変化 |
| Hard Parses/s | Load Profile | 急増はバインド変数問題のサイン |
| Buffer Hit % | Instance Efficiency | 急落はデータ量増加のサイン |
| Latch Hit % | Instance Efficiency | 急落はLatch競合のサイン |
| Top SQLの顔ぶれと % Total DB Time | SQL ordered by Elapsed Time | 新しい重いSQLの出現、既存SQLの悪化 |
変化量の見方
STATSPACKの値はスナップショット間の累積値または /秒・/トランザクションで表示されます。 Load Profileは既に /秒 または /トランザクション に正規化されているため直接比較できます。
| 比較時の注意点 | 理由 |
|---|---|
| Elapsed Timeが異なる場合は /秒 に正規化 | 長い期間のレポートは累積値が大きくなる |
| Load Profile の値はそのまま比較可能 | 既に /秒 または /トランザクション に正規化済み |
| 業務ピーク時間帯を合わせて比較 | オフピーク vs ピーク比較は意味がない |
| 同一スナップショット間隔で比較 | 間隔が異なると単純比較できない |
💡 STATSPACKのスナップショット管理
STATSPACKのスナップショットは STATSPACK.SNAP で手動取得するか、DBMS_JOB でスケジューリングします。
比較読みのためにピーク時とオフピーク時のスナップショットを定期的に取得しておくことを推奨します。
ベースライン作成のすすめ
STATSPACKには自動ベースライン機能はありませんが、保持期間を適切に設定（デフォルト7日 → 変更可能）することで正常時のデータを残しておけます。 重要なスナップショットは削除対象から除外する設定も可能です。
| ベースラインとして保存すべきタイミング |
|---|
| リリース直後（システムが正常に動作している状態） |
| 大規模バッチが正常完了した直後 |
| 月次・年次の業務ピークが正常に終了した直後 |
| チューニング前後（効果測定のため） |
比較読みの実例シナリオ
以下は比較読みが有効に機能する代表的なシナリオと、着目すべき変化のパターンだ。
| シナリオ | 正常時との主な変化 | 診断の方向性 |
|---|---|---|
| リリース後から突然遅くなった | Top SQLに新しいSQL_IDが出現。Elapsed Timeが急増 | 新規SQLの実行計画を確認。統計情報が古いか、インデックスが意図通り使われているか |
| データ量が増えてから徐々に遅くなった | Buffer Hit %が緩やかに低下。db file sequential readが増加傾向 | Buffer Cache Advisory でキャッシュサイズの効果を試算。増設を検討 |
| 月次バッチだけが先月より2倍遅くなった | 特定SQLのElapsed Timeが増加。Logical Reads/sが急増 | バッチが処理するデータ量の変化を確認。統計情報が古く全件スキャンになっていないか |
| 定期メンテナンス後から性能が落ちた | Hard Parses/sが急増。Library Hit %が低下 | 共有プールをFLUSHした場合は一時的な現象。継続するなら統計情報収集の影響を調査 |
比較チェックリスト
| チェック項目 | 変化の目安 | 問題発生時のアクション |
|---|---|---|
| DB CPU % の増加 | +20pt超は要調査 | PART 03 CPU分析 |
| 新しいWait Eventの出現 | 正常時に存在しないイベント | そのイベントに対応したPARTへ |
| Buffer Hit % 低下 | 5pt超の低下 | PART 07 メモリ分析 |
| Top SQL の顔ぶれ変化 | 正常時に上位になかったSQL | PART 05 SQL特定 |
| Latch Hit % 低下 | 0.1pt超の低下 | PART 08 Latch/Lock |
比較読みでよくある誤り
複数レポートの比較は強力な手法だが、比較条件のミスが診断を誤らせる。
| 誤り | 何が起きるか | 正しい比較の仕方 |
|---|---|---|
| 業務量が異なる期間のレポートを同列比較する | 月末バッチ実行日と通常日でElapsed Timeが倍になっても「問題なし」が正解のことがある | Business Transactionsなど業務量指標（Executions / Logical Reads等）で正規化して比較する |
| スナップショット間隔が異なる（例：30分vs120分）レポートを絶対値で比較する | 間隔が長いレポートでは累積値が大きくなり「悪化」に見える | 必ずper-second・per-transaction値（Load Profile）で比較し、間隔の違いを吸収する |
| 比較対象として「問題のあった日」と「最近の日」を比べてしまう | 「最近は正常」なのかが判断できず、問題が再発しているかの把握ができない | 安定した通常業務日（問題なしと確認済みの日）を「ベースライン」として保存・管理し、そこと比較する |