AWR快照生成失败主因是SYSAUX空间被WRH$表分区占满或MMON扫描x$kqlfbc内存基表超时；需查dba_segments定位大WRH$段、用v$bgprocess确认MMON状态、禁用WRH$_SQL_BIND_METADATA刷新或清理绑定变量源头。
awr快照生成失败，90%的情况不是数据库“坏了”，而是sysaux空间被wrh$表分区撑爆，或统计信息任务卡在x$kqlfbc这类内存基表上——尤其在oracle 11g中，绑定变量泛滥会直接拖垮mmon子进程。
查SYSAUX真实占用：别信dba_free_space
ORA-1688报错时，dba_free_space显示还有10%空间，但快照仍失败。这是因为WRH$表（如WRH$_ACTIVE_SESSION_HISTORY）的分区未被清理，占满高水位线，导致无法分配新段。
- 运行这个查询看真正吃空间的是谁：
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和WRH$_SQL_BIND_METADATA——前者常占几十GB，后者在绑定变量多时会因扫描x$kqlfbc超时而卡住整个快照流程 - 如果
WRH$_ACTIVE_SESSION_HISTORY有上百个分区且最老分区远超保留策略，说明MMON自动清理已失效
确认MMON是否真挂了：v$bgprocess才是唯一依据
用ps -ef | grep mmon看不到进程？正常。Linux下MMON混在oram000*里，不能靠OS命令判断存活。
- 查
v$bgprocess才准：SELECT pname, spid, program FROM v$bgprocess WHERE pname = 'MMON';
若无返回，或spid为空，说明进程异常退出 - 常见假象：实例刚崩溃重启后，MMON卡在latch初始化阶段，此时
ALTER SYSTEM FLUSH SHARED_POOL无效，必须等它自行恢复或重启实例 - 绝对不要
orakill或kill -9终止MMON——它没有安全重启逻辑，强行杀掉会导致后续所有快照永久失败
修复统计信息任务卡死：绕过x$kqlfbc扫描瓶颈
当WRH$_SQL_BIND_METADATA插入失败并报ORA-12751（cpu time violation），本质是MMON子进程扫描x$kqlfbc耗时超限。这不是SQL写得差，而是应用SQL绑定变量太多（单条超5000个），基表数据量爆炸。
- 临时止血：禁用该表刷新，立即生效
ALTER SYSTEM SET "_awr_disabled_flush_tables" = 'WRH$_SQL_BIND_METADATA' SCOPE=BOTH;
- 验证是否生效：
SELECT * FROM dba_hist_wr_control WHERE disabled_flush_tables LIKE '%BIND%';
返回非空即成功 - 长期解法不是删表，而是收缩
v$sql_bind_capture源头：SELECT sql_id, COUNT(*) bind_count FROM v$sql_bind_capture GROUP BY sql_id ORDER BY 2 DESC FETCH FIRST 5 ROWS ONLY;
找到TOP SQL后，让应用团队减少UNION ALL+DUAL构造、改用批量绑定
手动生成快照失败？先清缓存再试
执行EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT()卡住，大概率是共享池里残留了大量未释放的绑定元数据，导致新快照任务抢不到CPU时间片。
- 执行前先刷一次共享池：
ALTER SYSTEM FLUSH SHARED_POOL;
注意：这会引发短时硬解析风暴，业务低峰期操作 - 刷完立刻手动触发：
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
若仍失败，说明问题不在内存，要回头查v$active_session_history中是否有长事务阻塞WRH$写入 - 别用
DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOTRANGE()删旧快照——它会对WRH$表加DML锁，若已有MMON子进程在写WRH$_ACTIVE_SESSION_HISTORY，就会无限等待
最易被忽略的一点：WRH$_ACTIVE_SESSION_HISTORY分区膨胀后，单纯ALTER TABLE ... DROP PARTITION不释放空间，必须配合DBMS_WORKLOAD_REPOSITORY.REMOVE_SNAPSHOT_RANGE()调用官方清理逻辑，否则下次快照还会卡在同一点。
