RMAN保留策略需依赖归档日志完整性与控制文件元数据同步才生效，仅配置不触发清理；SHOW ALL仅显示策略设置，不反映备份实际可用性；必须通过REPORT OBSOLETE、CROSSCHECK等命令结合归档模式、自动备份等前提才能真正起效。
rman 保留策略不是“设完就生效”，它依赖控制文件中记录的备份元数据和当前归档日志完整性。直接执行 configure retention policy 只改配置项，不触发立即清理，也不校验归档是否真实可用。
为什么 SHOW ALL 看不到备份是否过期
SHOW ALL 只显示当前配置值，比如 CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS，但它不反映任何备份的实际状态。控制文件里可能还存着 10 天前的一份全备，但若中间归档日志被手动删过，这份全备其实已无法用于时间点恢复——SHOW ALL 完全不体现这点。
真正判断“哪些备份还能用”，必须用：
-
REPORT OBSOLETE：列出所有被当前策略判定为可删除的备份（文件物理存在 + 元数据标记过期） -
LIST BACKUP SUMMARY：只告诉你有哪些备份集、是否有效（valid），但不关联保留策略 -
CROSSCHECK BACKUP：同步控制文件与磁盘实际文件状态，把“找不到的备份”标为EXPIRED，这步不做，DELETE OBSOLETE就不会动它
RECOVERY WINDOW 和 REDUNDANCY 切换时的坑
两种策略互斥，切换前必须先清空旧策略，否则报错 ORA-19571: retention policy is already configured。
- 从
REDUNDANCY 2改成RECOVERY WINDOW OF 7 DAYS，得先执行：CONFIGURE RETENTION POLICY CLEAR - 设了
RECOVERY WINDOW OF 7 DAYS，但归档日志没开或被DELETE ARCHIVELOG清过，RMAN 会静默降级——REPORT OBSOLETE显示的过期备份比预期少，且不报错 - 设了
REDUNDANCY 1，又手工跑了一次BACKUP DATABASE，最老那份全备立刻变成OBSOLETE，下次DELETE OBSOLETE就直接删掉，没有二次确认
通道配置影响备份路径与速率，但不决定保留逻辑
CONFIGURE CHANNEL DEVICE TYPE DISK 控制的是备份写入行为，和保留策略无关，但容易混淆：
- 格式模板里的
%U或%d_%t_%s_%p必须和CONFIGURE CHANNEL ... FORMAT一致，否则备份片名不可预测，后期DELETE OBSOLETE可能漏删 - 执行
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '...'会覆盖之前所有磁盘通道的 format 设置，不是追加 - 没配通道就直接跑
BACKUP DATABASE，RMAN 会自动分配一个默认通道，但无法控制速率、路径、并发——生产环境务必预配
CONTROLFILE AUTOBACKUP 开启后，spfile 和控制文件备份也受保留策略约束
很多人以为自动备份的控制文件是“元数据保险”，其实它一样会被 DELETE OBSOLETE 扫到并删掉：
-
CONFIGURE CONTROLFILE AUTOBACKUP ON后，每次BACKUP DATABASE都会生成一份新控制文件备份，这些备份也参与REPORT OBSOLETE判定 - 如果用了
RECOVERY WINDOW，旧控制文件备份可能因“太老”被标 obsolete；如果用了REDUNDANCY，只留最新 N 份，其余全删 - 没开
AUTOBACKUP，又没手动BACKUP CURRENT CONTROLFILE，一旦控制文件损坏，连恢复起点都没了——这是比备份过期更致命的问题
保留策略真正起效的前提，是归档模式开着、归档日志没被意外截断、控制文件自动备份开着、且定期做 CROSSCHECK 同步状态。少其中任何一环，DELETE OBSOLETE 就只是个看起来很规范的命令而已。
