数据库的体检报告：Oracle AWR报告深度解读与生成指南

一、开篇：AWR是DBA的“听诊器”

某天业务部门反馈数据库响应变慢，DBA登录后面对数百个性能指标，一时不知从何入手。<font color=#D32F2F>这时AWR报告就是最有力的诊断工具——它就像数据库的“体检报告”，记录了特定时间段内的所有关键性能指标，包括Top等待事件、负载画像、SQL统计、缓存命中率等。</font>

<font color=#1976D2>AWR（Automatic Workload Repository）是Oracle自动采集的性能数据仓库，默认每60分钟生成一次快照，保留8天。通过分析两个快照之间的性能差异，可以快速定位性能瓶颈。</font>

本篇文章从AWR报告的生成方法、报告结构、核心指标解读到实战分析，全面覆盖AWR报告的使用技巧，帮助你快速掌握这一DBA必备的诊断技能。

二、AWR报告生成方法

1. <font color=#1976D2>生成AWR报告的三种方式</font>

方式一：使用awrrpt.sql脚本（最常用）

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

-- 按提示输入：
-- 1. 报告类型：HTML或TEXT
-- 2. 开始快照ID
-- 3. 结束快照ID
-- 4. 报告名称

方式二：直接调用DBMS_WORKLOAD_REPOSITORY包

SELECT output FROM TABLE(DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_TEXT(
    l_dbid => 1234567890,
    l_inst_num => 1,
    l_bid => 100,
    l_eid => 101
));

方式三：使用Oracle Enterprise Manager（OEM）

• 登录OEM → 性能 → AWR → 生成报告

2. <font color=#F57C00>查看可用的AWR快照</font>

SELECT 
    snap_id,
    TO_CHAR(begin_interval_time, 'YYYY-MM-DD HH24:MI:SS') AS begin_time,
    TO_CHAR(end_interval_time, 'YYYY-MM-DD HH24:MI:SS') AS end_time,
    startup_time
FROM dba_hist_snapshots
WHERE begin_interval_time > SYSDATE - 7
ORDER BY snap_id;

3. <font color=#388E3C>AWR快照管理</font>

-- 查看快照保留策略
SELECT 
    retention/1440 AS retention_days,
    snap_interval/60 AS snap_interval_minutes
FROM dba_hist_wr_control;

-- 修改快照间隔（30分钟）和保留时间（14天）
BEGIN
    DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(
        retention => 20160,   -- 14天（分钟）
        interval => 30        -- 30分钟
    );
END;
/

-- 手动创建快照
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

三、AWR报告结构全景图

报告结构解读：

• <font color=#1976D2>蓝色（Load Profile）：</font> 系统负载画像，每秒/每事务的资源消耗。
• <font color=#388E3C>绿色（Instance Efficiency）：</font> 缓存命中率，判断内存配置是否合理。
• <font color=#D32F2F>红色（Top 5 Timed Events）：</font> 最关键的等待事件，性能瓶颈的第一入口。

四、AWR报告头部分析

1. <font color=#1976D2>数据库标识信息</font>

DB Name        DB Id    Instance  Inst#  Release  RAC  Host
------------ ---------- --------- ----- --------- ---  ------------
ORCL          1234567890 orcl      1      19.0.0.0 NO   prod-server

Snap Id      Snap Time        Sessions  Cursors/Session
------------ ---------------- --------  ---------------
Begin Snap:  100              10:00:00   85         3.2
End Snap:    101              11:00:00   120        4.1
Elapsed:                      60.02 mins
DB Time:                      240.50 mins

2. <font color=#D32F2F>DB Time：最重要的健康指标</font>

精确描述：

DB Time是数据库处理所有用户请求的总时间（包括CPU时间和等待时间）。<font color=#D32F2F>DB Time / Elapsed Time = 平均活跃会话数，如果超过CPU核心数，说明存在排队。</font>

DB Time = 240.50 mins
Elapsed = 60.02 mins
平均活跃会话数 = 240.50 / 60.02 ≈ 4.0

如果CPU核心数 = 8 → 4 < 8，系统健康
如果CPU核心数 = 2 → 4 > 2，存在严重CPU排队

五、Report Summary核心解读

1. <font color=#D32F2F>Top 5 Timed Events：性能瓶颈第一入口</font>

报告示例：

Top 5 Timed Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Event                          Waits    Time(s)  Avg Wait(ms)  %DB Time  Wait Class
------------------------------ -------- -------- ------------- --------- ----------
db file sequential read        1,234,567 8,500    6.9           58.5      User I/O
CPU time                                  3,200                 22.0
log file sync                   456,789   1,200    2.6           8.3       Commit
db file scattered read          23,456    800      34.1          5.5       User I/O
enq: TX - row lock contention   1,234     500      405.2         3.4       Application

关键等待事件解读：

| 等待事件 | Wait Class | 常见原因 | 优化方向 |

|----------|-----------|----------|----------|

| db file sequential read | User I/O | 索引读取 | 优化SQL、添加合适索引 |

| db file scattered read | User I/O | <font color=#D32F2F>全表扫描</font> | 优化SQL、添加索引 |

| log file sync | Commit | 提交时磁盘I/O慢 | 减少提交频率、使用SSD |

| enq: TX - contention | Application | 行级锁等待 | 优化事务逻辑 |

| latch: cache buffers chains | Concurrency | 热块争用 | 分区、反向键索引 |

| library cache: mutex X | Concurrency | 硬解析过多 | <font color=#388E3C>使用绑定变量</font> |

| free buffer waits | Configuration | Buffer Cache不足 | 增大DB_CACHE_SIZE |

2. <font color=#1976D2>Load Profile：系统负载画像</font>

报告示例：

Load Profile
~~~~~~~~~~~~
                          Per Second       Per Transaction
                          -----------      ----------------
DB Time(s):               4.0              0.012
CPU Time(s):              2.1              0.006
Redo size (bytes):        5,234,567        15,678
Logical reads (blocks):   125,678          376
Physical reads (blocks):  3,456            10
Physical writes (blocks): 1,234            4
Parses (SQL):             234              0.7
Hard parses (SQL):        150              0.45    ← 异常！
Executes (SQL):           567              1.7
Transactions:             334

关键指标解读：

| 指标 | 正常范围 | 需关注 | 严重问题 |

|------|----------|--------|----------|

| Hard parses/s | < 10 | 10~50 | <font color=#D32F2F>> 50</font> |

| Physical reads/s | 取决于存储 | 持续高于峰值 | <font color=#F57C00>磁盘瓶颈</font> |

| Redo size/s | 取决于业务 | > 50MB/s | <font color=#F57C00>日志压力大</font> |

| Logical reads/s | 取决于业务 | > 100000 | <font color=#F57C00>SQL效率低</font> |

3. <font color=#388E3C>Instance Efficiency：缓存命中率</font>

报告示例：

Instance Efficiency Percentages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %:      99.99    Redo NoWait %:      99.95
Buffer Hit %:         97.50    In-memory Sort %:   98.20
Library Hit %:        95.30    Soft Parse %:       94.80
Execute to Parse %:   85.60    Latch Hit %:        99.90

命中率诊断标准：

| 指标 | 理想值 | 如果偏低的原因 |

|------|--------|---------------|

| Buffer Hit % | <font color=#388E3C>> 95%</font> | Buffer Cache不足或SQL效率低 |

| Library Hit % | <font color=#388E3C>> 99%</font> | <font color=#D32F2F>硬解析过多或共享池不足</font> |

| In-memory Sort % | <font color=#388E3C>> 99%</font> | PGA不足，磁盘排序过多 |

| Soft Parse % | <font color=#388E3C>> 99%</font> | <font color=#D32F2F>未使用绑定变量</font> |

六、AWR报告SQL Statistics分析

1. <font color=#D32F2F>Top SQL by Elapsed Time</font>

报告示例：

SQL ordered by Elapsed Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Elapsed Time (s)  Executions  Elapsed per Exec(s)  %Total  %CPU  %IO   SQL Id
----------------  ----------  -------------------- ------- ----- ----- -------------
8,500             1,000       8.50                 35.2    22.0  78.0  a1b2c3d4
3,200             500         6.40                 13.3    45.0  55.0  e5f6g7h8

2. <font color=#F57C00>Top SQL by Buffer Gets</font>

SQL ordered by Gets
~~~~~~~~~~~~~~~~~~~~
Buffer Gets        Executions  Gets per Exec   %Total  CPU Time(s)  SQL Id
---------------    ----------  --------------  ------  -----------  --------
50,000,000         1,000       50,000          45.5    4,500        a1b2c3d4

<font color=#D32F2F>每次执行5万次逻辑读——SQL效率极低，需要优化执行计划。</font>

3. <font color=#388E3C>获取完整SQL文本</font>

SELECT sql_text FROM dba_hist_sqltext WHERE sql_id = 'a1b2c3d4';

七、AWR报告实战分析

<font color=#1976D2>案例一：CPU飙升问题诊断</font>

AWR报告关键发现：

DB Time: 480 mins / Elapsed: 60 mins = 8.0 (平均活跃会话)
CPU Time: 400 mins (占DB Time的83%)
Top Event: library cache: mutex X (35% DB Time)
Load Profile: Hard parses = 150/s  ← 异常！
Library Hit %: 82%  ← 严重偏低！

诊断结论： <font color=#D32F2F>硬解析过多导致CPU飙升。</font>

解决方案：

• 应用代码修改为使用绑定变量。
• 增大共享池。
• 紧急情况可设置cursor_sharing=FORCE。

<font color=#F57C00>案例二：I/O性能问题诊断</font>

AWR报告关键发现：

Top Event: db file sequential read (45% DB Time)
           db file scattered read (15% DB Time)
Physical reads: 50000/s  ← 异常！
Buffer Hit %: 85%  ← 偏低！

诊断结论： <font color=#F57C00>大量物理I/O，Buffer Cache不足或SQL效率低。</font>

解决方案：

• 优化Top SQL（添加索引、改写SQL）。
• 增大Buffer Cache。
• 使用Keep池缓存热点表。

八、总结：记住这个“体检报告”类比就够了

<font color=#1976D2>【AWR报告是数据库的体检报告】</font>

• DB Time： <font color=#D32F2F>体温——超过CPU核心数就是发烧。</font>
• Top 5等待事件： <font color=#F57C00>五大症状——咳嗽（I/O等待）、发烧（CPU高）、胸闷（锁等待）。</font>
• Load Profile： <font color=#1976D2>生活习惯调查——每天抽几包烟（Hard Parse频率）、运动量多少（Physical Read频率）。</font>
• Instance Efficiency： <font color=#388E3C>器官功能指标——肝功能（Buffer Hit）、肾功能（Library Hit）。</font>
• Top SQL： <font color=#D32F2F>病灶定位——哪个器官出了问题。</font>

<font color=#1976D2>AWR报告是DBA最常用的性能诊断工具。掌握AWR报告的生成方法和核心指标解读，就能在数据库出现问题时快速定位根因。记住：先看DB Time判断整体健康，再看Top 5等待事件找到问题方向，最后通过Top SQL和执行计划精确诊断。</font>

你在日常运维中最常使用的AWR报告指标是什么？是如何通过AWR报告定位性能问题的？欢迎评论区分享你的经验。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/qq_41840843/article/details/162816472