RMAN的RETENTION POLICY决定备份是否过时，影响REPORT/DELETE OBSOLETE；三种模式（RECOVERY WINDOW、REDUNDANCY、TO NONE）互斥；需配合ARCHIVELOG模式、控制文件自动备份、FRA空间及归档删除策略协同生效。
rman 的不是“保留多少份备份”的简单计数器，而是决定哪些备份在恢复意义上“已不再需要”——它直接影响和的判断结果，且一旦配错，轻则空间爆满报，重则误删导致无法恢复。
RETENTION POLICY 三种模式不能共存
Oracle 明确禁止同时启用多种策略。执行任意一种
后，之前配置会立即被覆盖。
：按“可恢复到最近 N 天内任意时间点”反推所需备份链，包括全备、增量、归档日志。例如设为
，但上次全备是 8 天前，只要它仍是当前恢复窗口内唯一可用的全备，就不会被标记为过时。
：对每个数据文件（或控制文件、SPFILE）保留最多 N 个有效备份集。注意：不是“总共 N 个备份”，而是每个文件单独计数；若某文件从未被新备份覆盖，旧备份可能长期不被清理。
：彻底关闭过时判定。RMAN 永远不标记任何备份为 obsolete，
无效。在使用 FRA（闪回恢复区）时极危险——FRA 空间会被撑满，触发
，数据库可能 hang 住。
配置前必须确认归档模式与控制文件自动备份
保留策略生效的前提是 RMAN 能准确追踪备份元数据。若控制文件损坏或丢失，所有备份可能“不可见”。因此：
数据库必须处于
模式，否则在线全备失败，
失去意义；
务必开启
，并确认格式有效：
；
若使用 FRA，
必须有足够空间，否则即使策略合理，备份也会因写入失败而中断。
常见误操作与对应修复
很多问题不是策略本身错，而是没配合后续动作或忽略上下文：
oracle知识库
oracle知识库下载
下载
改完
后直接跑
，却没先
看一眼——结果删掉还在恢复链里的备份。正确顺序永远是：
→ 人工核对 →
；
用
却长期只做全备，不做增量或归档备份——RMAN 会保留最近两个全备，但归档日志仍按默认策略（
）堆积，最终 FRA 满；
脚本中写死
路径但没加日期变量（如
），导致多次备份覆盖同一文件，
判定时发现“只有一个备份”，于是把该备份也标为 obsolete —— 实际上是路径冲突造成的假象。
FRA 环境下 RETENTION POLICY 的实际效果差异
是否启用 FRA，会让
的行为完全不同：
未用 FRA：RMAN 只标记备份为 obsolete，不会自动删除，需手动
；
启用 FRA：RMAN 在备份写入前，会主动清理 FRA 中被标记为 obsolete 的文件以腾出空间。这意味着
直接影响备份能否成功写入；
关键细节：FRA 中的控制文件自动备份、归档日志、备份集都受同一策略约束。若策略太激进（如
），归档日志可能刚生成就被清理，导致无法做时间点恢复。
真正难的不是选
还是
，而是把策略和你的 RPO/RTO、归档日志保留习惯、FRA 容量、以及是否启用
这几件事拧成一股绳。漏掉其中一环，策略就只是纸面配置。
retention policyreport obsoletedelete obsoleteora-19809CONFIGURE RETENTION POLICY TO ...RECOVERY WINDOW OF N DAYS7 DAYSREDUNDANCY NTO NONEDELETE OBSOLETEORA-19809ARCHIVELOGRETENTION POLICYCONTROLFILE AUTOBACKUP ONCONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/cf_%F'DB_RECOVERY_FILE_DESTRETENTION POLICYDELETE OBSOLETEREPORT OBSOLETEREPORT OBSOLETEDELETE OBSOLETEREDUNDANCY 2TO NONEFORMAT%TRETENTION POLICYRETENTION POLICYDELETE OBSOLETERETENTION POLICYRECOVERY WINDOW OF 1 DAYRECOVERY WINDOWREDUNDANCYARCHIVELOG DELETION POLICY