AWR报告不显示系统load average，但能精准定位高负载的数据库内部原因；快速生成方法为：SYSDBA登录后执行@?/rdbms/admin/awrrpt.sql，选html格式、填天数1、查快照ID后生成，默认输出awrrpt_1_xxx_yyy.html。
awr报告本身不直接显示系统load average，但能精准定位导致高负载的数据库内部原因——cpu争用、io瓶颈或sql低效，这是比看top更可靠的起点。
怎么快速生成一份可用的AWR报告
别等故障发生再翻文档。在sqlplus里用SYSDBA登录后，直接运行@?/rdbms/admin/awrrpt.sql即可启动向导。关键点有三个：
- 类型选
html（比text更易读，尤其带图表） - 天数填
1：代表从今天0点起至今，适合排查刚发生的异常 - 开始/结束snap_id别手动输错——先查
select snap_id, begin_interval_time from dba_hist_snapshot order by snap_id desc fetch first 10 rows only;，挑两个时间差约15~30分钟的快照
报告默认输出到当前sqlplus工作目录，文件名类似awrrpt_1_1234_1245.html。
重点盯哪几块数据
打开HTML报告后，跳过Summary页，直奔三处：
-
Top 5 Wait Events：如果DB CPU排第一且占比超60%，说明是SQL执行太重；若db file sequential read或log file sync靠前，则分别指向单块IO慢或提交频繁 -
SQL ordered by Elapsed Time：找Elapsed Time (s)列里数值明显高于其他SQL的那几条，它们大概率就是“罪魁” -
Instance Efficiency Percentages下的Buffer Hit %和Library Hit %：低于95%就要警惕——前者低说明物理读多，后者低说明硬解析频繁
查出问题SQL后怎么验证它真在捣乱
光看AWR里的SQL_ID不够，得确认它此刻是否还在活跃执行：
- 用
SELECT sid, serial#, sql_id, status, event FROM v$session WHERE sql_id = 'your_sql_id' AND status = 'ACTIVE';确认会话状态 - 查
v$sql看执行次数和逻辑读：SELECT executions, buffer_gets, disk_reads, sql_text FROM v$sql WHERE sql_id = 'your_sql_id';——如果disk_reads远高于buffer_gets，基本坐实没走索引 - 别忘了检查绑定变量：同一
SQL_ID但不同PLAN_HASH_VALUE，说明执行计划不稳定，可能受绑定变量窥探影响
容易被忽略的陷阱
很多人生成AWR后只盯着SQL耗时，却漏掉两个隐蔽但高频的问题源：
- 大量短生命周期连接：AWR里
Logons per Second若持续＞50，且SQL*Net break/reset to client在Top Wait里靠前，大概率是应用没复用连接，每秒建连又断开，消耗大量CPU做上下文切换 - 后台Job失控：比如
DBMS_SCHEDULER任务卡住，AWR里看不到它的SQL，但在v$session中能看到MODULE为DBMS_SCHEDULER、EVENT为PL/SQL lock timer的长等待会话
这些情况不会在“Top SQL”里显形，必须结合v$session实时视图交叉验证。
