1. AWR报告基础数据库性能分析的瑞士军刀第一次接触AWR报告时我正面临一个棘手的生产问题——某电商系统在促销期间频繁出现数据库响应迟缓。当时手动检查了上百个参数都找不到症结直到一位资深DBA扔给我一份AWR报告说看这个比瞎猜管用。这份自动生成的报告不仅准确指出了I/O瓶颈所在还给出了具体的SQL优化建议让我真正见识到了Oracle这个内置工具的威力。AWRAutomatic Workload Repository就像数据库的黑匣子它会每小时自动拍摄一次系统快照默认间隔记录下包括CPU使用率、内存分配、SQL执行计划等600项性能指标。这些数据保存在SYSAUX表空间中默认保留8天相当于给数据库装了个全天候的监控摄像头。与老旧的Statspack相比AWR的三大优势特别明显自动化程度高不需要手动设置采样后台MMON进程自动完成数据收集指标维度丰富从系统资源到SQL细节形成完整监控链条诊断建议智能ADDM能基于AWR数据给出优化方案在最近的一次银行系统调优中我们通过对比业务高峰和低谷时段的AWR报告发现了一个隐藏的日志归档竞争问题。这种跨时间段的对比分析正是AWR最擅长的场景。2. 报告生成全流程从快照配置到报告导出2.1 快照策略优化实战默认的1小时采样间隔对于问题诊断往往不够用。上周处理的一个物流系统突发性能下降案例中我们临时将采样间隔调整为15分钟成功捕捉到了瞬时的锁冲突事件。调整方法很简单-- 将采样间隔改为30分钟保留10天数据 BEGIN DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( interval 30, retention 10*24*60); END; / -- 手动创建快照紧急情况使用 EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();这里有个实际经验对于核心业务系统我建议保留至少14天数据因为很多性能问题具有周期性比如周报生成时的资源紧张。而采样间隔在非特殊时期保持默认即可过于频繁会影响系统性能。2.2 生成报告的三种姿势最经典的生成方式是通过SQL*Plus运行脚本sqlplus / as sysdba ?/rdbms/admin/awrrpt.sql执行后会提示选择报告格式HTML可读性更好快照天数范围具体的起止快照ID但实际工作中我更推荐另外两种方式OEM图形化操作在性能页签直接点击生成适合新手PL/SQL API调用适合需要批量生成的情况-- 使用API生成最近1小时的HTML报告 BEGIN DBMS_WORKLOAD_REPOSITORY.awr_report_html( dbid NULL, inst_num NULL, bid (SELECT max(snap_id)-1 FROM dba_hist_snapshot), eid (SELECT max(snap_id) FROM dba_hist_snapshot), options 0); END; /生成后的报告默认保存在执行目录我曾遇到过因为目录权限导致报告生成失败的情况这时可以指定可写目录-- 指定输出到/tmp目录 SPOOL /tmp/awr_report.html ?/rdbms/admin/awrrpt.sql SPOOL OFF3. 核心指标深度解析从DB Time到等待事件3.1 DB Time数据库忙不忙的体温计DB Time DB CPU Time 非空闲等待时间这个指标相当于数据库的工作总时长。举个例子1小时Elapsed Time内DB Time为2小时服务器有4个CPU核心相当于平均每个核心工作了30分钟2h/4这说明数据库处于轻度负载。如果DB Time达到4小时就意味着所有CPU都在满负荷工作。去年双11大促前我们通过持续监控DB Time预测出数据库容量瓶颈提前完成了扩容。报告中的Load Profile区域需要特别关注这些指标Logical Reads逻辑读过高可能引起latch争用Hard Parses硬解析超过20次/秒就需要优化Physical Reads物理读直接反映I/O压力3.2 等待事件性能瓶颈的报警灯Top 5 Timed Events是报告中最关键的部分它像医院的化验单一样直指问题核心。常见的重要事件包括等待事件典型原因解决方案db file sequential read索引扫描过多优化SQL增加内存log file sync提交频繁批量提交调整日志缓冲区latch: cache buffers热点块争用使用绑定变量优化SQL最近处理的一个案例中某ERP系统出现enq: TX - row lock contention等待通过AWR定位到是某个批量更新程序未使用适当的事务隔离级别调整后性能提升80%。3.3 内存效率命中率背后的故事Instance Efficiency Percentages中的指标就像汽车的仪表盘- **Buffer Hit Ratio**建议95%低于90%需扩大SGA - **Library Hit Ratio**反映SQL重用率90%说明共享池有问题 - **Soft Parse Ratio**软解析比例OLTP系统应95%有个容易误解的点不是所有命中率都越高越好。比如一个全表扫描为主的DSS系统Buffer Hit Ratio低是正常的强行提高反而会浪费内存。4. 高级技巧对比报告与SQL优化4.1 AWR对比报告实战当性能出现波动时对比两个时段的AWR报告比单看一份更有价值。生成命令?/rdbms/admin/awrddrpt.sql上个月某证券系统升级后出现性能下降我们通过对比升级前后的AWR报告发现新版本中某个统计信息收集任务执行时间增长了3倍最终定位到是采样率设置过高导致。4.2 SQL优化黄金数据报告的SQL Statistics部分藏着金矿SQL ordered by Elapsed Time找出耗时最长的SQLSQL ordered by CPU Time识别CPU消耗大户SQL ordered by Gets定位高逻辑读语句有个实际技巧结合执行计划变化分析SQL性能退化。某次我们发现一个关键查询变慢通过对比不同时段的AWR发现是由于索引失效导致执行计划改变。5. 常见问题排查手册场景1系统突然变慢检查Top 5等待事件查看CPU使用率是否饱和分析是否有新的高负载SQL出现场景2内存不足告警检查Buffer Hit Ratio查看PGA内存使用情况确认是否有内存泄漏场景3I/O瓶颈查看Physical Reads指标检查I/O相关的等待事件确认存储性能是否达标曾经处理过的一个典型案例某系统每天上午10点准时变慢。通过分析多个日期的AWR报告发现是定时统计任务与业务高峰重叠导致调整调度时间后问题解决。对于RAC环境要特别关注Global Cache相关的等待事件比如gc cr block busy可能意味着跨节点数据访问竞争。去年某次RAC性能优化中我们通过调整服务分配将这类等待降低了70%。
Oracle AWR报告实战：从生成到关键指标深度解析
发布时间：2026/5/21 20:57:47
1. AWR报告基础数据库性能分析的瑞士军刀第一次接触AWR报告时我正面临一个棘手的生产问题——某电商系统在促销期间频繁出现数据库响应迟缓。当时手动检查了上百个参数都找不到症结直到一位资深DBA扔给我一份AWR报告说看这个比瞎猜管用。这份自动生成的报告不仅准确指出了I/O瓶颈所在还给出了具体的SQL优化建议让我真正见识到了Oracle这个内置工具的威力。AWRAutomatic Workload Repository就像数据库的黑匣子它会每小时自动拍摄一次系统快照默认间隔记录下包括CPU使用率、内存分配、SQL执行计划等600项性能指标。这些数据保存在SYSAUX表空间中默认保留8天相当于给数据库装了个全天候的监控摄像头。与老旧的Statspack相比AWR的三大优势特别明显自动化程度高不需要手动设置采样后台MMON进程自动完成数据收集指标维度丰富从系统资源到SQL细节形成完整监控链条诊断建议智能ADDM能基于AWR数据给出优化方案在最近的一次银行系统调优中我们通过对比业务高峰和低谷时段的AWR报告发现了一个隐藏的日志归档竞争问题。这种跨时间段的对比分析正是AWR最擅长的场景。2. 报告生成全流程从快照配置到报告导出2.1 快照策略优化实战默认的1小时采样间隔对于问题诊断往往不够用。上周处理的一个物流系统突发性能下降案例中我们临时将采样间隔调整为15分钟成功捕捉到了瞬时的锁冲突事件。调整方法很简单-- 将采样间隔改为30分钟保留10天数据 BEGIN DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( interval 30, retention 10*24*60); END; / -- 手动创建快照紧急情况使用 EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();这里有个实际经验对于核心业务系统我建议保留至少14天数据因为很多性能问题具有周期性比如周报生成时的资源紧张。而采样间隔在非特殊时期保持默认即可过于频繁会影响系统性能。2.2 生成报告的三种姿势最经典的生成方式是通过SQL*Plus运行脚本sqlplus / as sysdba ?/rdbms/admin/awrrpt.sql执行后会提示选择报告格式HTML可读性更好快照天数范围具体的起止快照ID但实际工作中我更推荐另外两种方式OEM图形化操作在性能页签直接点击生成适合新手PL/SQL API调用适合需要批量生成的情况-- 使用API生成最近1小时的HTML报告 BEGIN DBMS_WORKLOAD_REPOSITORY.awr_report_html( dbid NULL, inst_num NULL, bid (SELECT max(snap_id)-1 FROM dba_hist_snapshot), eid (SELECT max(snap_id) FROM dba_hist_snapshot), options 0); END; /生成后的报告默认保存在执行目录我曾遇到过因为目录权限导致报告生成失败的情况这时可以指定可写目录-- 指定输出到/tmp目录 SPOOL /tmp/awr_report.html ?/rdbms/admin/awrrpt.sql SPOOL OFF3. 核心指标深度解析从DB Time到等待事件3.1 DB Time数据库忙不忙的体温计DB Time DB CPU Time 非空闲等待时间这个指标相当于数据库的工作总时长。举个例子1小时Elapsed Time内DB Time为2小时服务器有4个CPU核心相当于平均每个核心工作了30分钟2h/4这说明数据库处于轻度负载。如果DB Time达到4小时就意味着所有CPU都在满负荷工作。去年双11大促前我们通过持续监控DB Time预测出数据库容量瓶颈提前完成了扩容。报告中的Load Profile区域需要特别关注这些指标Logical Reads逻辑读过高可能引起latch争用Hard Parses硬解析超过20次/秒就需要优化Physical Reads物理读直接反映I/O压力3.2 等待事件性能瓶颈的报警灯Top 5 Timed Events是报告中最关键的部分它像医院的化验单一样直指问题核心。常见的重要事件包括等待事件典型原因解决方案db file sequential read索引扫描过多优化SQL增加内存log file sync提交频繁批量提交调整日志缓冲区latch: cache buffers热点块争用使用绑定变量优化SQL最近处理的一个案例中某ERP系统出现enq: TX - row lock contention等待通过AWR定位到是某个批量更新程序未使用适当的事务隔离级别调整后性能提升80%。3.3 内存效率命中率背后的故事Instance Efficiency Percentages中的指标就像汽车的仪表盘- **Buffer Hit Ratio**建议95%低于90%需扩大SGA - **Library Hit Ratio**反映SQL重用率90%说明共享池有问题 - **Soft Parse Ratio**软解析比例OLTP系统应95%有个容易误解的点不是所有命中率都越高越好。比如一个全表扫描为主的DSS系统Buffer Hit Ratio低是正常的强行提高反而会浪费内存。4. 高级技巧对比报告与SQL优化4.1 AWR对比报告实战当性能出现波动时对比两个时段的AWR报告比单看一份更有价值。生成命令?/rdbms/admin/awrddrpt.sql上个月某证券系统升级后出现性能下降我们通过对比升级前后的AWR报告发现新版本中某个统计信息收集任务执行时间增长了3倍最终定位到是采样率设置过高导致。4.2 SQL优化黄金数据报告的SQL Statistics部分藏着金矿SQL ordered by Elapsed Time找出耗时最长的SQLSQL ordered by CPU Time识别CPU消耗大户SQL ordered by Gets定位高逻辑读语句有个实际技巧结合执行计划变化分析SQL性能退化。某次我们发现一个关键查询变慢通过对比不同时段的AWR发现是由于索引失效导致执行计划改变。5. 常见问题排查手册场景1系统突然变慢检查Top 5等待事件查看CPU使用率是否饱和分析是否有新的高负载SQL出现场景2内存不足告警检查Buffer Hit Ratio查看PGA内存使用情况确认是否有内存泄漏场景3I/O瓶颈查看Physical Reads指标检查I/O相关的等待事件确认存储性能是否达标曾经处理过的一个典型案例某系统每天上午10点准时变慢。通过分析多个日期的AWR报告发现是定时统计任务与业务高峰重叠导致调整调度时间后问题解决。对于RAC环境要特别关注Global Cache相关的等待事件比如gc cr block busy可能意味着跨节点数据访问竞争。去年某次RAC性能优化中我们通过调整服务分配将这类等待降低了70%。
