RETENTION POLICY 是 RMAN 全局配置项，决定 DELETE OBSOLETE 时清理旧备份的依据，而非 BACKUP 命令参数；支持 RECOVERY WINDOW（按可恢复时间点倒推）和 REDUNDANCY（按备份份数保留）两种互斥模式，需配合 CONTROL_FILE_RECORD_KEEP_TIME 和归档完整性使用。
RETENTION POLICY 是 RMAN 的全局策略，不是备份命令的参数
很多人以为 backup 时加个选项就能控制保留多久，其实 retention policy 是 rman 配置项，影响后续所有 crosscheck 和 delete obsolete 的行为。它不决定“备份时保留什么”，而决定“什么时候删旧备份”。
实操建议：
- 用
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS设置基于时间的窗口（推荐用于归档日志完整、需按时间点恢复的场景） - 用
CONFIGURE RETENTION POLICY TO REDUNDANCY 2设置冗余度（适合备份频率低、更看重副本数量而非时间跨度的环境） - 执行后立即生效，但不会自动删数据 —— 必须手动运行
DELETE OBSOLETE才真正清理 - 设成
NONE并不等于“不删”，而是让 RMAN 忽略该策略，DELETE OBSOLETE将无操作（容易误以为安全，实则积累垃圾）
RECOVERY WINDOW 和 REDUNDANCY 的判断逻辑完全不同
这是最容易混淆的点：两者计算 obsolete 备份的方式完全不兼容，不能混用或叠加理解。
RECOVERY WINDOW 按「最远可恢复时间点」倒推：比如今天是 2024-06-15，窗口为 7 天，则 RMAN 要确保能恢复到 2024-06-08 00:00:00 任意时刻 —— 这要求归档日志、全备、增量备份链必须覆盖该时间点之后的所有变更。哪怕你有 10 份全备，只要其中一份缺失了某段归档，RMAN 仍可能标记它为 obsolete。
REDUNDANCY 则只数同类备份的份数：对每个数据文件或归档日志序列，只保留最新 N 份，其余标为 obsolete。它不关心时间跨度，也不验证是否真能恢复。
常见错误现象：
- 设了
RECOVERY WINDOW 7，但归档日志被其他脚本提前清理 →DELETE OBSOLETE可能误删关键全备（因无法满足窗口内恢复） - 设了
REDUNDANCY 1，又手工多跑了一次BACKUP DATABASE→ 最老那份全备立刻被标 obsolete，下次DELETE OBSOLETE就没了 - 切换策略类型时没
CONFIGURE RETENTION POLICY CLEAR→ RMAN 报错ORA-19571: retention policy is already configured
SHOW ALL 和 LIST BACKUP SUMMARY 不显示保留状态，得用 REPORT OBSOLETE
SHOW ALL 只告诉你当前配置值，LIST BACKUP SUMMARY 只列备份集存在与否，二者都不反映哪些备份已被策略判定为 obsolete。真正要确认“删之前长啥样”，必须用 REPORT OBSOLETE。
实操建议：
- 执行
REPORT OBSOLETE查看将被删除的对象（含备份集、归档、镜像复制），输出里带obsolete标记 - 加
RECOVERY WINDOW 5参数可临时覆盖当前策略做预演，例如：REPORT OBSOLETE RECOVERY WINDOW OF 5 DAYS - 注意：
REPORT OBSOLETE不扫描磁盘，只查 RMAN repository（即控制文件或恢复目录），所以如果备份文件被手工删了但未CROSSCHECK，它仍会显示为 obsolete —— 实际已不存在，DELETE OBSOLETE会报ORA-19625
归档日志的保留受 CONTROL_FILE_RECORD_KEEP_TIME 影响，和 RETENTION POLICY 无关
这是个长期被忽略的耦合点：即使你配了 RECOVERY WINDOW 30，如果 CONTROL_FILE_RECORD_KEEP_TIME（默认 7 天）太小，RMAN 就查不到 7 天前的归档日志记录，导致它认为“无法满足窗口”，进而把很多全备标为 obsolete —— 即使那些归档物理还在磁盘上。
实操建议：
- 检查当前值：
SHOW PARAMETER CONTROL_FILE_RECORD_KEEP_TIME - 若归档保留期 > 7 天，务必同步调大该参数（如设为 30），并重启实例生效（静态参数）
- 在使用恢复目录（recovery catalog）的环境中，该参数不影响 RMAN 判断，因为元数据存在独立库中；但控制文件模式下，它是硬限制
- 不要指望靠延长
CONTROL_FILE_RECORD_KEEP_TIME来替代归档日志管理 —— 它只影响记录留存，不阻止归档被覆盖或删除
真正难的不是配那条 CONFIGURE 命令，而是理清 recovery window 背后依赖的归档完整性、控制文件记录寿命、以及 repository 同步状态。少一个环节断掉，DELETE OBSOLETE 就可能删掉不该删的东西。
