为什么Oracle AWR快照没有自动生成

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 冲突卡在初始化阶段）。

1. 别用 orakill 强杀 MMON：它没有安全重启逻辑，杀掉后快照生成可能永久失效
2. 实例刚崩溃重启后，MMON 常滞后恢复，ALTER SYSTEM FLUSH SHARED_POOL 没用，得等它自己恢复或重启实例
3. 查 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。

1. 查真实占用：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;
2. 确认保留策略：SELECT retention, interval FROM dba_hist_wr_control;，如果 retention 被设成 10000 天，清理逻辑直接绕过
3. 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;

1. 该参数修改后无需重启，但生效需等下一个快照周期（默认一小时）
2. RAC 环境下要确认所有节点都设对，单节点设对但其他节点仍是 BASIC，整套 AWR 就不可用
3. 某些脚本或备份工具会临时改这个参数，结束后没还原，就成了隐性故障源

手动创建快照卡住，本质是锁或资源争用

执行 DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT() 卡住，往往不是功能坏了，而是内部锁冲突或资源超限：

1. 如果卡在 insert into wrh$_sql_bind_metadata，可能是绑定变量元数据表 X$KQLFBC 数据量过大，ALTER SYSTEM FLUSH SHARED_POOL 可缓解
2. 如果卡在 insert into wrh$_service_stat，大概率是 v$service_stats 视图里残留了大量 UNKNOWN service 记录（常见于频繁 expdp 导致），需清理或禁用相关采集：ALTER SYSTEM SET "_awr_disabled_flush_tables" = 'wrh$_sql_bind_metadata';
3. 出现 ORA-12751: cpu time or run time policy violation，说明 MMON slave 执行超时被强制中止，通常因系统负载高或统计信息陈旧，先收集 SYS schema 统计：EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SYS', CASCADE => TRUE);

复杂点在于：这些现象常叠加出现——比如 MMON 挂了导致 WRH$ 膨胀，WRH$ 膨胀又让手动快照更慢，慢到触发 CPU 时间限制，进而让 MMON 更难恢复。排查时得从 v$bgprocess 和 dba_hist_wr_control 这两个最轻量的入口开始，别一上来就动表空间或杀进程。