必须调用dbms_workload_repository.modify_snapshot_settings修改awr保留时间，单位为分钟且需≥interval×2；直接删表或改参数无效，否则触发ora-13516；执行前须确保sysaux空闲≥2gb、实例open、用户具execute权限，并同步校验及调整moving_window基线大小。
直接改 DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS，别碰表、别删数据
AWR保留时间不能通过修改参数文件、ALTER SYSTEM 或直接 DELETE WRM$_SNAPSHOT 表来调整。所有合法且生效的变更，必须调用 DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS。这个过程不重启实例、不刷新缓存，但会立即更新 dba_hist_wr_control 视图里的配置，后续自动清理逻辑全按新值执行。
常见错误是先查 dba_hist_snapshot 算出最大时间差，再手动 DELETE 老快照——这不仅无效，还可能触发 ORA-13516: AWR purge failed，因为 MMON 进程只认控制表里的 retention 值，不认你删了多少行。
retention 单位是分钟，且必须 ≥ interval × 2
retention 参数必须传整数，单位为分钟。例如设为30天：填 43200（即 30 * 24 * 60），不是 30，也不是小数。
-
retention必须 ≥interval× 2，否则报ORA-13541或ORA-13516 - 若同时调大
retention并缩小interval（如设成10分钟），要同步检查 baseline 的 moving window 大小：执行SELECT moving_window_size FROM dba_hist_baseline WHERE baseline_type = 'MOVING_WINDOW'，确保它 ≤ 新的retention / 1440（单位转成天）；否则需先用DBMS_WORKLOAD_REPOSITORY.MODIFY_BASELINE_WINDOW_SIZE调整 - 传入小数（如
interval => 5.5）在某些版本会隐式截断为5，但部分补丁版本直接报错，统一用整数最稳
执行前必须确认三件事：权限、空间、实例状态
调用失败多数不是语法问题，而是环境卡点：
- 用户需有
EXECUTE权限在SYS.DBMS_WORKLOAD_REPOSITORY上（仅SELECT权限不够） - 实例必须处于
OPEN状态；若报ORA-13502: Cannot modify AWR settings while database is in restricted mode，检查是否启用了受限会话（SELECT logins FROM v$instance返回RESTRICTED） -
SYSAUX表空间至少预留 2GB 空闲——每多留1天，AWR 可能额外占用几百MB到几GB，取决于负载和采集级别；空间不足会导致后续快照生成失败或ORA-1291类错误
改完怎么看效果？别信 MAX(END_INTERVAL_TIME)
验证是否生效，唯一可靠方式是查控制视图：
SELECT snap_interval, retention FROM dba_hist_wr_control;
注意输出格式是 +00008 00:00:00.0 这类，其中天数部分就是小时数除以24后的整数——比如 +00030 00:00:00.0 表示30天。
千万别用 SELECT MAX(end_interval_time) - MIN(end_interval_time) FROM dba_hist_snapshot 来反推“实际保留了几天”，这张表受手工删除、baseline 创建、甚至 DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE 影响，完全不能反映策略配置。
真正容易被忽略的是 baseline moving window 和 retention 的联动关系——哪怕你把 retention 设成了43200，只要 baseline 的 moving_window_size 还卡在8天，某些自动报告和性能对比功能仍会受限。这个值不是“改完就完”，得连带检查并同步调整。
