recovery window 是唯一真正“基于周期”的保留策略，因其按可恢复时间点倒推并验证备份链完整性；redundancy 仅计数份数，to none 则关闭过期判定，二者均不满足周期定义。
直接配 recovery window，别碰 redundancy 或 to none —— 这才是“基于周期”的唯一合法路径。
为什么只有 RECOVERY WINDOW 算真正“基于周期”
所谓“周期”，指的是可恢复到过去某段时间内任意时间点的能力，比如“必须能恢复到最近 7 天内任一时刻”。RMAN 中只有 RECOVERY WINDOW OF N DAYS 满足这个定义：它从当前时间倒推 N 天，反向计算出支撑该恢复能力所需的最小备份集合（全备 + 增量 + 归档日志链），不是简单按文件生成时间删旧的。
而 REDUNDANCY 是按每个数据文件保留 N 份备份，不验证时间跨度是否连续；TO NONE 则彻底关闭过期判定，跟“周期”毫无关系。
- 执行
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS后，RMAN 会持续检查归档日志是否完整、增量链是否断裂——缺一块，就可能把本该保留的全备也标为OBSOLETE - 如果中间归档被
DELETE ARCHIVELOG清过，或没开归档，RECOVERY WINDOW会静默降级，REPORT OBSOLETE显示的过期备份会变少，且不报错 -
SHOW RETENTION POLICY才是真实生效依据；SHOW ALL只显示配置项，不反映任何备份实际可用性
RECOVERY WINDOW 配置前必须确认的三件事
配了不等于能用。以下任一缺失，策略都会失效或误判：
- 数据库必须处于
ARCHIVELOG模式：SELECT LOG_MODE FROM V$DATABASE返回值必须是ARCHIVELOG；否则全备无法持续，窗口根本无从谈起 -
CONTROLFILE AUTOBACKUP必须开启且路径有效：CONFIGURE CONTROLFILE AUTOBACKUP ON+CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/cf_%F'；否则控制文件损坏后元数据丢失，所有备份“不可见” - 若使用 FRA（
DB_RECOVERY_FILE_DEST），空间必须充足；否则备份写入失败，REPORT OBSOLETE可能漏掉本该标记的备份，后续DELETE OBSOLETE也就无从清理
配完不能直接删：必须走标准清理三步
CONFIGURE 只改控制文件里的策略项，不触发任何物理操作。要让“周期”真正落地，必须手动执行：
-
CROSSCHECK BACKUP：同步控制文件记录和磁盘真实状态。若备份片已被人工删除或 NFS 挂载异常，这步不做，DELETE OBSOLETE就不会动它，也不报错 -
REPORT OBSOLETE：列出所有被当前策略判定为过期 且物理存在 的备份。务必先看结果，确认最老全备是否仍在恢复链中——比如它的时间戳是 8 天前，但归档只保留到 6 天前，那它其实已不可用，RMAN 就会把它标为OBSOLETE -
DELETE OBSOLETE：仅删上一步报告出来的备份。它不等于自动清理，也不等同于DELETE EXPIRED或手动DELETE BACKUP
容易被忽略的底层依赖：CONTROL_FILE_RECORD_KEEP_TIME
控制文件里存的 RMAN 元数据不是永久的。默认 CONTROL_FILE_RECORD_KEEP_TIME=7，意味着超过 7 天的备份记录可能被覆盖——哪怕你设了 RECOVERY WINDOW OF 14 DAYS，若元数据已丢失，RMAN 就算想保留也“看不见”那些旧备份。
若未用恢复目录（recovery catalog），又需要 >7 天的保留周期，必须调大该参数：ALTER SYSTEM SET CONTROL_FILE_RECORD_KEEP_TIME = 14 SCOPE=BOTH。注意：增大它会略微增加控制文件体积，但比丢备份安全得多。
