MMON进程异常是AWR快照生成失败的核心原因，需通过v$bgprocess确认其状态，若SPID为空或无返回则进程已退出，且不可手动kill；ORA-1688报错本质是WRH$表因MMON失效导致分区膨胀、清理阻塞，非SYSAUX物理空间耗尽。
MMON进程没在跑，或被挂起
AWR快照自动生成完全依赖 MMON 进程——它不是普通后台进程，不会出现在 v$session 里，也不能用 ps -ef | grep mmon 直接确认存活。常见误判是“没看到 ora_mmon 进程就认为它死了”，其实 Linux 下它混在类似 oram000* 的名字里。
真正可靠的检查方式只有一种：SELECT * FROM v$bgprocess WHERE pname = 'MMON';。如果返回空行，或 SPID 列为 NULL，说明进程异常退出；如果返回但 STATE 是 NOT ALLOCATED 或长时间无变化，大概率被挂起（比如因 latch 冲突卡在初始化阶段）。
- 别用
orakill强杀MMON：它没有安全重启逻辑，杀掉后快照生成可能永久失效 - 实例刚崩溃重启后，
MMON常滞后恢复，ALTER SYSTEM FLUSH SHARED_POOL没用，得等它自己恢复或重启实例 - 查 trace 文件里是否有
Slave action has been temporarily suspended或Unknown return code: 101，这是典型挂起信号
SYSAUX 表空间“看起来有空间”，实际被 WRH$ 表撑爆
ORA-1688 报错说“无法扩展 sys.wrh$ 表”，很多人立刻去查 DBA_FREE_SPACE，发现还有 20% 空间就懵了——问题不在物理空间，而在 WRH$_* 表分区膨胀、自动清理失效。
根本原因是 MMON 挂了或清理策略异常，导致旧快照堆积。哪怕 SYSAUX 还剩 500MB，只要某个 WRH$_ACTIVE_SESSION_HISTORY 分区无法 split，就会报 ORA-1688。
- 查真实占用：
SELECT segment_name, bytes/1024/1024 MB FROM dba_segments WHERE tablespace_name = 'SYSAUX' AND segment_name LIKE 'WRH$_%' ORDER BY bytes DESC FETCH FIRST 5 ROWS ONLY; - 确认保留策略：
SELECT retention, interval FROM dba_hist_wr_control;，如果retention被设成 10000 天，清理逻辑直接绕过 - SM/AWR 组件占比超 70%，基本可判定
MMON清理已严重滞后
STATISTICS_LEVEL 不是 ALL 或 TYPICAL
这是最基础也最容易漏的配置项。STATISTICS_LEVEL 必须是 ALL 或 TYPICAL，设成 BASIC 时，MMON 根本不启动快照采集逻辑，也不会报任何错误，只是安静地啥都不干。
检查命令：SHOW PARAMETER statistics_level。如果值是 BASIC，执行：ALTER SYSTEM SET statistics_level = TYPICAL SCOPE=BOTH;
- 该参数修改后无需重启，但生效需等下一个快照周期（默认一小时）
- RAC 环境下要确认所有节点都设对，单节点设对但其他节点仍是 BASIC，整套 AWR 就不可用
- 某些脚本或备份工具会临时改这个参数，结束后没还原，就成了隐性故障源
手动创建快照卡住，本质是锁或资源争用
执行 DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT() 卡住，往往不是功能坏了，而是内部锁冲突或资源超限：
- 如果卡在
insert into wrh$_sql_bind_metadata，可能是绑定变量元数据表X$KQLFBC数据量过大，ALTER SYSTEM FLUSH SHARED_POOL可缓解 - 如果卡在
insert into wrh$_service_stat，大概率是v$service_stats视图里残留了大量UNKNOWNservice 记录（常见于频繁 expdp 导致），需清理或禁用相关采集：ALTER SYSTEM SET "_awr_disabled_flush_tables" = 'wrh$_sql_bind_metadata'; - 出现
ORA-12751: cpu time or run time policy violation，说明 MMON slave 执行超时被强制中止，通常因系统负载高或统计信息陈旧，先收集SYSschema 统计：EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SYS', CASCADE => TRUE);
复杂点在于：这些现象常叠加出现——比如 MMON 挂了导致 WRH$ 膨胀，WRH$ 膨胀又让手动快照更慢，慢到触发 CPU 时间限制，进而让 MMON 更难恢复。排查时得从 v$bgprocess 和 dba_hist_wr_control 这两个最轻量的入口开始，别一上来就动表空间或杀进程。
