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