1. AWR性能报告核心价值解析
在Oracle数据库性能调优领域，AWR（Automatic Workload Repository）报告就像数据库的"黑匣子"，每30分钟自动记录一次系统快照。我处理过上百个性能案例，90%的严重性能问题通过AWR报告都能快速定位到根源。这份报告不仅包含SQL执行统计、等待事件、系统负载等关键指标，还能通过时间维度对比发现性能退化趋势。
关键提示：AWR默认保留8天数据，紧急情况下务必在问题发生后第一时间保存快照，避免关键数据被自动清理。
2. AWR报告生成实战指南
2.1 基础生成方法
最常用的生成命令是通过SQL*Plus执行：
-- 生成HTML格式报告 @?/rdbms/admin/awrrpt.sql -- 生成文本格式报告（适合批量分析） @?/rdbms/admin/awrrpti.sql执行后会交互式提示：
- 选择报告格式（HTML/TEXT）
- 输入快照天数范围（默认1天）
- 选择开始和结束的快照ID
我习惯用HTML格式报告，因为其包含可交互的图表和排序功能。当需要分析历史问题时，会先用以下查询确定可用快照范围：
SELECT snap_id, begin_interval_time FROM dba_hist_snapshot ORDER BY snap_id DESC;2.2 高级生成技巧
场景1：对比不同时段性能
@?/rdbms/admin/awrddrpt.sql这个对比报告能直观显示指标变化，比如某SQL执行时间从2秒暴涨到2分钟，报告会用红色高亮显示差异。
场景2：RAC环境全局报告
@?/rdbms/admin/awrgrpt.sql对于RAC集群，这个报告会聚合所有节点的数据，避免逐个节点分析的麻烦。
3. AWR报告核心模块精读
3.1 负载概览（Load Profile）
这个模块我首先会看以下指标：
- DB CPU vs Wait Time：CPU时间占比过高可能说明需要优化SQL逻辑
- Logical Reads/Executes：异常高的逻辑读往往指向缺失索引
- Hard Parses/sec：硬解析率>100次/秒需要检查绑定变量使用
典型问题案例：某系统每秒硬解析达到300次，通过AWR发现是某报表工具动态拼接SQL导致，引入绑定变量后性能提升40倍。
3.2 等待事件分析（Top 5 Timed Events）
这里揭示系统真正的瓶颈：
- db file sequential read：通常表示全表扫描或索引效率低
- log file sync：可能事务提交太频繁
- enq: TX - row lock contention：明确的行锁争用
经验法则：单个等待事件占比超过30%就需要重点优化
4. SQL性能分析实战
4.1 识别问题SQL
AWR会按以下维度排序SQL：
- 执行时间最长（Elapsed Time）
- CPU消耗最多（CPU Time）
- 逻辑读最多（Buffer Gets）
- 物理读最多（Disk Reads）
我通常会交叉查看这几个榜单，比如某SQL虽然执行时间不是最长，但单次逻辑读异常高（>100万），这就是优化重点。
4.2 SQL优化案例
曾遇到一个每秒执行200次的SQL，AWR显示其平均执行时间1.5秒：
SELECT * FROM orders WHERE status='PENDING' AND create_date>SYSDATE-30;通过AWR发现：
- 该SQL占系统总逻辑读的65%
- 执行计划是全表扫描
- 没有合适的复合索引
解决方案：
CREATE INDEX idx_orders_status_date ON orders(status, create_date);优化后执行时间降至0.02秒，系统整体吞吐量提升3倍。
5. 高级分析技巧
5.1 基线对比分析
创建性能基线：
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE( start_snap_id => 1000, end_snap_id => 1001, baseline_name => 'Normal_Workload');对比当前性能与基线：
@?/rdbms/admin/awrddrpt.sql输入基线快照和当前快照范围，报告会自动标注偏离基线的异常指标。
5.2 自定义指标监控
通过DBMS_WORKLOAD_REPOSITORY包可以扩展监控：
-- 添加自定义统计项 BEGIN DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 21600, -- 延长保留时间（分钟） interval => 15); -- 缩短快照间隔 END;6. 常见问题排查指南
问题1：AWR报告没有数据
- 检查STATISTICS_LEVEL参数是否为TYPICAL/ALL
- 确认SYSAUX表空间有足够空间
- 验证AWR快照是否正常生成：
SELECT * FROM dba_hist_wr_control;
问题2：关键SQL不在Top SQL中
- 调整AWR收集阈值：
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( topnsql => 'MAXIMUM'); - 使用SQL_ID直接查询：
@?/rdbms/admin/awrsqrpt.sql
问题3：快照间隔太长错过瞬时问题
- 临时调整快照频率：
BEGIN DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( interval => 5); -- 5分钟一次 END; - 问题解决后记得恢复默认设置（30分钟）
7. 性能优化实战心得
在分析AWR报告时，我总结出"三看原则"：
- 看趋势：对比历史同期数据，区分偶发问题与持续恶化
- 看比例：单个指标占总量的百分比比绝对值更重要
- 看关联：CPU高可能是由低效SQL引起，要关联分析
一个真实案例：某系统每周一上午响应变慢，通过对比AWR发现：
- 每周一9:00-10:00的"log file sync"等待激增
- 对应时间段的用户连接数增加50%
- 有3个批处理作业正好在该时段启动
最终方案：调整批处理作业执行时间，并优化事务提交频率，问题解决。
