PART 09 - 比較読み（正常時 vs 問題発生時）

正常時のAWRを保存しておらず、問題発生時のレポート単体で「何が異常か」を判断できず苦労した経験があります。比較読みのための準備と指標の選び方をまとめました。

比較読みの目的と準備

図1: 正常時 vs 問題発生時の比較読み手順

AWRの最大の強みの一つは複数スナップショットを比較できることです。「問題発生時」のAWRだけを見ても、それが異常かどうか判断できない場合があります。 正常時との比較によって初めて異常を正確に検出できます。

比較読みが特に有効な場面：

各セクションの読み方は PART 03 〜 PART 08 および AWRセクション定義書を参照。

AWRの値はスナップショット期間中の累積値または平均値です。単純な数値の比較ではなく、期間で割った「1秒あたり」の値を比較することが重要です。

比較時の注意点	理由
期間（Elapsed Time）が異なる場合は /秒に正規化する	長い期間のAWRは累積値が大きくなるため
Load Profile の値はすでに /秒または /トランザクション	そのまま比較可能
業務ピーク時間帯を合わせて比較する	オフピーク vs ピーク比較は意味がない
同一スナップショット間隔（例：1時間）のAWRで比較する	間隔が異なると単純比較できない

💡 AWR Diff Report（差分レポート）の活用

OracleにはAWR Diff Reportという2つのAWRを比較する機能があります。@?/rdbms/admin/awrddrpt.sql で生成でき、正常時と問題時の差分を自動整理してくれます。

比較読みを効果的に行うために、正常稼働時のAWRをベースラインとして保存しておくことをお勧めします。 Oracleには DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE でベースライン（スナップショット保存期間の延長）を作成する機能があります。

比較読みが有効に機能する代表的なシナリオと、着目すべき変化のパターンを示す。

シナリオ	正常時との主な変化	診断の方向性
リリース後から突然遅くなった	Top SQLに新しいSQL_IDが出現。Elapsed Timeが急増	新規SQLの実行計画を確認。統計情報が古いか、インデックスが意図通り使われているか
データ量が増えてから徐々に遅くなった	Buffer Cache Hit %が緩やかに低下。db file sequential readが増加傾向	Buffer Cache Advisory でキャッシュサイズの効果を試算。増設を検討
月次バッチだけが先月より2倍遅くなった	特定SQLのElapsed Timeが増加。Logical Reads/sが急増	バッチが処理するデータ量の変化を確認。統計情報が古く全件スキャンになっていないか
定期メンテナンス後から性能が落ちた	Hard Parses/sが急増。Library Hit %が低下	共有プールFLUSHなら一時的現象。継続するなら統計情報収集の影響を調査

AWRの比較読みは「差分があれば問題」ではなく「意味のある差分かどうか」を判断することが重要だ。

誤り	何が起きるか	正しい見方
業務量の違いを考慮せず比較する	問題発生時に業務量が2倍だった場合、DB Timeが2倍でも異常ではないのに「劣化」と誤判断する	DB Time / Executions（SQL単位の処理時間）で正規化し、業務量あたりのDB負荷を比較する
スナップショット間隔が異なる2つのレポートを比較する	間隔が2倍違うとDB Timeも2倍になるため、絶対値での比較が意味をなさない	比較するレポートは同一のスナップショット間隔に揃え、Per Second値（1秒あたり）で比較する
新しいWait Eventが出た際に原因を推測で判断する	正常時に存在しないWait Eventは重要なシグナルだが、名称だけで判断すると誤診になる	Latch定義書・Wait Event定義書でイベントの意味を確認し、対応するPARTで診断する