delete obsolete未删除残留备份片，因其仅清理标记为obsolete的文件，而大量因失败、中断或未注册导致的“幽灵备份片”仍为available状态；需先crosscheck backup标记expired，再delete noprompt expired backup安全清理。
为什么DELETE OBSOLETE没删掉那些备份片
RMAN的DELETE OBSOLETE只按当前RETENTION POLICY删“不再用于恢复”的文件，但很多残留备份片根本没被标记为obsolete——它们可能因备份失败、中断或未注册到控制文件而处于AVAILABLE状态，却早已没人需要。查一下：LIST BACKUP SUMMARY里一堆AVAILABLE但COMPLETION TIME是三个月前的备份片，就是典型残留。
常见诱因包括：
– BACKUP DATABASE中途被kill，RMAN没来得及清理临时文件
– 手动用rm删过FRA里的.bkp但没跑CROSSCHECK，控制文件还记着它“存在”
– 用了恢复目录但没定期RESYNC CATALOG，主库控制文件和目录状态不同步，导致obsolete判定失效
怎么安全识别并清理这些“幽灵备份片”
不能靠ls -l看文件时间，必须让RMAN自己“看见”哪些真丢了、哪些该删。关键动作只有两个，顺序不能错：
-
CROSSCHECK BACKUP：扫描FRA物理路径，把OS上已不存在的备份片在控制文件中标为EXPIRED -
DELETE NOPROMPT EXPIRED BACKUP：只删标记为EXPIRED的元数据条目，不碰任何物理文件，零风险
如果FRA里有大量小备份片（比如每小时一次的归档备份），CROSSCHECK BACKUP会慢，但别跳过——跳过就等于永远不知道哪些是真残留。
清理后空间还是没释放？检查闪回日志和归档策略
FRA里三类主力占空间：备份片、归档日志、闪回日志。你刚清了备份片，但V$RECOVERY_FILE_DEST里FLASHBACKLOG占比突然飙高，说明DB_FLASHBACK_RETENTION_TARGET设得过大，或业务写入压力突增，闪回日志正在疯长。
同时确认归档是否真被允许删除：
– 运行SHOW ARCHIVELOG DELETION POLICY，如果不是TO APPLIED ON ALL STANDBY（Data Guard环境）或TO BACKED UP 1 TIMES TO DEVICE TYPE DISK（单机），即使备份成功，归档也不会自动标记为可删
– 检查V$FLASH_RECOVERY_AREA_USAGE中ARCHIVELOG的PERCENT_SPACE_RECLAIMABLE是否为0；如果是，说明归档还在“待应用”或“待备份”状态，不是备份片的问题
如何防止下次又堆满
残留备份片反复出现，往往是因为缺乏自动化清理闭环。别只依赖人工DELETE OBSOLETE：
- 每天固定时间跑
CROSSCHECK BACKUP; DELETE EXPIRED BACKUP;——这是防残留的底线操作 - 把
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;和CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DEVICE TYPE DISK;配齐，让RMAN知道“备份完就能删归档” - 禁用
CONTROLFILE AUTOBACKUP ON以外的自动备份，除非真需要；频繁的controlfile autobackup会在FRA里留一堆小文件，极难清理
真正难处理的从来不是单次清理，而是FRA里混着备份片、归档、闪回日志、autobackup四类生命周期完全不同的文件——它们共用一个配额，但清理逻辑各自独立。盯住V$FLASH_RECOVERY_AREA_USAGE里每一行的PERCENT_SPACE_RECLAIMABLE，比盯着总使用率有用十倍。
