10分钟读懂AWR报告------不看200页，就看3个地方
AWR报告动辄几十页，新人一打开就放弃了。其实80%的瓶颈藏在三个地方：Top SQL、等待事件、IO负载。这篇文章结合社保系统的实际AWR案例，告诉你哪几节值得看、看到什么该警觉。
文章目录
- 10分钟读懂AWR报告------不看200页，就看3个地方
-
- 一、AWR是什么
- [二、第一眼看：Top 10 等待事件](#二、第一眼看：Top 10 等待事件)
- [三、第二眼看：Top SQL](#三、第二眼看：Top SQL)
- 四、第三眼看：IO负载
- 五、不需要看的那些页
- 六、快速诊断命令（不用AWR报告）
一、AWR是什么
AWR（Automatic Workload Repository）是Oracle 10g起自带的性能快照------每小时自动采集一次数据库的运行状态，存入 SYSAUX 表空间。
生成一份AWR报告：
sql
-- 先查有哪些快照
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"------这是第一段要看的。
正常健康系统的等待事件分布：
| 等待事件 | 占比 | 说明 |
|---|---|---|
| DB CPU | 40-60% | CPU在处理SQL，正常 |
| db file sequential read | 15-25% | 索引读，正常 |
| db file scattered read | 5-15% | 全表扫描读，偏高要警惕 |
| log file sync | 1-5% | 事务提交日志写 |
警觉信号：
| 等待事件 | 占比 | 问题 |
|---|---|---|
| log file sync > 10% | 事务提交太频繁，COMMIT太多 | 批量提交或关闭autocommit |
| enq: TX - row lock contention | 行锁等待 | 有人在select...for update没释放 |
| enq: TX - allocate ITL | ITL槽不够 | 增加表的INITRANS |
| buffer busy waits | 热块争用 | 反序主键或Hash分区 |
| read by other session | IO跑不动 | 加大buffer cache或换SSD |
社保系统有一次 log file sync 占了35%。查原因------银行回调接口每笔扣款都单独COMMIT，150笔就是150次日志刷盘。改成批量提交（50笔COMMIT一次），降到3%。
三、第二眼看：Top SQL
搜 "SQL ordered by Elapsed Time"------这是第二段。
关注三个指标：
| 指标 | 含义 | 警戒值 |
|---|---|---|
| Elapsed Time (s) | 总耗时 | 单条超过几百秒 |
| Executions | 执行次数 | 高频+高耗时=头号目标 |
| Elapsed per Exec (s) | 单次耗时 | 超过1秒就要看 |
sql
-- 从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后看执行计划：
sql
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('SQL_ID'));四、第三眼看：IO负载
搜 "Tablespace IO Stats" 和 "File IO Stats"。
关注 Av Rd(ms)------单次读的平均毫秒数：
| 延迟 | 含义 |
|---|---|
| <1ms | SSD，飞一样 |
| 1-5ms | 普通SAN，正常 |
| 5-10ms | 有点慢了 |
| >10ms | 磁盘是瓶颈，考虑加大buffer cache或换存储 |
社保系统有一次 Av Rd(ms) 飙到25ms------查原因是归档日志和数据文件放在了同一块机械盘上，两者抢IO。把归档日志移到独立磁盘后降到5ms。
五、不需要看的那些页
- Load Profile------知道就行，不调参不用看
- Instance Efficiency Percentages------命中率都是骗人的（buffer hit 99%不代表SQL写得好，可能是反复扫同一块）
- Advisory Section------参考价值有限，Oracle建议的内存值通常是实际需要的2倍
- Wait Class------太粗，直接看等待事件更准
六、快速诊断命令（不用AWR报告）
sql
-- 当前等待事件
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自动化优化。