AWR快照间隔与保留时间必须用DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS修改，因retention≥interval×2且需整数分钟值，否则报ORA-13541/13516；设7天以下需先调小SYSTEM_MOVING_WINDOW基线；缩短interval至5分钟虽技术可行但生产慎用，会显著增加SYSAUX压力与采集延迟。
AWR快照间隔和保留时间必须用 DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS 修改，不能直接改表或用 ALTER SYSTEM；否则会报 ORA-13541 或 ORA-13516 错误。
为什么 MODIFY_SNAPSHOT_SETTINGS 总是报错
最常见原因是参数不满足约束： retention 必须 ≥ interval × 2，且必须是整数分钟值。Oracle 强制校验这个关系，不是可选逻辑。
-
retention => 7*24*60（7天）但interval => 60（1小时），则 10080 ≥ 120 → 合法 -
retention => 10080但interval => 90→ 10080 ORA-13541 - 传入小数如
interval => 15.5，某些版本隐式截断为 15，有些直接报ORA-13516；统一用整数 - 缺少
EXECUTE权限也会报类似错误，不是只读权限够就行
如何安全地缩短保留时间到 7 天以下
Oracle 默认有 SYSTEM_MOVING_WINDOW 基线，其 moving_window_size（单位：分钟）不能超过 retention。想设 retention = 7 天（10080 分钟），先确认基线大小：
SELECT baseline_name, moving_window_size FROM dba_hist_baseline;
若返回 moving_window_size = 11520（即 8 天），必须先调小基线：
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_BASELINE_WINDOW_SIZE(7);
- 该过程无返回值，成功即静默完成
- 执行后才能调用
MODIFY_SNAPSHOT_SETTINGS设置retention => 10080 - 基线大小改小后，原超出部分的基线数据会自动失效，不影响历史快照
快照间隔设成 5 分钟真的可行吗
技术上允许（interval => 5），但生产环境慎用——它不是“更精细”，而是“更高开销”。
- SYSAUX 表空间写入压力翻倍以上，
WRH$_ACTIVE_SESSION_HISTORY膨胀极快 - 快照生成本身耗时可能接近甚至超过 5 分钟（尤其高负载时），导致实际采集间隔远大于设定值
- AWR 报告生成变慢，
awrrpt.sql执行可能超时 - 仅建议在短期问题定位、性能压测期间启用，事后立刻恢复为 60 分钟
修改后怎么验证是否生效
别只看 PL/SQL 是否成功，要查视图确认真实值：
SELECT snap_interval, retention FROM dba_hist_wr_control;
注意输出格式：+00000 01:00:00.0 中的小时部分就是 interval（这里是 60 分钟），+00007 00:00:00.0 表示 retention 是 7 天。
- 修改立即生效，但不会清理已过期快照——老数据仍按旧策略逐步删除
- 如果
snap_interval显示为+00000 00:00:00.0，说明自动采集已关闭，不是“慢”，是“停” - 手动触发一次快照：
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();，再查dba_hist_snapshot确认新快照 ID 是否生成
真正容易被忽略的是 SYSAUX 空间增长速度——延长 retention 或缩短 interval 后，头几天可能没异常，但一周后 WRH$_ 表碎片和归档压力会集中爆发。改之前务必跑一次空间评估查询，而不是只看当前占用。
