RMAN DELETE OBSOLETE 不释放FRA空间是因为仅标记文件为可删除，未物理清理；需配合CROSSCHECK和DELETE EXPIRED才能真正释放，且不处理归档日志和闪回日志。
RMAN DELETE OBSOLETE 为什么没释放 FRA 空间？
执行 delete obsolete 后 v$recovery_file_dest 里 space_used 没降，不是命令没跑，是 rman 默认只标记文件为“可删除”，不真正清理磁盘——得配合 crosscheck 和 delete expired 才能触发物理删除。
-
DELETE OBSOLETE依赖保留策略（如CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS），它只删「被策略判定过期且 RMAN 目录中状态为 AVAILABLE 的备份」 - 如果备份片物理丢失但控制文件/恢复目录里还记着它（比如手动删了
backupset目录），RMAN 会把它标为EXPIRED，而DELETE OBSOLETE对EXPIRED记录完全无视 - 真实空间释放发生在
DELETE NOPROMPT EXPIRED BACKUP或DELETE NOPROMPT OBSOLETE后的清理阶段，但前提是这些文件在磁盘上仍可访问且权限正常
怎么确认哪些文件该删、哪些卡住了？
别猜，直接查 RMAN 视图和 FRA 实际占用。重点看三处是否对齐：RMAN 目录记录、控制文件中的文件状态、FRA 目录下真实文件存在性。
- 运行
LIST EXPIRED BACKUP和LIST OBSOLETE，对比输出——如果前者结果多，说明有“记录还在但文件没了”，后者为空却空间不降，大概率是权限或挂载问题 - 查
V$RECOVERY_AREA_USAGE，关注FILE_TYPE = 'FLASHBACK LOG'和'ARCHIVED LOG'占比，这两类常被忽略，且DELETE OBSOLETE默认不碰 flashback logs（除非加FOR RECOVERY WINDOW且窗口覆盖） - 进 FRA 路径（如
+FRA/orcl/或/u01/fast_recovery_area/ORCL/），用ls -lt | head -20看大文件，再用find . -name "*.bkp" -mtime +7 -ls扫描旧备份片，核对是否真被DELETE命令覆盖
DELETE OBSOLETE 加不加 NOPROMPT 和 FORCE？
生产环境必须加 NOPROMPT，否则交互式确认会卡住；FORCE 则要慎用——它跳过文件存在性检查，强行从 RMAN 目录抹记录，但磁盘文件还在，下次 CROSSCHECK 又变 EXPIRED，白忙活。
-
DELETE NOPROMPT OBSOLETE是安全基线，适合定期调度脚本 - 如果
LIST OBSOLETE有输出但执行后空间不变，先做CROSSCHECK BACKUP→DELETE NOPROMPT EXPIRED BACKUP，再重试OBSOLETE - 遇到 ORA-19573 错误（无法获取独占访问），说明某个备份集正被归档进程或 RMAN 会话占用，查
V$BACKUP_ASYNC_IO或停掉无关 RMAN 作业再试
FRA 空间还是不够？绕过 DELETE OBSOLETE 的硬手段
当保留策略本身不合理（比如设了 30 天但实际只需 3 天），或者归档日志堆积远超预期，光靠 DELETE OBSOLETE 不够，得动配置和流程。
- 临时腾空间：用
ALTER SYSTEM ARCHIVE LOG DELETE ALL COMPLETED BEFORE 'SYSDATE-1'清指定时间前已应用的归档（仅限 Data Guard 备库或确认无用场景） - 调小 FRA 压力：关掉不必要的 flashback（
ALTER DATABASE FLASHBACK OFF），或缩小DB_FLASHBACK_RETENTION_TARGET - 最狠但有效：手动删
archivelog后立刻CROSSCHECK ARCHIVELOG ALL+DELETE NOPROMPT EXPIRED ARCHIVELOG ALL，避免 RMAN 自己扫描慢
真正卡住的往往不是命令不会敲，而是忘了 FRA 里 archive log 和 flashback log 的生命周期独立于 backupset，它们不响应 RETENTION POLICY，得单独管。
