awr报告生成卡顿并非功能故障，而是资源争用、锁等待或底层异常所致；常见原因包括sysaux i/o延迟高、wrh$表锁争用、ash数据量大、undo段争用、sysaux空间不足、索引失效及rac集群服务异常。
AWR报告生成过程本身不会导致数据库“系统无响应”，你遇到的卡顿或无响应，基本是报告生成时触发了资源争用、锁等待或底层依赖异常，而非AWR功能本身出错。
awrrpt.sql执行卡住但数据库仍可连，大概率是SQL*Plus会话被阻塞
这是最常见却最容易误判的情况：你运行@?/rdbms/admin/awrrpt.sql后光标不动，以为数据库挂了，其实只是当前SQL*Plus会话在等某个内部资源。原因包括：
-
DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML（或TEXT）函数执行时需访问WRH$_系列历史表，若SYSAUX表空间I/O延迟高（如Avg Rd(ms) > 20ms），查询会卡在全表扫描这些大基表上 - 多个DBA同时跑AWR报告，争抢
WRH$_SQLSTAT等大表上的共享锁，尤其当某张WRH$_表因统计信息陈旧引发动态采样时，会加剧争用 - 你正在生成的快照区间内存在大量ASH采样数据（比如AAS持续>10），
awrrpt.sql默认要聚合这些行，单次查询可能扫描数千万行
DB Time远大于DB CPU且Top 5里出现enq: US - contention
这说明AWR报告生成逻辑正被Undo段争用拖住——不是你写的SQL在争，而是AWR自身在读取历史事务信息时，需要访问UNDO$和SEG$字典表，而这些访问受Undo段头块（US enqueue）保护。典型表现是：
- 执行
awrrpt.sql时，v$session_wait中看到大量会话在等enq: US - contention -
SELECT * FROM v$undostat ORDER BY begin_time DESC发现最近几个快照的maxquerylen异常长（比如>3600秒），说明有长事务未提交，AWR为保证一致性必须回滚到SCN快照点 - 此时即使数据库其他SQL还能跑，AWR报告生成也会陷入“等Undo”的死循环
SYSAUX表空间不足或WRH$_表索引失效
AWR所有快照数据都写入SYSAUX，一旦空间紧张或索引损坏，报告生成就会退化为暴力扫描：
- 检查
dba_free_space中tablespace_name = 'SYSAUX'的剩余空间，低于10%时WRH$_ACTIVE_SESSION_HISTORY分区扩展失败，后续快照写入异常，报告工具反而更难定位有效数据范围 - 运行
ANALYZE TABLE WRH$_SQLSTAT VALIDATE STRUCTURE CASCADE，若报ORA-01498，说明索引与表数据不一致，awrrpt.sql将绕过索引直接扫全表 -
WRH$_表的主键索引（如WRH$_SQLSTAT_PK）若因DDL操作被disable，报告生成性能下降可达10倍以上
crsctl或ohasd异常间接影响AWR报告生成
在RAC环境中，这个链路容易被忽略：AWR报告生成脚本依赖v$database和v$instance视图，而这些视图底层调用集群同步服务。如果CRS状态异常，会导致：
-
crsctl check crs返回CRS-4537（OHAS未启动），此时v$instance中INSTANCE_NAME可能为空或不一致，awrrpt.sql在初始化阶段就卡住 - 私网通信故障（如UDP 12345端口不通）导致
GV$视图查询超时，默认等待120秒，你看到的就是“无响应” - 手动执行
SELECT * FROM gv$sysstat WHERE rownum 若也卡住，基本可锁定是CRS层问题，不是AWR本身
真正危险的不是报告生成慢，而是你试图用awrrpt.sql诊断问题时，它自己成了问题的一部分——这时该切去查v$session_wait实时等待、确认SYSAUX空间、验证CRS状态，而不是反复重试脚本。
