AWR快照不自动生成主因是MMON进程卡死、SYSAUX表空间高水位线满导致“假空”、或SYS统计信息过期引发递归SQL性能崩溃，三者常叠加形成死循环。
AWR快照不自动生成，90%不是数据库坏了，而是MMON进程卡死、SYSAUX空间假空、或SYS统计信息过期这三类问题在作祟。
MMON进程被Suspend或异常退出
AWR自动快照依赖后台进程MMON定时触发，但它一旦被挂起（suspended），就不会再调度任何flush动作。常见现象是手动执行DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT卡住数分钟，v$session里看到会话长期停留在insert into wrh$_sql_bind_metadata这类语句上。
- 查真实状态必须用
v$bgprocess：运行SELECT pname, spid, program FROM v$bgprocess WHERE pname = 'MMON'；无返回或spid为空即异常 - 别信
ps -ef | grep mmon——Linux下它常混在oram000*进程里，OS层看不到不代表没跑 - 常见诱因：
ORA-12751（CPU time violation）导致子进程被强制中止后未恢复；实例刚重启时卡在latch初始化阶段 - 禁用/重启用参数无效：
ALTER SYSTEM SET "_swrf_mmon_flush" = FALSE再设为TRUE只影响下一次调度逻辑，不重启MMON本身
SYSAUX表空间“有空间却写不进”
dba_free_space显示还有10%剩余，但快照仍失败，本质是WRH$表分区高水位线（HWM）已顶满，新段无法分配。最典型的是WRH$_ACTIVE_SESSION_HISTORY和WRH$_SQL_BIND_METADATA这两张表。
- 查真实占用：运行
SELECT segment_name, bytes/1024/1024/1024 GB FROM dba_segments WHERE tablespace_name = 'SYSAUX' AND segment_name LIKE 'WRH$_%' ORDER BY bytes DESC FETCH FIRST 5 ROWS ONLY - 若
WRH$_ACTIVE_SESSION_HISTORY有上百个分区且最老分区远超保留策略（如保留8天但存在60天前的分区），说明MMON自动清理机制已失效 - 别急着删数据：先确认
WRH$_SQL_BIND_METADATA是否在拖慢MMON——它扫描内存基表x$kqlfbc超时就会阻塞整个快照流程 - 临时缓解可禁用该表刷新：
ALTER SYSTEM SET "_awr_disabled_flush_tables" = 'WRH$_SQL_BIND_METADATA' SCOPE=BOTH
SYS模式统计信息陈旧引发递归SQL性能崩溃
MMON在采集快照前需访问大量数据字典视图（如GV$SQL、V$SESSION），若SYS schema统计信息过期，优化器可能选错执行计划，导致单次flush耗时飙升至15分钟以上，触发Oracle 11g+的自动熔断机制（报错Unknown return code: 101）。
- 验证方式：执行
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SYS', OPTIONS => 'GATHER AUTO', ESTIMATE_PERCENT => 30, CASCADE => TRUE)后再试手动快照，大概率立刻成功 - 重点补全固定表统计：尤其是
X$KEWRATTRNEW和X$KEWRSQLIDTAB，它们直接影响WRH$_SQL_PLAN等核心历史表的查询效率 - 注意
NO_INVALIDATE => FALSE参数——不加这个，已有游标不会重解析，新统计信息对当前MMON任务无效 - 不要只清
SHARED_POOL：单独ALTER SYSTEM FLUSH SHARED_POOL治标不治本，它只让SQL重硬解析，但若统计信息还是错的，下次照样卡
真正难处理的点在于：这三类问题经常叠加出现。比如SYSAUX空间紧张 → MMON flush失败 → 触发多次重试 → 消耗大量CPU → 引发ORA-12751 → MMON suspend → SYS统计信息更没人更新 → 形成死循环。排查时得按v$bgprocess状态 → dba_segments占用 → DBA_TAB_STATISTICS时效性这个顺序往下压，跳步容易漏根因。
