retention policy 是 rman 全局配置项，仅决定 delete obsolete 的判断逻辑，不自动清理；必须配合 crosscheck、report obsolete 和归档完整性才能安全生效，且 recovery window 与 redundancy 二者互斥，须按 rpo 需求择一配置。
retention policy 配置不是“设完就自动删旧备份”，它只影响 report obsolete 和 delete obsolete 的判断逻辑；配错会直接导致该删的没删（fra爆满报 ora-19809），或不该删的被删（恢复链断裂）。
怎么选 RECOVERY WINDOW 还是 REDUNDANCY
二者互斥，只能生效一个，选哪个取决于你的恢复目标：
-
RECOVERY WINDOW OF 7 DAYS：适合有明确 RPO 要求的场景，比如“必须能恢复到任意过去 7 天内的时间点”。RMAN 会反推所需最小备份集（全备 + 增量 + 归档日志链），不是简单保留最近 7 天的备份文件。 -
REDUNDANCY 2：适合空间敏感、但对时间点无硬性要求的环境（如开发库）。它按每个数据文件单独计数——只要该文件有 2 份有效全备（含对应归档/增量），最老那份就会被标为OBSOLETE。 - 别混用。执行第二个
CONFIGURE RETENTION POLICY命令时，前一个自动失效。查当前生效策略用：SHOW RETENTION POLICY，不是SHOW ALL。
为什么配了却没删？常见漏掉的三步
配置只是改控制文件里的策略项，不触发任何清理动作。真正让 DELETE OBSOLETE 生效，必须补全这三步：
-
CROSSCHECK BACKUP：同步控制文件记录和磁盘真实状态。如果备份片已被手动删掉或 NFS 挂载异常，控制文件还记着它，DELETE OBSOLETE就不会动它，也不报错。 -
REPORT OBSOLETE：列出所有被当前策略判定为可删且物理存在的备份。务必先看结果，再人工核对——比如确认最老全备是否仍在恢复链中。 - 确保归档日志完整。若
RECOVERY WINDOW下中间归档被DELETE ARCHIVELOG清过，RMAN 会静默降级，REPORT OBSOLETE显示的过期备份比预期少，且不报错。
19c 升级后必须重配的关联项
从 11g 升上来的 19c 实例，几个关键配置不会继承，必须手动补全，否则策略形同虚设：
-
CONTROLFILE AUTOBACKUP FORMAT必须显式指定路径。19c 默认开启自动备份，但若未设FORMAT，会 fallback 到闪回区（$ORACLE_BASE/fast_recovery_area），而新库的 FRA 往往未初始化或权限不对，导致控制文件备份静默失败，元数据丢失后策略完全失效。 -
BACKUP OPTIMIZATION默认关闭。如果你依赖它跳过重复归档备份，升级后需手动开：CONFIGURE BACKUP OPTIMIZATION ON，并确认V$BLOCK_CHANGE_TRACKING.STATUS = 'ENABLED'且 BCT 文件已重建（11g 的 BCT 文件 19c 不兼容）。 -
ARCHIVELOG DELETION POLICY必须重新绑定。11g 的归档路径在 19c 中仍可用，但 RMAN 删除策略默认只认LOG_ARCHIVE_DEST_n中标记为SYNC或STANDBY的目的地。本地归档需显式配置：CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY或根据实际调整。
真正容易被忽略的是：RETENTION POLICY 的生效前提是控制文件里存着准确、完整的备份元数据。一旦控制文件损坏、或自动备份失败、或归档日志链断裂，策略就变成“纸上谈兵”——REPORT OBSOLETE 可能漏判，DELETE OBSOLETE 可能误删，而这些都不会主动报错。
