05-十分钟读懂AWR报告

10分钟读懂AWR报告——不看200页，就看3个地方

AWR报告动辄几十页，新人一打开就放弃了。其实80%的瓶颈藏在三个地方：Top SQL、等待事件、IO负载。这篇文章结合社保系统的实际AWR案例，告诉你哪几节值得看、看到什么该警觉。

一、AWR是什么

AWR（Automatic Workload Repository）是Oracle 10g起自带的性能快照——每小时自动采集一次数据库的运行状态，存入 SYSAUX 表空间。

生成一份AWR报告：

-- 先查有哪些快照
SELECT SNAP_ID, BEGIN_INTERVAL_TIME, END_INTERVAL_TIME
FROM DBA_HIST_SNAPSHOT ORDER BY SNAP_ID DESC;

-- 生成HTML报告（SNAP_ID 用实际值替换）
@?/rdbms/admin/awrrpt.sql

报告生成在当前目录下，是一个HTML文件。

二、第一眼看：Top 10 等待事件

打开报告搜 “Top 10 Foreground Events”——这是第一段要看的。

正常健康系统的等待事件分布：

警觉信号：

社保系统有一次 log file sync 占了35%。查原因——银行回调接口每笔扣款都单独COMMIT，150笔就是150次日志刷盘。改成批量提交（50笔COMMIT一次），降到3%。

三、第二眼看：Top SQL

搜 “SQL ordered by Elapsed Time”——这是第二段。

关注三个指标：

-- 从AWR直接查Top SQL（不用报告）
SELECT SQL_ID,
       ROUND(ELAPSED_TIME_DELTA/1000000, 2) AS TOTAL_SEC,
       EXECUTIONS_DELTA AS EXECS,
       ROUND(ELAPSED_TIME_DELTA/DECODE(EXECUTIONS_DELTA,0,1,EXECUTIONS_DELTA)/1000000,4) AS AVG_SEC
FROM DBA_HIST_SQLSTAT
WHERE SNAP_ID = 快照ID
ORDER BY ELAPSED_TIME_DELTA DESC
FETCH FIRST 10 ROWS ONLY;

找到SQL_ID后看执行计划：

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('SQL_ID'));

四、第三眼看：IO负载

搜 “Tablespace IO Stats” 和 “File IO Stats”。

关注 Av Rd(ms)——单次读的平均毫秒数：

社保系统有一次 Av Rd(ms) 飙到25ms——查原因是归档日志和数据文件放在了同一块机械盘上，两者抢IO。把归档日志移到独立磁盘后降到5ms。

五、不需要看的那些页

• Load Profile——知道就行，不调参不用看
• Instance Efficiency Percentages——命中率都是骗人的（buffer hit 99%不代表SQL写得好，可能是反复扫同一块）
• Advisory Section——参考价值有限，Oracle建议的内存值通常是实际需要的2倍
• Wait Class——太粗，直接看等待事件更准

六、快速诊断命令（不用AWR报告）

-- 当前等待事件
SELECT EVENT, COUNT(*) FROM V$SESSION WHERE WAIT_CLASS<>'Idle'
GROUP BY EVENT ORDER BY 2 DESC;

-- 当前活跃SQL
SELECT SQL_ID, SQL_FULLTEXT FROM V$SQL
WHERE SQL_ID IN (SELECT SQL_ID FROM V$SESSION WHERE STATUS='ACTIVE');

-- 锁等待关系（谁在等谁）
SELECT HOLDING_SESSION, WAITING_SESSION, MODE_HELD, MODE_REQUESTED
FROM DBA_WAITERS;

✅ 亮点：不逐页解释AWR报告，直接用社保系统的真实诊断案例（log file sync 35%、IO 25ms延迟）讲重点看哪里、看到什么数字该警觉。扩展方向：ASH报告实时诊断、SQL Tuning Advisor自动化优化。