AWR快照无法自动生成主因是MMON卡在WRH$_SQL_BIND_METADATA刷新或SYSAUX被WRH$分区占满；需查v$bgprocess确认MMON状态，禁用该表刷新或调整_swrf_mmon_flush可临时恢复。
AWR快照无法自动生成，90%不是数据库故障，而是MMON卡在WRH$_SQL_BIND_METADATA刷新或SYSAUX空间被WRH$分区撑满。
查MMON是否真挂了：别信ps -ef | grep mmon
Linux下MMON进程名混在oram000*里，OS命令根本不可靠。唯一可信的是v$bgprocess：
SELECT pname, spid, program FROM v$bgprocess WHERE pname = 'MMON';
若无返回、或spid为空，说明MMON异常退出；若spid存在但快照仍失败，大概率是它卡在某项任务里（比如扫描X$KQLFBC）。
- 不要用
kill -9杀MMON——它没有安全重启逻辑，杀完后快照可能永久失效 - 实例刚崩溃重启后，MMON常卡在latch初始化阶段，此时
ALTER SYSTEM FLUSH SHARED_POOL无效，只能等它自行恢复或重启实例
禁用WRH$_SQL_BIND_METADATA刷新：最快止血手段
当MMON因扫描X$KQLFBC超时而报ORA-12751，本质是应用SQL绑定变量泛滥（单条超5000个），导致内存基表检索爆炸。绕过该表是最直接的临时修复：
ALTER SYSTEM SET "_awr_disabled_flush_tables" = 'WRH$_SQL_BIND_METADATA' SCOPE=BOTH;
验证是否生效：
SELECT value FROM v$parameter WHERE name = '_awr_disabled_flush_tables';
- 该参数立即生效，无需重启
- 不影响其他WRH$表（如
WRH$_ACTIVE_SESSION_HISTORY）的快照采集 - 长期开启会丢失绑定变量元数据，仅建议作为过渡方案
确认SYSAUX真实空间占用：DBA_FREE_SPACE不准
DBA_FREE_SPACE显示还有10%空闲？别信。WRH$表分区高水位线已顶满，新段根本无法分配。真正吃空间的是这些：
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：常占几十GB，分区数上百且最老分区远超保留策略 → 表明MMON自动清理失效 -
WRH$_SQL_BIND_METADATA：绑定变量多时极易暴涨，且插入易超时
若发现WRH$_ACTIVE_SESSION_HISTORY最老分区时间远早于dba_hist_wr_control.retention设定值，说明自动清理机制已瘫痪，需手动干预或打补丁（如MOS Doc ID 387914.1）。
重启MMON的可靠方式：用_swrf_mmon_flush开关
比杀进程或重启实例更稳妥——触发MMON软重载：
ALTER SYSTEM SET "_swrf_mmon_flush" = FALSE; ALTER SYSTEM SET "_swrf_mmon_flush" = TRUE;
这个操作会让MMON终止当前卡住的任务并重新初始化调度逻辑。
- 比
ALTER SYSTEM ENABLE RESTRICTED SESSION更精准，不干扰普通连接 - 比杀OS进程安全，避免残留锁或状态不一致
- 执行后观察
v$session中MMON相关会话是否重建、WRH$_插入语句是否恢复
复杂点在于：MMON卡死往往不是孤立现象，而是SYSAUX空间+绑定变量+统计信息任务三者叠加的结果。单独做任一操作都可能短时有效，但不清理源头（比如放任WRH$_SQL_BIND_METADATA持续膨胀），几小时后又会复发。
