RMAN的RETENTION POLICY在11g中“不起作用”通常因策略被清空为TO NONE、归档日志未注册进控制文件、未执行CROSSCHECK或ARCHIVELOG DELETION POLICY未配置所致。
rman 的 retention policy 在 11g 中“不起作用”，几乎总是因为策略根本没生效，而不是它坏了。最常见的情况是：你执行了 configure retention policy to ...，但随后 report obsolete 显示 “no obsolete backups”，delete obsolete 什么也不删——这不代表策略失效，而是它被覆盖、清空，或压根没进判定范围。
SHOW RETENTION POLICY 输出是 TO NONE
这是 11g 中最典型的静默失效。一旦执行过 CONFIGURE RETENTION POLICY CLEAR（哪怕只是测试），策略就退回到默认的 TO NONE。RMAN 永远不会标记任何备份为 OBSOLETE，DELETE OBSOLETE 必然无效。
- 立刻验证：
SHOW RETENTION POLICY;—— 别信脚本注释或记忆 - 若输出是
RETENTION POLICY TO NONE，必须重配，例如：CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; - 注意：
TO NONE在使用 FRA（DB_RECOVERY_FILE_DEST）时极其危险：RMAN 不删，FRA 空间满则触发ORA-19809，数据库可能 hang 住
归档日志不在控制文件记录里
RMAN 判定归档是否可删，完全依赖 v$archived_log 视图里的元数据。而该视图只保留约 30 天记录（由 control_file_record_keep_time 参数控制）。老归档即使物理存在，RMAN 也“看不见”。
-
LIST ARCHIVELOG ALL查不到旧文件 → 控制文件已丢失记录 -
CROSSCHECK ARCHIVELOG ALL没反应 → RMAN 根本没在控制文件里看到它们 - 解决办法：先用
CATALOG START WITH '/path/to/archivelog/';把磁盘上真实存在的归档手动注册进控制文件 - 注册后务必确认：
SELECT COUNT(*) FROM v$archived_log WHERE FIRST_TIME > SYSDATE - 60;数量明显增加才算成功
没跑 CROSSCHECK 就直接 DELETE OBSOLETE
RETENTION POLICY 只定义“哪些算过期”，不保证这些备份还“物理存在”。如果备份片曾被手动 rm、NFS 挂载异常、或备份目录权限变更，控制文件仍记着它，但磁盘上早已消失。
-
DELETE OBSOLETE只删“策略判定过期 + 物理存在”的备份；对“已丢失”的备份，它静默跳过，不报错也不提示 - 必须前置执行：
CROSSCHECK BACKUP;和CROSSCHECK ARCHIVELOG ALL;，把缺失文件标为EXPIRED - 再补一步清理残留：
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;（否则REPORT OBSOLETE会漏掉真正该删的）
ARCHIVELOG DELETION POLICY 未配置或配错
即使 RETENTION POLICY 正确，RMAN 对归档日志的删除还受另一独立策略约束：ARCHIVELOG DELETION POLICY。11g 默认不启用，且它和主库归档路径绑定紧密。
- 检查当前策略：
SHOW ARCHIVELOG DELETION POLICY; - 若输出是
NO ARCHIVELOG DELETION POLICY，RMAN 会拒绝删除本地归档（哪怕REPORT OBSOLETE列出来了） - 对单机主库，安全做法是：
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK; - 若用了备库，别用
APPLIED ON STANDBY（易误判），改用SHIPPED TO ALL STANDBY
真正卡住人的地方，往往不是策略写错，而是 SHOW RETENTION POLICY 没查、CATALOG 没做、CROSSCHECK 漏掉——三步缺一，DELETE OBSOLETE 就像对着空气挥拳。
