AWR快照失效并非因间隔过长，而是因SNAP_INTERVAL为+00000 00:00:00.0（完全关闭）、MMON异常、SYSAUX空间阻塞或绑定变量泛滥；确认是否关闭需查dba_hist_wr_control中SNAP_INTERVAL值。
awr快照不会因为“间隔过长”而失效——真正导致失效的，是间隔被设为 0（即完全关闭），或者后台进程 mmon 异常、sysaux 空间阻塞、绑定变量泛滥等底层故障。所谓“间隔过长”只是误判，实际问题往往藏在配置值或进程状态里。
怎么确认AWR快照是否真的“关了”？
关键看 dba_hist_wr_control 里的 SNAP_INTERVAL 值是不是 +00000 00:00:00.0：
- 如果是这个值，说明 AWR 快照采集已彻底禁用，不是“慢”，是“停”
- 如果是
+00000 01:00:00.0或+00000 00:30:00.0，说明采集正常，只是间隔设得长 - Oracle 19c 默认仍是每小时一次，
retention默认仍是 8 天（11520 分钟）
执行这条语句就能一眼看清：
SELECT dbid, snap_interval, retention FROM dba_hist_wr_control;
为什么有人觉得“调大间隔就失效”？
本质是混淆了“采样稀疏”和“功能失效”。比如把间隔从 60 分钟改成 24 小时，快照确实变少了，但只要 SNAP_INTERVAL 不是 0，MMON 就仍在运行，数据也仍在写入 WRH$ 表。问题出在：
- 分析时发现“没有覆盖问题时间段”的快照 → 其实是采样太粗，不是没生成
- 手动执行
DBMS_WORKLOAD_REPOSITORY.create_snapshot()报错 → 错误根源在 MMON 或 SYSAUX，和间隔无关 - AWR 报告提示 “No data found for selected time period” → 很可能起止时间没对上快照边界，不是没快照
调整保留策略和采样频率的实操要点
改之前先确认当前负载和 SYSAUX 空间压力，避免盲目延长 retention 导致空间爆炸：
- 查 SYSAUX 实际占用：
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; - 延长 retention 要同步评估空间：每多留 1 天，通常增加 0.5–2 GB（视活跃 SQL 数和绑定变量量而定）
- 缩短间隔（如到 15 分钟）只建议短期用：性能测试、问题复现期间，用完立刻调回，否则
WRH$_ACTIVE_SESSION_HISTORY会暴涨 - Oracle 19c 支持
TOPNSQL动态调整，但改它不影响快照生成，只影响 AWR 报告里 TOP SQL 的数量
执行修改的命令必须带单位（分钟）：
EXEC DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(interval => 30, retention => 14*24*60);
最容易被忽略的“假失效”信号
很多 DBA 看到 AWR 报告空白、快照 ID 断层、create_snapshot() 卡住，第一反应是“间隔设错了”，其实更该优先检查：
-
v$bgprocess中MMON的SPID是否为空 —— 空则进程已死，不是配置问题 - 告警日志里有没有
ORA-12751—— 有则大概率是绑定变量泛滥卡在wrh$_sql_bind_metadata -
dba_hist_snapshot最后一条记录的startup_time是否变化 —— 若不变，说明实例重启过，新快照还没来得及生成 - SYSAUX 表空间中
WRH$段的分区数是否超 1000 —— 过多分区会让清理逻辑变慢甚至挂起
配置本身不会让 AWR 失效；失效永远发生在进程、内存、锁或空间层面。盯着 SNAP_INTERVAL 调来调去，不如先看 MMON 活着没、SYSAUX 堵没堵、x$kqlfbc 里有没有几万条绑定变量等着被扫。
