一、开篇：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 mins2. <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 e5f6g7h82. <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报告定位性能问题的？欢迎评论区分享你的经验。
