rman归档删除策略在19c需手动触发且依赖完整配置：retention policy默认to none须重配；archivelog deletion policy对本地路径无效需显式配置；crosscheck缺失或control_file_record_keep_time过短会导致归档“不可见”，必须脚本化三步闭环清理。
RMAN 归档删除策略在 19c 上“配了却没用”，根本不是策略没生效，而是它压根没被触发——RMAN 从不自动执行删除，所谓“策略”只是判断依据，不是执行开关。
RETENTION POLICY 被隐式清空为 TO NONE
19c 升级或执行过 CONFIGURE RETENTION POLICY CLEAR 后，策略会退回到默认的 TO NONE。此时 REPORT OBSOLETE 永远返回 “no obsolete backups”，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 住
ARCHIVELOG DELETION POLICY 对本地归档路径无效
19c 默认只信任 LOG_ARCHIVE_DEST_n 中标记为 SYNC 或 STANDBY 的目的地。如果你只用 LOCATION=/arch 这类本地路径，DELETE ARCHIVELOG ALL COMPLETED BEFORE 会静默跳过这些文件，甚至报 RMAN-08137。
- 查真实配置：
SELECT DEST_NAME, TARGET, BINDING FROM V$ARCHIVE_DEST WHERE STATUS = 'VALID'; - 若
BINDING = 'MANDATORY'且TARGET = 'PRIMARY'，必须配：CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;（即使没备库也要配） - 更稳妥：改用
LOG_ARCHIVE_DEST_1='LOCATION=/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES)'，再配策略
CROSSCHECK 缺失导致 RMAN “看不见”磁盘上的归档
RMAN 判定能否删，依赖控制文件里 v$archived_log 的 STATUS 和 DELETED 字段。如果归档目录被手动 rm 过、NFS 挂载异常、或长时间未同步，RMAN 仓库记录就和物理文件脱节——LIST ARCHIVELOG ALL 查不到，DELETE 自然不生效。
- 每次删前必须先做：
CROSSCHECK ARCHIVELOG ALL; - 否则
DELETE EXPIRED ARCHIVELOG ALL可能什么也不删，DELETE ARCHIVELOG ALL COMPLETED BEFORE也可能漏删 - 注意：
CROSSCHECK是 I/O 密集操作，大归档目录下耗时明显，别跳过
control_file_record_keep_time 过短，旧归档彻底“不可见”
控制文件默认只保留约 30 天的归档元数据（由参数 control_file_record_keep_time 控制）。超过这个时间的归档，哪怕物理文件还在磁盘上，RMAN 也完全无法识别，REPORT OBSOLETE 和 DELETE ARCHIVELOG 全部失效。
- 这类文件只能通过 OS 命令清理：
find /arch -name "*.dbf" -mtime +15 -delete - 执行前务必确认：这些文件不在当前备份集中，且业务恢复窗口（如 RMAN 备份保留期）已覆盖
- 别指望
DELETE OBSOLETE或DELETE ARCHIVELOG处理它们——它们不在 RMAN 视野内
真正可靠的清理，从来不是靠“配完策略就自动运行”，而是脚本里硬编码 CROSSCHECK → DELETE EXPIRED → DELETE COMPLETED BEFORE 三步闭环，并交由 cron 或 Windows 任务调度。任何一步缺失，都会让策略形同虚设。
