RETENTION POLICY 只能二选一，RECOVERY WINDOW 与 REDUNDANCY 不可共存；执行新配置时旧策略立即失效，须用 SHOW RETENTION POLICY 确认当前生效策略。
RETENTION POLICY 只能二选一，别同时设 RECOVERY WINDOW 和 REDUNDANCY
RMAN 不允许两种策略共存，执行第二个 CONFIGURE RETENTION POLICY 命令时，前一个会立即失效。很多人在测试环境反复切换，却没查当前生效的是哪个——结果误判备份过期逻辑。
确认当前策略的唯一方式是运行：SHOW RETENTION POLICY;
输出类似 RECOVERY WINDOW OF 7 DAYS 或 REDUNDANCY 2，这才是真实生效的依据。
- 用
RECOVERY WINDOW：适合有明确 RPO 要求的生产库（例如“必须能恢复到 1 小时前”） - 用
REDUNDANCY：适合空间敏感、但对时间点无硬性要求的环境（如开发库只要防误删） - 绝对避免
TO NONE：除非你手动管理所有备份生命周期；在 FRA 环境下极易触发ORA-19809，数据库可能 hang 住
RECOVERY WINDOW 不是“保留最近 N 天备份”，而是按恢复能力反推
设为 RECOVERY WINDOW OF 7 DAYS，不代表 RMAN 会保留过去 7 天的所有备份。它真正做的是：检查当前归档日志链 + 全备/增量备份链，反向计算“要恢复到任意 7 天内时间点，最少需要哪些备份”。如果上次全备是 10 天前，但它仍是当前窗口内唯一可用的全备，RMAN 就不会标记它为 obsolete。
- 前提必须是
ARCHIVELOG模式开启，否则归档日志无法连续，窗口策略直接失效 - 若归档日志被人工删除或
CONTROL_FILE_RECORD_KEEP_TIME过短（默认约 30 天），RMAN 会静默降级——不报错，但REPORT OBSOLETE显示的备份比预期少 - 不要指望它自动清理旧归档：归档日志是否可删，由
ARCHIVELOG DELETION POLICY控制，和RETENTION POLICY是两套逻辑
REDUNDANCY 不是“总共留 N 份备份”，而是每个数据文件单独计数
设为 REDUNDANCY 2，意思是每个数据文件至少要有 2 个有效备份集（含控制文件、SPFILE、归档日志链）。如果某个表空间长期没变更，它的旧备份可能一直不被覆盖，也就一直不被 DELETE OBSOLETE 清理。
- 只做全备、不做增量或归档备份？那 RMAN 会保留最近两个全备，但归档日志仍按默认
TO NONE堆积，FRA 很快撑满 - 脚本中
FORMAT路径没加日期变量（如%T）？多次备份覆盖同一文件，RMAN 判定“只有一个备份”，可能把唯一一份也标为 obsolete -
DELETE OBSOLETE不等于自动清理：它只删“策略判定过期且物理存在”的备份。若备份片已被人工删掉，或 NFS 挂载异常导致路径不可达，RMAN 会跳过，也不报错
改完策略后别急着删，先 REPORT OBSOLETE 看一眼
这是最常被跳过的一步。直接跑 DELETE OBSOLETE 可能删掉仍在恢复链里的备份，尤其在刚切完策略、或归档日志不全时风险极高。
- 正确顺序永远是：
REPORT OBSOLETE→ 人工核对输出列表 → 确认无关键备份 → 再执行DELETE OBSOLETE - 执行前建议先
CROSSCHECK BACKUP和CROSSCHECK ARCHIVELOG ALL，同步控制文件记录与磁盘实际状态 - 哪怕用了恢复目录（catalog），
RETENTION POLICY仍是写在控制文件里的全局配置，catalog 只存元数据，不改策略逻辑
真正难的不是选哪个参数，而是理解它如何和归档模式、控制文件自动备份、FRA 空间、归档删除策略联动。漏掉任意一环，策略就只是纸面配置。
