AWR快照无法自动创建主因是SYSAUX表空间被WRH$分区占满或MMON进程卡死在x$kqlfbc扫描上；需查dba_segments定位大WRH$段、用v$bgprocess确认MMON状态、禁用WRH$_SQL_BIND_METADATA刷新或清理绑定变量源头。
AWR快照无法自动创建，90%不是数据库坏了，而是 SYSAUX 表空间被 WRH$ 分区撑爆，或 MMON 进程卡死在 x$kqlfbc 内存基表扫描上——尤其在绑定变量泛滥的 11g 环境里，WRH$_SQL_BIND_METADATA 插入超时直接拖垮整个快照流程。
查 SYSAUX 真实占用，别信 DBA_FREE_SPACE
ORA-1688 报错时，DBA_FREE_SPACE 可能显示还有 10% 空间，但快照仍失败。这是因为 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（常占几十 GB）和WRH$_SQL_BIND_METADATA（绑定变量多时极易卡住） - 如果
WRH$_ACTIVE_SESSION_HISTORY有上百个分区，且最老分区远超保留策略（如保留 8 天），说明 MMON 自动清理已失效
确认 MMON 是否存活，只看 V$BGPROCESS
用 ps -ef | grep mmon 找不到进程？正常。Linux 下 MMON 混在 oram000* 里，OS 层不可靠。
- 唯一可信方式是查视图：
SELECT pname, spid, program FROM v$bgprocess WHERE pname = 'MMON';
- 若无返回，或
spid为空，说明进程异常退出 - 常见假象：实例刚崩溃重启后，
MMON卡在 latch 初始化阶段，此时ALTER SYSTEM FLUSH SHARED_POOL无效，必须等它自行恢复，或重启实例 -
绝对不要 用
orakill或kill -9终止MMON——它没有安全重启逻辑，强行杀掉会导致后续所有快照永久失败
禁用 WRH$_SQL_BIND_METADATA 刷新，绕过 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 disabled_flush_tables FROM dba_hist_wr_control;
结果应含BIND - 若需长期缓解，可定期执行：
ALTER SYSTEM FLUSH SHARED_POOL;
（注意业务低峰期操作） - 不推荐重启数据库来“清空
x$kqlfbc”，除非其他手段全失效；更稳妥的是调整绑定变量使用方式，减少单语句变量数
修复后验证与防复发
手动触发一次快照只是起点，真正难点在于让自动机制重新跑起来且不再中断。
- 先手工生成快照：
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
- 检查是否成功：
SELECT snap_id, begin_interval_time FROM dba_hist_snapshot ORDER BY snap_id DESC FETCH FIRST 3 ROWS ONLY;
- 确认自动任务恢复：
SELECT * FROM dba_hist_wr_control;中interval应为非零值（如 60 分钟） - 最容易被忽略的一点：迁移过主机名的 RAC 环境，
DBA_HIST_DATABASE_INSTANCE里可能残留旧主机名记录，导致 AWR 报告选不到实例——需人工清理过期行，否则即使快照生成了，awrrpt.sql也报“no snapshots found”
