DELETE OBSOLETE常无效，因其仅删除RETENTION POLICY判定过期的备份，而元数据滞后、控制文件陈旧、物理文件被手动删除未同步、未连接恢复目录等均导致跳过真实待删文件；须严格按CROSSCHECK BACKUP→DELETE EXPIRED→DELETE OBSOLETE三步闭环执行。
直接删 DELETE OBSOLETE 很可能没效果——它只删“策略认定过期”的备份，而元数据滞后、控制文件陈旧、物理文件被手动删过，都会导致它跳过真正该删的文件。
为什么 DELETE OBSOLETE 执行后空间没释放
这不是命令写错了，而是 RMAN 的“过期”判断严重依赖元数据一致性。常见真实原因：
-
CROSSCHECK BACKUP没执行：备份文件已被rm删除，但控制文件里还记着 STATUS = AVAILABLE，DELETE OBSOLETE不会碰它 - 控制文件中备份记录已超
control_file_record_keep_time（默认约 30 天）：元数据被覆盖，RMAN 根本不“知道”那些备份存在 - 用了恢复目录（catalog），但 RMAN 连接时没加
catalog用户，只读了控制文件——策略不同步，OBSOLETE判定失效 - 备份被手动打上
KEEP标记（如BACKUP DATABASE KEEP UNTIL TIME 'SYSDATE+365'），DELETE OBSOLETE会主动绕过
安全删除的三步闭环必须串行执行
缺一不可，顺序不能调换。否则会出现“显示删了，LIST BACKUP 还在，磁盘空间也不释放”：
-
CROSSCHECK BACKUP：强制扫描所有备份路径，把物理缺失的备份标记为EXPIRED -
DELETE NOPROMPT EXPIRED BACKUP：清除控制文件中已标记为EXPIRED的元数据条目（这步释放的是 FRA 配额，不是磁盘空间） -
DELETE NOPROMPT OBSOLETE：按当前RETENTION POLICY删真正过期的物理备份文件
注意：DELETE OBSOLETE 默认不删归档日志，除非你额外配置了 ARCHIVELOG DELETION POLICY。归档要单独用 DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' 处理。
生产环境脚本里最容易漏掉的细节
自动化脚本跑通 ≠ 真删成功。以下几处权限和路径问题，90% 的失败都卡在这儿：
-
ORACLE_HOME和ORACLE_SID必须在脚本开头显式export，不能靠 shell 环境继承——cron 下常为空 - RMAN 进程对备份目录（如
$ORACLE_BASE/fast_recovery_area）要有rwx权限；若备份存于 NFS 或 ASM，需确认挂载点用户映射正确 - 如果用了恢复目录，脚本里必须包含
CONNECT CATALOG rman_user/password@catalog_db，否则SHOW RETENTION POLICY查到的是控制文件里的旧策略 -
REPORT OBSOLETE要先跑一遍：它不删，只输出将被删的列表，适合上线前人工核对
删完还得验证，别信“执行成功”四个字
执行完脚本，立刻查三处：
-
LIST BACKUP SUMMARY：看STATUS是否还有大量AVAILABLE—— 如果有，说明CROSSCHECK没扫全或权限不足 -
SELECT * FROM V$RECOVERY_FILE_DEST：确认SPACE_USED确实下降，SPACE_RECLAIMABLE不再持续增长 - OS 层面
df -h：如果磁盘空间没变，大概率是备份文件被其他进程（如 tar、rsync）锁住，或文件系统用了延迟释放机制（如 XFS 的 reflink）
真正难处理的，永远是那些 RMAN “看不见”的残留——比如三年前的手动备份，控制文件早没了记录，只能靠 find /backup/path -name "*.bkp" -mtime +1095 -delete 这类 OS 命令收尾，但前提是业务确认这些文件完全无用。
