RECOVERY WINDOW OF N DAYS不是保留最近N天备份，而是确保能恢复到过去N天内任意时刻，依据是备份集中最老数据块的CHECKPOINT TIME而非备份时间，需配合归档完整性、控制文件自动备份及FRA空间等前提才生效。
RECOVERY WINDOW OF N DAYS 不是保留最近 N 天的备份
很多人配完 CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS 就以为“7天前的备份全该删”，结果发现 10 天前的全备还在，FRA 却爆了。根本原因：这个策略不是按备份时间（START_TIME）算的，而是按备份集中最老数据块的 CHECKPOINT TIME 倒推——即 SYSDATE - CHECKPOINT TIME >= 7 才可能被标为 obsolete。只要这份旧全备仍是支撑“恢复到第 8 天”的唯一基础（比如中间没做新全备、归档日志又完整），它就必须留着。
常见误判场景：
- 手动执行过
DELETE ARCHIVELOG，导致恢复链断裂，RMAN 静默降级，那份 10 天前的全备立刻变成OBSOLETE，但你根本不会收到告警 - 用
REPORT OBSOLETE看到的列表，才是真实可删的；SHOW ALL只显示配置，不反映实际恢复能力 - 归档日志默认永不自动删（
ARCHIVELOG DELETION POLICY TO NONE），哪怕你设了 7 天窗口，归档照样堆满 FRA，触发ORA-19809
REDUNDANCY N 和 RECOVERY WINDOW 不能共存
Oracle 明确禁止同时启用两种策略。执行第二个 CONFIGURE RETENTION POLICY 命令时，前一个立即失效。别信“先配 redundancy 再配 window 就能叠加”这种说法——SHOW RETENTION POLICY 输出什么，才是当前真实生效的策略。
选哪个？看业务需求：
-
RECOVERY WINDOW OF 7 DAYS：适合有明确 RPO 要求的生产库，比如“必须能恢复到任意过去 7 天内的时间点”。它会保留整条链（全备 + 增量 + 归档），哪怕某些备份片生成于 12 天前 -
REDUNDANCY 2：适合空间敏感、恢复时间点无硬性要求的环境（如开发库）。它对每个数据文件单独计数——只要该文件有 2 份有效全备（含对应归档/增量），最老那份就会被标为OBSOLETE -
TO NONE：彻底关闭过时判定。在 FRA 环境下极危险，DELETE OBSOLETE永远不生效，FRA 必爆
配完 retention policy 不等于自动清理
配置只改控制文件里的策略项，不触发任何物理删除。想让 DELETE OBSOLETE 真正起作用，必须补全三步：
- 先跑
CROSSCHECK BACKUP：同步控制文件记录和磁盘真实状态。如果备份片已被人工删掉或 NFS 挂载异常，控制文件还记着它，DELETE OBSOLETE就不会动它，也不报错 - 再执行
REPORT OBSOLETE：列出所有被当前策略判定为可删且物理存在的备份。务必人工核对——比如确认最老全备是否仍在恢复链中 - 确保归档日志完整：若
RECOVERY WINDOW下中间归档缺失，RMAN 不报错，但REPORT OBSOLETE显示的过期备份会比预期少
建议把 CROSSCHECK + REPORT OBSOLETE + DELETE OBSOLETE 封装进备份脚本末尾，而不是靠“配完就完事”。
必须配套的三项关键配置
缺一不可，否则 retention policy 形同虚设，甚至引发误删或恢复失败：
- 数据库必须是
ARCHIVELOG模式：SELECT log_mode FROM v$database;返回ARCHIVELOG才行。否则BACKUP DATABASE PLUS ARCHIVELOG直接失败 - 开启
CONTROLFILE AUTOBACKUP ON，且FORMAT必须指向可写路径（RAC 环境要确认是共享存储）：CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/bak/cf_%F.bkp'; -
DB_RECOVERY_FILE_DEST（FRA）或自定义备份路径，剩余空间至少是数据库大小的 1.5 倍。否则备份写入失败，控制文件元数据无法更新，策略判断失准
最容易被忽略的是归档日志删除策略。必须显式配置：CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;，否则归档日志只增不减，FRA 爆满只是时间问题。
