dbms_workload_repository.modify_snapshot_settings是唯一合法修改方式，直接改数据字典或alter system无效；需先查dba_hist_wr_control确认当前配置，且retention必须≥interval×2，interval最小为1分钟但不建议低于15分钟，设0则关闭自动采集，修改仅影响后续快照，实例须open且sysaux空间充足。
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS 是唯一合法修改方式，直接改数据字典或用 ALTER SYSTEM 命令无效，还会引发不一致。
查当前配置再动手，别猜
先执行：
SELECT dbid, snap_interval, retention FROM dba_hist_wr_control;结果里
snap_interval 显示为 +00000 01:00:00.0 表示当前是每小时一次；+00000 00:30:00.0 就是30分钟。注意：这不是字符串，是 Oracle 内部时间间隔格式，小时位就是实际分钟数（比如 00:30:00.0 对应 30 分钟）。
调间隔必须满足 retention ≥ interval × 2
这是硬性校验，违反会报 ORA-13541 或 ORA-13516。比如设 interval => 30（30 分钟），retention 至少得是 60（单位是分钟）——但生产环境没人只留 1 小时，通常配成 retention => 30*24*60（30 天）。
-
interval最小允许值是 1，但 Oracle 官方明确不建议低于 15 分钟 - 设
interval => 0不是“调短”，是彻底关闭自动采集 - 所有参数必须传整数，
interval => 15.5会隐式截断或直接报错，统一写15
执行前务必确认 SYSAUX 空间和 baseline 窗口
高频采样（如 15 分钟）会让 WRH$_ACTIVE_SESSION_HISTORY 表暴涨，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;
- 如果
dba_hist_baseline中moving_window_size是 8，而你把retention改成7*24*60（7 天），就得先运行DBMS_WORKLOAD_REPOSITORY.MODIFY_BASELINE_WINDOW_SIZE(7) - 实例必须处于
OPEN状态，受限模式（restricted mode）下会报ORA-13502 - 修改只影响后续快照，已生成的旧快照仍按原策略过期
验证是否生效，重点看 MMON 是否真在跑
改完再查 dba_hist_wr_control 只能确认参数写了进去，不代表 MMON 进程正常触发。观察最近 2 小时有没有新快照：
SELECT snap_id, begin_interval_time, end_interval_time FROM dba_hist_snapshot ORDER BY snap_id DESC FETCH FIRST 5 ROWS ONLY;
- 如果
snap_id停滞不动，说明 MMON 挂了、SYSAUX 写满、或绑定变量爆炸导致采样卡死 - 手动执行
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT()成功，但自动快照不来 → 问题不在间隔设置，在后台进程或资源阻塞 - 快照时间不是绝对准时的，
interval => 30意味着“至少每 30 分钟尝试一次”，I/O 压力大时可能顺延
MMON 进程状态，也没查 SYSAUX 实际增长速度。参数写了≠功能活了，尤其在负载高的库上，自动快照停摆往往不是配置错了，而是系统扛不住了。
