要延长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计数是否正常。