AWR快照缺失首要确认MMON进程状态，若其未运行或僵死（如RAC中某节点无MMON），则快照停摆；其次排查ORA-12751超时、SYSAUX空间不足、AWR被禁用三类硬性阻断点。
AWR快照缺失，先确认MMON是否在运行
AWR快照由MMON进程驱动，它挂了，快照就停摆。别急着查表空间或SQL，先看进程状态。
- 执行
SELECT program, status FROM gv$session WHERE program LIKE '%MMON%';，若无结果或状态为INACTIVE，说明MMON已僵死 - RAC环境下需检查所有实例：
SELECT inst_id, program, status FROM gv$session WHERE program LIKE '%MMON%'; - 常见现象是MMON反复报
Slave action has been temporarily suspended，背后往往是绑定变量过多触发了运行时策略限制（ORA-12751）
手动创建快照失败？重点盯 WRH$_SQL_BIND_METADATA 插入超时
这是11g+版本最典型的卡点：MMON子进程 m00x 在往 WRH$_SQL_BIND_METADATA 表插入数据时，因访问内存基表 X$KQLFBC 过慢而超时。
- 查告警日志，搜
ORA-12751和AutoFlush Main，若匹配，基本锁定该路径 - 验证方式：手动执行
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();，观察是否卡在enq: WF - contention等待事件上 - 根本原因是业务SQL大量使用绑定变量，导致
X$KQLFBC内存扫描耗时剧增——这不是SQL写得不好，而是AWR自身采集逻辑对高绑定变量负载不友好
SYSAUX满、控制参数关、触发器干扰，三类硬性阻断点
即使MMON活着、SQL也不超时，这三类配置/空间问题仍会直接拦停快照生成。
-
SELECT status FROM dba_hist_wr_control;返回DISABLED？说明AWR被显式关闭，用DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS重开 -
SELECT tablespace_name, bytes/1024/1024 MB FROM dba_data_files WHERE tablespace_name = 'SYSAUX';若剩余空间 - 升级到19c后突然失效？查
_system_trig_enabled是否为FALSE，OGG残留的系统触发器可能拦截MMON操作
别跳过 dba_hist_snapshot 的断层验证
快照“没生成”和“生成了但被清理/不可见”表现一样，必须用底层视图交叉验证。
- 运行
SELECT SNAP_ID, BEGIN_INTERVAL_TIME, FLUSH_ELAPSED FROM dba_hist_snapshot ORDER BY snap_id DESC FETCH FIRST 20 ROWS ONLY; - 若发现SNAP_ID跳跃（如100→105），且
FLUSH_ELAPSED为空或极大（>3600秒），说明快照任务中途失败，不是没触发，而是挂了 - 此时再结合
v$sql_bind_capture中高频出现的sql_id，就能定位到具体哪条绑定密集型SQL拖垮了采集链路
真正难处理的不是单点故障，而是MMON在超时后不报错、不退出、只静默挂起——它可能卡在内存扫描里长达数小时，期间你查 gv$session 看不到异常，查表空间也充足，直到翻出 m00x 的trace文件才看到 X$KQLFBC 扫描耗时82800秒这种线索。
