FRA空间耗尽时需手动清理：先查真实占用率，再CROSSCHECK后DELETE EXPIRED，最后按策略DELETE OBSOLETE；直接rm归档无效且致统计失真，清理后须LIST RECOVERY AREA确认释放。
FRA空间耗尽时，RMAN本身不会自动释放空间，必须手动干预；直接rm归档文件无效，反而会导致v$flash_recovery_area_usage统计失真，真正有效的操作只有三步：查真实占用、先CROSSCHECK再DELETE EXPIRED、按策略DELETE OBSOLETE。
查FRA真实使用率，别信df -h
FRA是逻辑配额机制，df -h显示磁盘有空闲 ≠ FRA有空间。ORA-19809报错时，必须进数据库执行：
SELECT name, space_limit/1024/1024/1024 AS "GB Limit",
space_used/1024/1024/1024 AS "GB Used",
ROUND(space_used/space_limit*100, 2) AS "Pct Used"
FROM v$recovery_file_dest;v$flash_recovery_area_usage更要查——如果ARCHIVED LOG占比超95%，说明归档堆积；若BACKUP PIECE持续增长，说明RETENTION POLICY太松。
CROSSCHECK ARCHIVELOG ALL必须在DELETE前执行
手动删过归档或备库拉取延迟，都会让控制文件元数据和物理文件状态不一致。跳过这步直接DELETE ARCHIVELOG ALL会报no archived log of thread 1 with sequence # found，因为RMAN只删“它认为存在”的文件。
-
CROSSCHECK ARCHIVELOG ALL把OS上已删但控制文件还记着的归档标为EXPIRED - 紧接着执行
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL，只清理这些标记，安全无风险 - 如果归档还在被DataGuard备库需要，
CROSSCHECK会把它标为AVAILABLE而非EXPIRED，避免误删
DELETE OBSOLETE和DELETE EXPIRED不能混用
两者清理对象完全不同：
-
DELETE OBSOLETE依据当前RETENTION POLICY（如RECOVERY WINDOW OF 7 DAYS）判断哪些备份/归档已无恢复价值，再物理删除 -
DELETE EXPIRED只删CROSSCHECK后状态为EXPIRED的记录，不碰“控制文件里根本没记录”的旧文件 - 生产环境推荐顺序：
REPORT OBSOLETE预览 →DELETE NOPROMPT OBSOLETE→CROSSCHECK ARCHIVELOG ALL→DELETE NOPROMPT EXPIRED ARCHIVELOG ALL
清理后必须LIST RECOVERY AREA确认空间释放
DELETE命令输出deleted 12 objects不代表空间已回收。执行完所有清理后，立刻运行：
LIST RECOVERY AREA;
检查输出中Space used是否下降。如果v$recovery_file_dest.space_used没变，常见原因有：
- 归档日志正被DataGuard备库读取（
APPLIED = 'NO'），RMAN拒绝删除 - 闪回日志（
FLASHBACK LOG）未触发自动清理，需等DB_FLASHBACK_RETENTION_TARGET超时 - 控制文件自动备份（
AUTOBACKUP）被保留策略锁定，需单独DELETE CONTROLFILECOPY
最易被忽略的是：自动脚本长期运行后漏掉CROSSCHECK，导致“已删文件仍占FRA配额”的假满现象，此时LIST RECOVERY AREA会暴露残留的EXPIRED条目。
