recovery window 和 redundancy 不能共存，必须二选一：rman 仅允许一个生效的 retention policy，后执行的 configure 命令会静默覆盖前一个；需用 show all 或 show retention policy 确认真实生效策略，误配将导致策略失效或恢复能力下降。
RECOVERY WINDOW 和 REDUNDANCY 不能共存，必须二选一
RMAN 只允许当前生效一个 RETENTION POLICY：要么是 RECOVERY WINDOW OF N DAYS，要么是 REDUNDANCY N。第二次执行 CONFIGURE RETENTION POLICY 命令时，前一个自动失效——不是报错，而是静默覆盖。
很多人在测试环境反复切换，却忘了用 SHOW RETENTION POLICY 确认真实生效的策略。输出类似 CONFIGURATION FOR RETENTION POLICY IS: REDUNDANCY 2 或 RECOVERY WINDOW OF 7 DAYS，这才是唯一可信依据。
- 误以为“设了冗余 2，再设窗口 3 天就能兼顾”——语法上不被允许，Oracle 直接拒绝第二个配置生效
- 误把
REPORT OBSOLETE输出为空当作策略没生效——可能只是当前备份集还没触发淘汰条件 - 没开归档或归档被手动删过，
RECOVERY WINDOW会静默降级（不报错，但实际可恢复时间点缩短）
RECOVERY WINDOW 适合有明确 RPO 要求的生产库
比如业务要求“必须能恢复到任意过去 2 小时内的状态”，那就必须用 RECOVERY WINDOW OF 2 HOURS（注意：最小单位是小时，不支持分钟）。它不看备份次数，而看“能否拼出一条完整恢复链”。
关键点在于：RMAN 会保留所有必要的备份集 + 归档日志，哪怕某份全备是 10 天前的，只要它是支撑“恢复到昨天下午 3 点”的唯一基础，它就不会被标记为 OBSOLETE。
- 依赖归档日志完整性：缺一份归档，整个窗口就断链，
DELETE OBSOLETE可能什么也不删 - 受
CONTROL_FILE_RECORD_KEEP_TIME限制：若设窗口为 7 天，但该参数仍为默认 7，历史备份元数据可能被覆盖，导致策略失效 - 闪回区（FRA）内，过期文件会被自动清理；非 FRA 环境下，
DELETE OBSOLETE必须手动执行，且只删“控制文件里还记着、又满足策略”的备份
REDUNDANCY 更适合空间敏感、恢复目标宽松的场景
比如开发/测试库只要防误删，或者备份存储紧张，就用 REDUNDANCY 2。它以最近的 FULL 或 LEVEL 0 备份为锚点，只保留该锚点及之后的 N−1 份同类备份。
注意：它不保证时间跨度。连续三天每天做一次 BACKUP DATABASE，第 4 天执行 REPORT OBSOLETE 才可能标出第一天的备份为过期——因为此时已有 3 份 LEVEL 0，而策略只要求留 2 份。
- 归档日志是否保留，取决于它能否应用到“最老的非过期
LEVEL 0”上；旧归档若无法连到任一存活的LEVEL 0，就会被标记为OBSOLETE - 单独备份归档日志（
BACKUP ARCHIVELOG）本身不参与冗余计数，只有和LEVEL 0组成恢复链时才被策略约束 -
REDUNDANCY 1是默认值，等效于“只留最新一份”，但不等于“不留”——它依然会阻止你删掉最后一份有效备份
别忽略 CONTROL_FILE_RECORD_KEEP_TIME 这个隐性开关
RETENTION POLICY 的判断完全依赖控制文件里的备份元数据。而这些元数据最多只保留 CONTROL_FILE_RECORD_KEEP_TIME 天（默认仅 7 天）。如果策略窗口设为 30 天，但该参数仍是 7，那 8 天前的备份记录早就从控制文件里消失了——策略形同虚设。
调整方法很简单：ALTER SYSTEM SET CONTROL_FILE_RECORD_KEEP_TIME = 30;，建议设为略大于你最长的 RECOVERY WINDOW 或备份周期。
- 该参数修改后立即生效，无需重启实例
- 它影响所有 RMAN 元数据（不仅是备份，还包括归档日志记录、备份片状态等）
- 设得过大不会明显拖慢控制文件写入，但会略微增加其体积；设得太小会导致策略“看不见”旧备份
