【完全ガイド】Oracle AWR レポート 読み方 完全ガイド｜Load Profile・Wait Event・Top SQL 徹底解説

Oracle DBA としてパフォーマンス問題対応で最初に開くレポート、それが AWR (Automatic Workload Repository) です:

              WORKLOAD REPOSITORY report for
DB Name    DB Id       Instance  Inst Num Startup Time   Release   RAC
---------- ----------- --------- -------- -------------- --------- ---
ORCL       1234567890  orcl             1 06-Jun-26 09:15 19.0.0.0 NO

              Snap Id      Snap Time      Sessions Curs/Sess
              ---------- --------------- -------- ---------
Begin Snap:         100 06-Jun 10:00:00       45       2.3
End Snap:           101 06-Jun 11:00:00       52       2.5
Elapsed:                  60.00 (mins)
DB Time:                  145.32 (mins)

Oracle 標準のパフォーマンス分析ツールとして、以下の圧倒的優位性:

• 1 時間ごとのスナップショットを自動収集
• DB Time 分析で時間の使い方を可視化
• Top Wait Events でボトルネック特定
• Top SQL で遅い SQL 発見
• Instance Efficiency でメモリ効率評価
• Load Profile でワークロード特性把握
• 8 日間の履歴（デフォルト）で過去比較
• ADDM による自動診断
• ASH によるセッションレベル詳細
• Autonomous DB でもOCI Performance Hub で統合

このツールの本質は、Oracle 公式 Database Performance Tuning Guide が定義:

「AWR は自動的にパフォーマンス統計を収集し、
  データベースの動作を包括的に分析するリポジトリ。
  スナップショット間隔ごとにキー統計を保存し、
  時間軸でのパフォーマンス変化を追跡可能にする」

AWR vs Statspack vs ASH の使い分け

Oracle パフォーマンス分析ツールの階層:

【AWR】（本記事）
  - 1 時間ごとの集約統計
  - 全体傾向・時系列比較
  - Diagnostic Pack 必要
  - MMON バックグラウンドプロセス

【ASH (Active Session History)】
  - 1 秒ごとのセッションサンプリング
  - 特定時点の詳細分析
  - Diagnostic Pack 必要
  - MMNL バックグラウンドプロセス

【Statspack】
  - AWR の前身
  - ライセンス不要
  - Autonomous DB でも使用可
  - 手動設定

なぜ AWR レポートを読めることが重要か

現場での典型的な流れ:

1. アプリユーザー: 「SQL が遅い」
2. DBA: AWR レポート生成
3. Load Profile → 何が起きているか
4. Top 10 Foreground Events → ボトルネックは何か
5. Top SQL → どの SQL が問題か
6. Instance Efficiency → メモリ足りているか
7. 対策実施

AWR 読めない DBA は現場で通用しない、それほど重要なスキル。

AWR レポートの 9 大セクション

読む順序に沿って整理:

1. Report Summary
   - DB 情報、期間、DB Time / Elapsed Time
   
2. Load Profile
   - DB Time (s) per second
   - Logical/Physical Reads per second
   - Hard Parses per second
   - Redo size per second
   
3. Instance Efficiency Percentages
   - Buffer Hit %
   - Library Hit %
   - Soft Parse %
   
4. Top 10 Foreground Events by Total Wait Time
   - ⭐ 最重要セクション
   - どこで時間を使っているか
   
5. Time Model Statistics
   - DB Time 分解
   - SQL execute elapsed time
   
6. Operating System Statistics
   - CPU、Memory、I/O
   
7. SQL Statistics (Top SQL)
   - SQL ordered by Elapsed Time
   - SQL ordered by CPU Time
   - SQL ordered by Gets
   - SQL ordered by Reads
   
8. Wait Events
   - 全 Wait Events 詳細
   
9. Advisor Statistics
   - Buffer Pool / Shared Pool / PGA Advisor

多くの日本語記事が「AWR を生成せよ」で終わりますが、実務では:

• DB Time > Elapsed Time の意味（Multi-CPU 有効稼働）
• AAS (Average Active Sessions) の計算（DB Time / Elapsed Time）
• Top 10 Events のWait Class 別解釈
• db file sequential read vs db file scattered read の違い
• log file sync の閾値（5ms 警告、20ms 深刻）
• library cache: mutex X によるHard Parse 問題特定
• buffer busy waits のHot Block 対応
• Top SQL のElapsed Time / Executions / Elapsed per Exec の見方
• awrddrpt.sql（Compare Report）による比較分析
• awrsqrpt.sql（SQL Report）による特定 SQL 深掘り
• OCI Performance Hub によるAutonomous DB での分析
• 良好時と問題時の 2 つを比較

さらに、Oracle 現場での鉄則:

1. 問題発生時と正常時の AWR 両方取得
2. Load Profile で正常時との差分確認
3. Top 10 Events で症状特定
4. Top SQL で原因 SQL 特定
5. ASH で瞬間的な詳細把握
6. ADDM で自動診断参照

本記事では、Oracle AWR レポート読み方の全てを実務レベルで完全網羅。基本概念、9 大セクション、主要 Wait Event、Top SQL 分析、ADDM/ASH、Compare/SQL Report、OCI Performance Hub、Autonomous DB、Rails/Java/Python 監視統合、実践シナリオ、FAQまで。この1本で AWR レポートをプロフェッショナルに読めるようになります。

結論：Load Profile → Top 10 Events → Top SQL の順で読む

時間がない方向けに、最速の読み方を先に示します。

3 分で AWR を読む方法

1. DB Time / Elapsed Time 比率
   → 問題があるかざっくり判断

2. Load Profile
   → ワークロード特性把握
   → 正常時との比較

3. Top 10 Foreground Events
   → ボトルネック特定
   → Wait Class 別に見る

4. Top SQL (Elapsed Time / Gets)
   → 問題 SQL 特定

最速のレポート生成

# SYSDBA で
$ sqlplus / as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql

Enter value for report_type: html
Enter value for num_days: 1
Enter value for begin_snap: 100
Enter value for end_snap: 101
Enter value for report_name: awrrpt_20260606_1000.html

6つの必須知識

詳細は以下で解説します。

AWR の仕組み

内部構造

【MMON プロセス（Memory Monitor）】
  → デフォルト 60 分ごとに Snapshot 取得
  → SYS.WRH$_* テーブルに保存

【MMNL プロセス（Memory Monitor Light）】
  → ASH バッファをディスクに書き込み
  → v$active_session_history → dba_hist_active_sess_history

【自動収集】
  → dbms_workload_repository.create_snapshot
  → デフォルト 8 日間保持

Snapshot 管理

-- 現状確認
SELECT snap_interval, retention FROM dba_hist_wr_control;
-- INTERVAL: +00000 01:00:00.0 (60 分)
-- RETENTION: +00008 00:00:00.0 (8 日)

-- 変更（60 分 → 30 分、14 日保持）
BEGIN
  DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
    interval  => 30,       -- 分
    retention => 14 * 24 * 60  -- 分（14 日 = 20160）
  );
END;
/

-- 手動 Snapshot 作成
BEGIN
  DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
END;
/

-- Snapshot 一覧
SELECT snap_id, begin_interval_time, end_interval_time
FROM dba_hist_snapshot
ORDER BY snap_id DESC
FETCH FIRST 20 ROWS ONLY;

ライセンス

⚠️ 重要:
AWR / ASH / ADDM は Diagnostic Pack 必須
Enterprise Edition + 追加ライセンス

Statspack は代替、ライセンス不要
Autonomous DB は含まれる

AWR レポート生成方法

awrrpt.sql（対話形式）

$ sqlplus / as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql

# プロンプト:
Enter value for report_type: html    # or text
Enter value for num_days: 1
# Snap Id 一覧が表示される
Enter value for begin_snap: 100
Enter value for end_snap: 101
Enter value for report_name: /tmp/awrrpt.html

DBMS_WORKLOAD_REPOSITORY（プログラマティック）

DECLARE
  v_report CLOB;
BEGIN
  SELECT DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(
    l_dbid    => (SELECT dbid FROM v$database),
    l_inst_num => (SELECT instance_number FROM v$instance),
    l_bid     => 100,
    l_eid     => 101
  ) INTO v_report FROM dual;
  -- v_report を出力
END;
/

RAC 環境

# 全インスタンス
$ @$ORACLE_HOME/rdbms/admin/awrgrpt.sql

# 特定インスタンス
$ @$ORACLE_HOME/rdbms/admin/awrrpti.sql

関連レポート

# 2 期間比較（超便利）
$ @$ORACLE_HOME/rdbms/admin/awrddrpt.sql

# 特定 SQL 詳細
$ @$ORACLE_HOME/rdbms/admin/awrsqrpt.sql

# ASH レポート
$ @$ORACLE_HOME/rdbms/admin/ashrpt.sql

# ADDM レポート
$ @$ORACLE_HOME/rdbms/admin/addmrpt.sql

セクション1: Report Summary

何を見るか

              Snap Id      Snap Time      Sessions Curs/Sess
              ---------- --------------- -------- ---------
Begin Snap:         100 06-Jun 10:00:00       45       2.3
End Snap:           101 06-Jun 11:00:00       52       2.5
Elapsed:                  60.00 (mins)
DB Time:                  145.32 (mins)

主要指標

Elapsed Time: レポート期間（Snapshot 間の実時間）。

DB Time: 全セッションが DB 内で費やした時間の合計（CPU + 待機）。

DB Time > Elapsed Time:

複数セッションが並行して活動
Multi-CPU 有効稼働の証拠
= 通常

DB Time < Elapsed Time:

セッションが少ない、または CPU 使ってない
= アイドル期間

AAS (Average Active Sessions)

最重要指標:

AAS = DB Time / Elapsed Time

例: 145.32 / 60.00 = 2.42

解釈:

AAS < CPU 数: 通常運用
AAS ≈ CPU 数: 高負荷
AAS >> CPU 数: 深刻な待機発生

セクション2: Load Profile

例

Load Profile              Per Second   Per Transaction
~~~~~~~~~~~              ---------   ---------------
     DB Time(s):              2.42          0.05
      DB CPU(s):              1.65          0.03
Logical read(blocks):      35,240.00      720.15
 Physical reads (blocks):    250.00        5.11
      Redo size (bytes): 2,500,000.00   51,020.41
       Hard parses:            0.25          0.005
             Parses:          125.30         2.56
        Executions:          890.50        18.18
      User calls:           1,250.00       25.51
      Transactions:            48.98

主要指標の解釈

DB Time(s) per second:

= AAS
= 継続的なアクティブセッション数

Logical read (blocks) per second:

高い = SQL がブロック大量アクセス
Physical read と比較 → キャッシュ効率

Physical reads / Logical reads 比率:

Physical / Logical > 10% = ディスク I/O 多い
→ SGA (buffer cache) 不足
→ db file sequential read 増える

Hard parses per second:

> 3 = 要注意
> 100 = 深刻
→ Bind variable 未使用
→ Shared Pool 圧迫

Executions per second:

SQL 実行頻度
アプリの負荷を示す

Redo size per second:

DML 量を示す
急増 = 想定外の DML

Transactions per second (TPS):

COMMIT/ROLLBACK 頻度
アプリのトランザクション量

比較の重要性

正常時 AWR    → 現在 AWR
Load Profile 比較で異常を検出

例: Hard parses/sec が 5 → 150
   = Bind 使ってない SQL 増加

セクション3: Instance Efficiency Percentages

例

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             Buffer Nowait %:  99.98    Redo NoWait %: 100.00
            Buffer Hit %:      99.75    In-memory Sort %: 100.00
            Library Hit %:     99.32     Soft Parse %:  99.85
         Execute to Parse %:   87.51     Latch Hit %:   99.99
Parse CPU to Parse Elapsd %:   90.15    % Non-Parse CPU: 99.78

主要指標の閾値

低い場合の対処

Buffer Hit % < 95%:

→ SGA (buffer cache) 不足
→ SGA_TARGET 増加検討

Library Hit % < 99%:

→ Shared Pool 不足
→ Hard Parse 多い
→ Bind 変数使用検討

Soft Parse % < 95%:

→ Bind 変数未使用
→ アプリの SQL 生成方法見直し

⚠️ 注意: これらの指標だけで判断せず、Wait Events と組み合わせて総合判断。

セクション4: Top 10 Foreground Events by Total Wait Time

例

Top 10 Foreground Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                     Total Wait   Avg    % DB   Wait
Event                       Waits    Time (sec)   Wait   Time   Class
------------------------- --------- ----------- ------- ------ ---------
DB CPU                                    5,830           66.9
db file sequential read   1,250,000     2,500      2.00  28.7  User I/O
log file sync                50,000       250      5.00   2.9  Commit
enq: TX - row lock           15,000       120      8.00   1.4  Application
library cache: mutex X       25,000        95      3.80   1.1  Concurrency

🌟 最重要セクションの読み方

優先順位:

1. % DB Time で降順ソート済み
2. 上位が主要ボトルネック
3. DB CPU が Top なら CPU バウンド
4. I/O 系が Top なら I/O 問題
5. Concurrency 系なら排他問題

Wait Class 別解釈

User I/O（db file sequential/scattered read）:

→ ディスク読み取り待機
→ 対応: インデックス見直し、SGA 増、SSD 検討

Commit（log file sync）:

→ REDO ログ書き込み待機
→ 対応: バッチ COMMIT、REDO ログ最適化

Application（enq: TX - row lock contention）:

→ 行ロック待ち
→ 対応: アプリロジック見直し

Concurrency（library cache: mutex X, latch）:

→ ラッチ・ミューテックス競合
→ 対応: Hard Parse 削減、Bind 使用

System I/O（log file parallel write, control file sequential read）:

→ システム I/O
→ 対応: I/O 分散、SSD

Network（SQL*Net message from client）:

→ ネットワーク・クライアント待機
→ アプリ側原因、通常無視

主要 Wait Event 完全リファレンス

DB CPU（イベントではない、CPU 使用時間）:

Top = CPU バウンド
対処: SQL チューニング、CPU 追加

db file sequential read（単一ブロック読み取り）:

主にインデックススキャン
Avg Wait > 10ms = ディスク遅い
対処: SGA 増、SSD、SQL 見直し

db file scattered read（マルチブロック読み取り）:

主にフルテーブルスキャン
存在自体は正常（DWH）
OLTP で多いなら Index 不足の可能性

log file sync（COMMIT 待機）:

Avg Wait > 5ms = 警告
Avg Wait > 20ms = 深刻
対処: バッチ COMMIT、REDO 高速化

buffer busy waits（Hot Block 競合）:

複数セッションが同ブロックに集中
対処: 
- INSERT 集中 → ASSM/シーケンス CACHE 増
- INDEX 集中 → Reverse Key Index
- UPDATE 集中 → 分散

enq: TX – row lock contention（行ロック待ち）:

アプリの排他制御問題
対処: トランザクション設計見直し

enq: TX – allocate ITL entry（ITL 不足）:

対処: INITRANS 増加、PCTFREE 増加

library cache: mutex X（Hard Parse 集中）:

Bind 変数未使用が疑い
対処: CURSOR_SHARING、アプリ修正

latch: shared pool（Shared Pool ラッチ待ち）:

Hard Parse 多い
対処: Shared Pool 増、Bind 使用

cursor: pin S wait on X（Mutex 待機）:

特定 SQL の集中実行
対処: SQL 分散、キャッシュ

gc buffer busy acquire/release（RAC 特有）:

インターコネクト経由のブロック待機
対処: パーティション、Service 分離

セクション5: Time Model Statistics

例

Time Model Statistics                             DB/Inst: ORCL/orcl
                                          Time (sec)   % of DB Time
-----------------------------------------------------------------
sql execute elapsed time                     8,500        97.5
DB CPU                                       5,830        66.9
parse time elapsed                             250         2.9
hard parse elapsed time                         80         0.9

主要指標

sql execute elapsed time:

= 実 SQL 実行時間
DB Time の大半を占めるのが健全

DB CPU:

= 実 CPU 使用時間

parse time elapsed:

= パース時間
DB Time の 10% 超は要注意

hard parse elapsed time:

= Hard Parse 時間
DB Time の 5% 超は要注意

セクション6: Operating System Statistics

例

Operating System Statistics                       DB/Inst: ORCL/orcl
                                    Value            Value
Statistic Name                       Start              End
--------------------------- ------------ ----------------
NUM_CPUS                              16               16
BUSY_TIME                     58,340,000      145,200,000
IDLE_TIME                    319,050,000      288,300,000
USER_TIME                     53,850,000      132,100,000
SYS_TIME                       4,490,000       13,100,000
LOAD                                2.5              8.7
PHYSICAL_MEMORY_BYTES     68,719,476,736   68,719,476,736

主要指標

NUM_CPUS: CPU 数（AAS と比較）。

LOAD: OS のロード平均。CPU 数と比較。

BUSY_TIME / IDLE_TIME: OS CPU 使用率。

USER_TIME / SYS_TIME: ユーザー空間 vs システム空間。

セクション7: SQL Statistics（Top SQL）

SQL ordered by Elapsed Time

SQL ordered by Elapsed Time                       DB/Inst: ORCL/orcl
Elapsed          Elapsed Time
Time (s)  Executions  per Exec (s)  %Total  SQL Id
-------- ----------- -------------- ------ -------------
5,432.10          1        5,432.10   62.1  1abc23def4
1,250.00      2,500            0.50   14.3  9xyz45abc6
  830.20     10,000            0.08    9.5  2mno67pqr8

読み方

Elapsed Time (s): 合計実行時間。

Executions: 実行回数。

Elapsed per Exec (s): 1 回あたり時間。

高い → 1 回が重い（フルスキャン、Sort 多い）
低い → 1 回は速いが実行多すぎ

%Total: DB Time に対する割合。

分析パターン

パターン1: 1 回が重い SQL:

Elapsed: 5,432 s
Exec:    1
per Exec: 5,432 s

→ 実行計画確認、インデックス、パラレル化検討

パターン2: 高頻度実行 SQL:

Elapsed: 830 s
Exec:    10,000
per Exec: 0.083 s

→ アプリ側でキャッシュ、集約、頻度削減

他の SQL Statistics

SQL ordered by CPU Time: CPU 集中 SQL。

SQL ordered by User I/O Wait Time: I/O 集中 SQL。

SQL ordered by Gets: 論理読み取り集中。

SQL ordered by Reads: 物理読み取り集中。

SQL ordered by Parse Calls: パース集中（Bind 問題）。

SQL ordered by Executions: 実行頻度 Top。

セクション8: Wait Events（詳細）

例

Wait Events                                       DB/Inst: ORCL/orcl
                                  Total       Wait   %DB
Event                       Waits Time(s) Avg Wait  Time  Wait Class
-------------------------- ------ ------- --------- ---- ----------
db file sequential read  1250000    2500  2.00 ms   28.7 User I/O
log file sync              50000     250  5.00 ms    2.9 Commit
db file scattered read      3000     150 50.00 ms    1.7 User I/O
...

Foreground vs Background

Foreground Events: ユーザーセッションの待機。

Background Events: DBWR/LGWR 等のバックグラウンド待機。

Foreground Wait Class: クラス別集計。

セクション9: Advisor Statistics

Buffer Pool Advisory

Buffer Pool Advisory                              DB/Inst: ORCL/orcl
Size for  Buffer for   Est Phys  Est Phys
Estimate  Estimate     Read      Read Time
--------  ---------    --------  ---------
    500     0.5      2,500,000    500
   1000     1.0      1,200,000    240
   2000     2.0        600,000    120  ← 現行
   4000     4.0        400,000     80  ← 増やすと改善
   8000     8.0        380,000     76  ← 効果薄い

読み方: 現行より大きくしてEst Phys Read が大幅減少するなら SGA 増加検討。

Shared Pool Advisory

Library Cache Hit の改善予測。

PGA Aggregate Target Advisory

Sort/Hash に必要な PGA 見積もり。

ADDM（Automatic Database Diagnostic Monitor）

概要

AWR データから自動分析:

-- 実行
@$ORACLE_HOME/rdbms/admin/addmrpt.sql

-- または
SELECT DBMS_ADDM.GET_REPORT(:tid) FROM dual;

出力例

FINDING 1: 65% impact (5000 seconds)
-----------------------------------
SQL statements consuming significant database time were found.

   RECOMMENDATION 1: SQL Tuning, 65% benefit (5000 seconds)
      ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
              "1abc23def4".

ADDM が推奨する対策を実施。

ASH（Active Session History）

AWR との違い

AWR: 集約統計、1 時間ごと
ASH: セッション詳細、1 秒ごとサンプリング

ASH Report 生成

$ @$ORACLE_HOME/rdbms/admin/ashrpt.sql

Enter value for report_type: html
Enter value for begin_time: -30    -- 30 分前から
Enter value for duration: 30       -- 30 分間

ASH の見所

Top User Events         - ユーザーセッションの Top Event
Top Background Events   - バックグラウンド Top
Top Sessions           - Top セッション
Top Blocking Sessions  - ロックの首謀者
Top DB Objects         - 対象オブジェクト
Top SQL Statement      - 上位 SQL
Activity Over Time     - 時系列変化

特定時点の分析

AWR は 1 時間平均、ASH は瞬間的な問題を捉える。

AWR Compare Report（awrddrpt.sql）

用途

問題時と正常時の 2 つの AWR を比較:

$ @$ORACLE_HOME/rdbms/admin/awrddrpt.sql

# 正常時
Enter value for begin_snap: 100
Enter value for end_snap: 101

# 問題時
Enter value for begin_snap2: 200
Enter value for end_snap2: 201

出力

                                First    Second
Load Profile                    Period    Period   %Diff
------------------------ ---------- ---------- -------
DB Time (s):                    145      1250    +762%
DB CPU (s):                      98       450    +359%
Logical reads/sec:           35,240    52,300     +48%
Hard parses/sec:               0.25    148.30 +59200%  ← 犯人!

変化が大きい指標が問題の原因。

AWR SQL Report（awrsqrpt.sql）

用途

特定 SQL の履歴分析:

$ @$ORACLE_HOME/rdbms/admin/awrsqrpt.sql

Enter value for sql_id: 1abc23def4

出力

SQL Text
--------
SELECT ... FROM ...

Elapsed Time (s):     5,432
CPU Time (s):         3,200
Executions:               1
Buffer Gets:      1,500,000
Disk Reads:          85,000

Execution Plan
--------------
FULL TABLE SCAN of ORDERS  ← ここで遅い!

特定 SQL の実行計画・統計を確認。

Autonomous DB / OCI Performance Hub

Autonomous DB

Autonomous DB では:
- AWR / ASH / ADDM 有効（含まれる）
- OCI Console から確認
- Performance Hub で GUI 分析
- SQL Monitor 統合

OCI Performance Hub

機能:
- Real-Time モニター
- ASH Analytics
- SQL Monitor
- ADDM Reports
- AWR Reports
- Blocking Sessions

従来 sqlplus でも可能

Autonomous DB でも awrrpt.sql 実行可能:

sqlplus admin/pw@adb_high
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql

実践シナリオ

シナリオ1：緊急対応の読み方

アプリユーザー: 「10:00-11:00 が異常に遅かった」

1. AWR 生成
   $ @awrrpt.sql
   Snap 100 (10:00) - 101 (11:00)

2. 正常時の AWR も生成
   Snap 90 (前日 10:00) - 91 (前日 11:00)

3. awrddrpt.sql で比較
   → Hard parses/sec が 100 倍
   → library cache: mutex X が Top

4. Top SQL 確認
   → Bind 使ってない SQL 特定

5. アプリ側で Bind 使用に修正

シナリオ2：Top 10 Events からの分岐

Case A: db file sequential read が Top
   → I/O 問題
   → Top SQL (Reads) 確認
   → 実行計画・インデックス見直し

Case B: log file sync が Top
   → COMMIT 集中
   → バッチ COMMIT に変更
   → REDO ログ SSD 化

Case C: buffer busy waits が Top
   → Hot Block
   → INSERT/UPDATE パターン確認
   → 分散策検討

Case D: enq: TX - row lock contention
   → 排他制御問題
   → アプリロジック見直し
   → SELECT FOR UPDATE 適切化

Case E: DB CPU が Top で AAS 高
   → CPU バウンド
   → Top SQL (CPU) チューニング
   → CPU 追加検討

シナリオ3：Load Profile 比較

【正常時】
DB Time(s)/s:     2.42
Logical reads/s:  35,240
Hard parses/s:    0.25
Executions/s:     890

【問題時】
DB Time(s)/s:    12.50  ← 5 倍
Logical reads/s: 350,000 ← 10 倍
Hard parses/s:   0.30
Executions/s:    850

→ Logical reads 激増、Hard parse 変化なし
→ 特定の重い SQL が実行された可能性
→ SQL ordered by Gets を確認

シナリオ4：Top SQL 分析

SQL ordered by Elapsed Time で:

Rank 1:
Elapsed: 8,000 s
Executions: 1
Per Exec: 8,000 s

→ 1 回だけの巨大 SQL
→ awrsqrpt.sql で詳細確認
→ 実行計画で FULL SCAN 発見
→ インデックス追加 or ヒント

Rank 2:
Elapsed: 3,500 s
Executions: 100,000
Per Exec: 0.035 s

→ 高頻度 SQL
→ 個々は速いが多すぎ
→ アプリでキャッシュ・集約

シナリオ5：Instance Efficiency から

Buffer Hit %: 78%    ← 低い!
Library Hit %: 99.5%
Soft Parse %: 99.2%
Latch Hit %: 99.9%

→ SGA 不足の疑い
→ Buffer Pool Advisory 確認
→ SGA_TARGET 増加検討

シナリオ6：Rails アプリ監視統合

class AwrMonitor
  def self.check_hard_parses(window_hours: 1)
    result = ActiveRecord::Base.connection.select_one(<<-SQL)
      SELECT SUM(value) AS hard_parses
      FROM dba_hist_sysstat s
      JOIN dba_hist_snapshot sn ON sn.snap_id = s.snap_id
      WHERE stat_name = 'parse count (hard)'
        AND sn.begin_interval_time > SYSDATE - #{window_hours}/24
    SQL
    result['hard_parses'].to_i
  end
end

Rails 8 系の詳細は Rails 8 アップグレードガイドの記事も参照してください。

シナリオ7：Python での自動レポート生成

import oracledb
from datetime import datetime, timedelta

def generate_awr_report(conn, hours_ago=1):
    cursor = conn.cursor()
    
    # 最新 Snapshot ID 取得
    cursor.execute("""
        SELECT snap_id FROM dba_hist_snapshot
        ORDER BY snap_id DESC FETCH FIRST 2 ROWS ONLY
    """)
    snaps = [row[0] for row in cursor.fetchall()]
    end_snap, begin_snap = snaps[0], snaps[1]
    
    # AWR HTML 生成
    cursor.execute("""
        SELECT DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(
          l_dbid    => (SELECT dbid FROM v$database),
          l_inst_num => (SELECT instance_number FROM v$instance),
          l_bid     => :1,
          l_eid     => :2
        ) FROM dual
    """, [begin_snap, end_snap])
    
    report = cursor.fetchone()[0].read()
    
    filename = f"awr_{begin_snap}_{end_snap}.html"
    with open(filename, 'w') as f:
        f.write(report)
    return filename

シナリオ8：Docker Oracle でのテスト

docker exec -it oracle-xe sqlplus / as sysdba <<EOF
-- 手動 Snapshot
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

-- 負荷生成
BEGIN
  FOR i IN 1..10000 LOOP
    EXECUTE IMMEDIATE 'SELECT COUNT(*) FROM dba_objects' INTO :n;
  END LOOP;
END;
/

-- 再度 Snapshot
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

-- レポート生成
@?/rdbms/admin/awrrpt.sql
EOF

Docker 関連は docker daemon 接続エラーの記事、Docker no space left on device の記事も参照してください。

シナリオ9：CI/CD 統合

- name: Compare pre/post deploy AWR
  run: |
    sqlplus -s $DB_USER/$DB_PW <<EOF
    -- Deploy 前
    EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
    EOF
    
    # Deploy
    ./deploy.sh
    
    # 負荷テスト
    ./load_test.sh
    
    # Deploy 後
    sqlplus -s $DB_USER/$DB_PW <<EOF
    EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
    
    -- 比較レポート
    @?/rdbms/admin/awrddrpt.sql
    EOF

Kamal 2 デプロイの詳細は Kamal 2 デプロイの記事を参照してください。

シナリオ10：Autonomous DB での分析

1. OCI Console → Database → Performance Hub
2. Real-Time View
3. Historical View（AWR ベース）
4. SQL 詳細
5. ASH Analytics
6. AWR Report Download

トラブルシューティング

AWR 生成でエラー

Diagnostic Pack ライセンス確認、または Statspack 使用。

スナップショット取得失敗

MMON プロセス確認:

SELECT * FROM v$process WHERE program LIKE '%MMON%';

期間指定間違い

snap_id 一覧確認:

SELECT snap_id, begin_interval_time FROM dba_hist_snapshot
ORDER BY snap_id DESC FETCH FIRST 20 ROWS ONLY;

レポートサイズが大きい

Text 形式は小さい、HTML はグラフィカル。

分析ポイント不明

ADDM 実行、自動診断参照。

PostgreSQL からの移行

PG は pg_stat_statements + auto_explain、Oracle AWR は統合的で優秀。

よくある質問（FAQ）

Q1. AWR と Statspack

• AWR: 有償ライセンス、機能豊富
• Statspack: 無償、機能限定

Q2. スナップショット間隔

60 分デフォルト、変更可（30 分推奨する意見も）。

Q3. リテンション

8 日デフォルト、14 日〜30 日推奨。

Q4. Top 10 Events から何を見るか

上位 3 つに集中、DB CPU 以外を優先チェック。

Q5. DB Time > Elapsed Time

Multi-CPU 並列稼働の証拠、正常。

Q6. Load Profile 比較

正常時と問題時を比較、差分を発見。

Q7. ADDM 使うか

必ず参照、自動診断で見落とし防止。

Q8. ASH との使い分け

• AWR: 全体傾向
• ASH: 瞬間的な詳細

Q9. Autonomous DB

Performance Hub で GUI 分析、AWR も従来通り。

Q10. 予防的分析

定期的に AWR 確認、ベースライン確立。

Q11. Rails/Java/Python 統合

DBMS_WORKLOAD_REPOSITORY で自動生成、監視統合。

Q12. Buffer Hit % の目標

95%+ 推奨、ただし他指標と組み合わせ判断。

参考リンク

Oracle 公式

• Oracle Database Performance Tuning Guide: Automatic Workload Repository
• Oracle Database PL/SQL Packages: DBMS_WORKLOAD_REPOSITORY
• Oracle Database Reference: AWR Views
• OCI Performance Hub

まとめ

Oracle AWR レポートの読み方の要点を再整理します。

AWR の本質

自動収集される時系列パフォーマンス統計
- 60 分ごとのスナップショット
- 8 日間リテンション（デフォルト）
- 全体傾向分析、時系列比較
- Diagnostic Pack 必須

3 分で読む順序

1. Report Summary → DB Time / AAS
2. Load Profile → ワークロード
3. Top 10 Events → ボトルネック
4. Top SQL → 問題 SQL 特定

9 大セクション

主要 Wait Event

推奨閾値

AWR 関連ツール

awrrpt.sql:    通常 AWR レポート
awrddrpt.sql:  2 期間比較（超便利）
awrsqrpt.sql:  特定 SQL 詳細
ashrpt.sql:    ASH レポート
addmrpt.sql:   ADDM レポート
awrgrpt.sql:   RAC 全インスタンス
awrrpti.sql:   特定インスタンス

実務チェックリスト

□ Diagnostic Pack ライセンス確認
□ Retention 14+ 日推奨
□ 正常時ベースライン取得
□ 問題発生時と正常時比較
□ Load Profile 差分確認
□ Top 10 Events で症状特定
□ Top SQL で原因 SQL 特定
□ ADDM で自動診断参照
□ ASH で瞬間的詳細分析
□ Compare Report で差異分析
□ OCI Performance Hub 活用
□ Rails/Java/Python 監視統合

これらの知識は、Oracle DBA のパフォーマンスチューニング・本番運用・障害対応・キャパシティプランニング・Rails/Java/Python アプリ運用・Autonomous DB 運用・CI/CD パイプライン・SLA 管理・監視設計など、あらゆる場面で活用できます。本記事をブックマークしておけば、Oracle AWR レポートをプロフェッショナルとして読み解き、パフォーマンス問題を的確に解決できるようになります。

本記事は2026年6月時点の情報をもとに、Oracle Database 19c〜23ai での動作確認・公式ドキュメントに基づき作成しています。Oracle のバージョンにより挙動が異なる場合があるため、最新の情報は Oracle 公式ドキュメント（docs.oracle.com）もあわせてご確認ください。