PART 02 — AWRレポートの全体構成

初めてAWRレポートを開いたとき、Report SummaryからSegment統計まで数十ページに渡る出力量に圧倒された記憶があります。どこから手を付けるべきか迷わないよう、各セクションの役割を地図のように整理しました。

AWRレポートの主要セクション

AWRレポートは膨大な情報量を持っていますが、構成を理解すれば「どこを見れば何がわかるか」が見えてきます。代表的なセクションは次の6つです。

セクション	確認できること	優先度
① Report Summary	レポート期間・DB情報・スナップショット番号	必ず確認
② DB Time & Wait Classes	CPU処理 vs 待機時間の全体傾向	必ず確認
③ Top 5 Timed Events	最大のボトルネック（待機イベント）	★最重要
④ SQL Statistics	負荷の高いSQL（実行時間・CPU・I/O別）	状況に応じて
⑤ Instance Activity	統計カウンタ（論理読み込み等）の経時変化	状況に応じて
⑥ I/O Stat & Memory	ディスクI/O・SGAメモリ・PGA使用状況	インフラ調査時

各セクションの詳細と着目点

① Report Summary

レポート対象期間・DB情報・スナップショット番号など、メタ情報を確認するセクションです。「いつのデータか」「どのインスタンスか」を最初に把握します。

ここで確認すべき主な項目は、DB Name（どのDBのレポートか）、Begin/End Snap（スナップショット番号と時刻）、Elapsed Time（レポート対象期間）です。Elapsed Time が異常に短い（数分など）場合、手動スナップショットで取得した可能性があり、通常のピーク時間帯と異なる可能性があります。

② DB Time & Wait Classes

処理時間の内訳と待機クラス別の時間分布です。DB全体の負荷の傾向（CPU処理 vs 待機）が一目でわかります。

Wait Classes は Oracle が待機イベントを分類した大カテゴリです。代表的な分類に「User I/O」「Concurrency」「System I/O」「Commit」「Network」「Application」があります。CPU time の割合が高ければ処理能力不足、特定の Wait Class が突出していればその分野のボトルネックを示唆します。

③ Top 5 Timed Events

最も時間を費やした待機イベントのTop 5です。AWRで最も重要なセクションと言って差し支えないほど、ここから問題の方向性が決まります。

代表的な待機イベントとその意味を覚えておくと分析が速くなります。

• db file sequential read: インデックスによる1ブロック読み込み。I/O性能問題の可能性。
• db file scattered read: フルスキャンによる複数ブロック読み込み。インデックス未使用の可能性。
• log file sync: COMMITのたびにREDOログ書き込みを待機。コミット頻度が高すぎる場合に発生。
• enq: TX - row lock contention: 行ロック競合。同一行へのUPDATE集中が原因のことが多い。
• CPU time: 純粋なCPU処理時間。Top 5 の中でCPU timeが大部分なら、SQLのチューニングが優先課題。

④ SQL Statistics

負荷の高いSQL文の一覧です。実行時間・CPU・I/O など、複数の切り口でランキングされます。Top 5 Timed Events で「CPU timeが多い」「db file sequential readが多い」などを把握した後、このセクションで原因SQLを特定します。

⑤ Instance Activity

各種統計カウンタ（論理読み込み、物理読み込み等）の基礎データです。「User calls」「Logons」「Executions」などの数値を確認することで、その時間帯のアクセス量を把握できます。経時変化を比較する際の基準データとして使います。

⑥ I/O Stat & Memory

ディスクI/O・SGAメモリ・PGA使用状況を確認するセクションです。インフラ側のボトルネックを発見するために使います。Buffer Cache Hit Ratio・Library Cache Hit Ratio・PGA Over-Allocation などを確認します。

推奨の読み進め方

まず ① Report Summary でレポート期間を確認し、
続いて ③ Top 5 Timed Events へ進むのが基本手順です。

上から順に読まなくてもよいので、まず「全体像」と「最大のボトルネック」を押さえることが大切です。Top 5 Timed Events で仮説を立てたら、その仮説を裏付けるためにSQL Statisticsやメモリ・I/O統計を参照する、という流れが効率的です。

具体的なフローを示すと次のようになります。

1. Report Summary → レポート期間・インスタンス確認
2. DB Time / Wait Classes → CPU vs 待機の全体傾向を把握
3. Top 5 Timed Events → 最大ボトルネックの特定・仮説立て
4. 仮説に応じて SQL Statistics / Memory & I/O を参照
5. 対象SQL の SQL_ID を確認し、実行計画を調査

初見でやりがちな失敗

AWRレポートを初めて読む際によくある失敗と対処法を紹介します。

まず「全セクションを上から読もうとする」という失敗があります。AWRレポートはHTML形式で数十ページになることもあり、全部を順番に読もうとすると目的を見失います。上記のフローで「Top 5 から仮説を立てる」手順を先に習慣化しましょう。

次に「Elapsed Time を確認せずに数値を比較する」失敗があります。1時間のレポートと3時間のレポートでは、同じSQL統計の値でも意味が異なります。比較するときは必ずElapsed Timeを揃えるか、「秒あたり」の値を使いましょう。

最後に「単一時点のレポートだけで判断する」失敗があります。性能問題を正確に特定するには、通常時と問題発生時の両方のレポートを比較することが重要です。AWR差分レポート（awrddrpt.sql）を使うと2つのレポートの差分を自動集計できます。

セクション別 優先度と確認タイミング早見表

セクション	確認タイミング	見落としがちな注意点
Report Summary	必ず最初に確認	Elapsed Timeが短い場合、通常の1時間スナップでなく手動取得の可能性。値の比較前に期間を確認する
Top 5 Timed Events	Report Summaryの直後	CPU timeが1位でも「CPUの問題」とは限らない。Hard Parsesが多いことによるCPU消費の場合はSQL問題
SQL Statistics	Top 5で仮説を立てた後	Elapsed Time順だけでなく、CPU Time順・Buffer Gets順で同じSQLが複数リストに出ていないか確認する
I/O Stat & Memory	Top 5でI/O系イベントが上位の場合	Buffer Hit Ratioが高くても物理I/Oが多い場合はDirect Path Readが原因のことがある