Oracle AWR报告生成与性能诊断实战指南

1. AWR报告的价值与生成逻辑

在Oracle数据库性能诊断领域，AWR（Automatic Workload Repository）报告堪称DBA的"CT扫描仪"。这份由Oracle自动生成的性能快照，记录了数据库在特定时间段内的完整运行状态。我处理过数百次性能问题，90%的案例通过AWR报告就能快速定位到症结所在。

AWR的核心价值在于其数据采集机制。Oracle会每小时自动拍摄一次数据库"快照"（Snapshot），持续记录包括等待事件、SQL执行统计、系统负载等150+项关键指标。当我们需要分析性能问题时，只需指定两个快照点，Oracle就会自动生成这两个时间点之间的差异化分析报告。

2. 快速生成AWR报告的标准流程

2.1 连接数据库的正确姿势

首先通过SQL*Plus连接到目标数据库实例。这里有个专业细节：必须用sysdba或具有DBA权限的用户登录。我见过太多人卡在这一步，错误提示"ORA-28547"往往就是权限不足导致的。

sql复制sqlplus / as sysdba
-- 或者
sqlplus sys/password@service_name as sysdba

2.2 确定快照时间范围

执行以下查询获取可用快照列表。注意观察SNAP_ID和对应的采集时间：

sql复制SELECT snap_id, begin_interval_time, end_interval_time
FROM dba_hist_snapshot
ORDER BY snap_id DESC;

2.3 调用报告生成脚本

Oracle提供了标准脚本awrrpt.sql，通常位于$ORACLE_HOME/rdbms/admin目录。执行时需注意：

1. 报告格式选择HTML（更直观）或TEXT
2. 输入起始和结束SNAP_ID
3. 指定报告输出文件名

bash复制@?/rdbms/admin/awrrpt.sql

3. 高级技巧与避坑指南

3.1 快照间隔调整策略

默认的60分钟快照间隔可能错过瞬时性能问题。对于关键业务系统，我建议通过以下命令调整：

sql复制BEGIN
  DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
    interval => 15,  -- 单位：分钟
    retention => 4320 -- 单位：分钟（3天）
  );
END;
/

3.2 手动创建快照的时机

在以下场景应立即手动创建快照：

• 性能问题复现时
• 执行重大变更前后
• 压力测试开始/结束时

sql复制EXEC DBMS_WORKLOAD_REPOSITORY.create_snapshot();

3.3 典型问题排查案例

问题现象：AWR报告生成失败，提示"ORA-20019: Invalid snapshot IDs"

排查步骤：

1. 确认输入的SNAP_ID确实存在
2. 检查DBA_HIST_SNAPSHOT视图是否有对应记录
3. 验证快照是否被手动清理

4. AWR报告核心指标解读

4.1 负载概览（Load Profile）

重点关注以下指标的突变：

• 每秒逻辑读（Logical Reads）
• 硬解析率（Hard Parses/sec）
• 物理读写（Physical Reads/Writes）

4.2 等待事件分析（Top 5 Timed Events）

这是性能问题的"风向标"。常见关键事件：

• db file sequential read：索引扫描等待
• log file sync：提交等待
• enq: TX - row lock contention：行锁争用

4.3 SQL语句分析

重点关注：

• 执行时间最长的SQL
• 逻辑读最高的SQL
• 执行计划突变的SQL

5. 自动化生成方案

对于需要定期收集的场景，可以创建自动化脚本：

bash复制#!/bin/bash
ORACLE_SID=orcl
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
OUTPUT_DIR=/awr_reports

sqlplus -s / as sysdba <<EOF
set heading off
set feedback off
spool ${OUTPUT_DIR}/awr_${ORACLE_SID}_$(date +%Y%m%d_%H%M%S).html
@?/rdbms/admin/awrrpt.sql
spool off
EOF

将此脚本加入cron定时任务即可实现自动采集。

6. 性能优化实战案例

最近处理的一个典型案例：某系统在每天10:00-11:00出现严重卡顿。通过分析该时段的AWR报告发现：

1. 等待事件首位是log file sync，平均等待时间达487ms
2. 检查I/O子系统发现redo日志所在磁盘阵列的写延迟异常
3. 解决方案：将redo日志迁移到高性能SSD，并增加日志组数量

优化后，同一时段的log file sync等待时间降至23ms，事务处理速度提升8倍。

7. 注意事项与经验总结

1. 存储管理：AWR数据默认保留8天，对于大型系统需要监控SYSAUX表空间使用情况

2. 权限控制：生产环境应严格限制AWR访问权限，避免敏感信息泄露

3. 基准建立：建议在系统健康状态时保存基准AWR报告，便于后续对比分析

4. 报告差异：比较型分析使用awrddrpt.sql（差值报告）比单独看两个报告更高效

5. 移动数据库：12c以后的PDB需要切换到对应容器再生成AWR：

sql复制ALTER SESSION SET CONTAINER=pdb1;
@?/rdbms/admin/awrrpt.sql

通过多年实践，我发现AWR报告的价值不仅在于问题诊断，更是容量规划、性能调优的重要依据。建议DBA建立定期收集和分析机制，将性能问题扼杀在萌芽阶段。