要延长AWR保留时间至30天，必须用DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS设置retention=43200（分钟），该操作直接更新dba_hist_wr_control表，立即生效，且SYSAUX需预留至少2GB空闲空间。
修改AWR保留时间要用DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS
oracle默认awr快照保留8天，想延长到30天，核心就是调这个包——不是改参数文件，也不是动表结构，更不是删旧快照手动腾空间。它直接更新wrm$_wr_control里的配置，下次自动清理就按新规则走。
常见错误是先查DBA_HIST_SNAPSHOT看最近快照时间，再手动DELETE老数据，结果下次MMON一跑，又清掉一批，或者干脆报ORA-13516：AWR purge failed。因为底层清理逻辑只认控制表的设置，不认你手删了多少行。
- 必须用
SYS或有ADMINISTER DATABASE TRIGGER权限的用户执行 -
retention单位是分钟，30天得填30*24*60 = 43200 -
interval（采集频率）可以不动，保持默认60分钟；改它会影响性能数据粒度，但和保留时间无关 - 执行后立即生效，不需要重启实例，也不需要刷新任何缓存
检查当前设置别只看DBA_HIST_SNAPSHOT最大END_INTERVAL_TIME
很多人用SELECT MAX(END_INTERVAL_TIME) - MIN(END_INTERVAL_TIME) FROM DBA_HIST_SNAPSHOT估算“实际保留了几天”，这完全误导。这张表只是快照内容视图，受自动清理、手工删除、甚至DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE影响，不能反推保留策略。
真正权威的来源只有两个：
-
SELECT retention, interval FROM dba_hist_wr_control—— 这是MODIFY_SNAPSHOT_SETTINGS写入的位置，唯一可信 -
SELECT * FROM v$sysstat WHERE name = 'AWR snapshot interval'（辅助验证采集是否正常）
如果dba_hist_wr_control里retention还是11520（即8天），说明MODIFY_SNAPSHOT_SETTINGS根本没成功执行，或者被回滚了。
ORA-13505：修改失败最常见的原因是SYSAUX表空间不足
延长保留期不光是改个数字，AWR要存更多历史快照数据，SYSAUX会持续增长。如果执行MODIFY_SNAPSHOT_SETTINGS时抛ORA-13505: Cannot modify AWR settings due to lack of space in SYSAUX tablespace，别硬 retry，先看空间。
- 查可用空间：
SELECT tablespace_name, round(used_mb), round(max_mb-used_mb) free_mb FROM v$ tablespaces_usage_metrics WHERE tablespace_name = 'SYSAUX' - SYSAUX建议预留至少2GB空闲（30天+中等负载），否则后续快照可能写失败，
MMON日志里会出现AWR flush failed - 扩容方式优先用
ALTER TABLESPACE SYSAUX ADD DATAFILE，别依赖自动扩展，避免临时文件撑爆磁盘
延长后要注意DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT不会跳过清理逻辑
有人以为“我手动多打几个快照，就能绕过自动清理”，不行。CREATE_SNAPSHOT只是强制触发一次采集，清理逻辑仍然严格按dba_hist_wr_control.retention执行。哪怕你刚建完快照，只要它的时间戳早于当前时间减去43200分钟，下一轮清理就会干掉它。
所以真要保某些关键窗口的数据，得用DBMS_WORKLOAD_REPOSITORY.FLUSH_DATABASE_MONITORING_INFO配合SNAPSHOT_ID范围锁定，或者导出为STP文件——但这属于例外操作，不能替代合理设置retention。
最常被忽略的是：修改后头两天看不到“明显变多”的快照，因为旧快照按原策略还在陆续被清理，要等满一个新保留周期（30天），才能稳定看到完整数据量。别着急查表，先盯两天v$sysstat里AWR snapshot completed计数是否正常。
