fra空间不足是配额耗尽而非磁盘满，需查v$recovery_file_dest确认使用率；清理按crosscheck→delete expired→delete obsolete顺序执行；释放后space_used可能延迟更新。
快速恢复区（FRA）空间不足不是磁盘满了，而是 db_recovery_file_dest_size 配额耗尽 —— 即使 df -h 显示挂载点还有几十 GB 空闲，RMAN 仍会报 ORA-19804 或 ORA-19809 拒绝写入。
查清 FRA 实际使用率，别只看 df -h
操作系统层面的磁盘剩余 ≠ FRA 可用空间。FRA 是数据库内部按参数限制的逻辑配额，必须进库查视图确认真实占用：
- 执行
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; - 若
Pct Used≥ 95%，就是 FRA 配额满，不是磁盘满；name字段显示的实际路径，才是你要检查文件系统余量的地方 - 顺带查
v$flash_recovery_area_usage，看哪类文件占大头（归档、备份、控制文件副本、闪回日志）
快速释放空间：RMAN 清理三步走
比改参数、加磁盘更快，且无需重启。但必须按顺序做，否则 DELETE OBSOLETE 可能不生效：
- 先运行
CROSSCHECK ARCHIVELOG ALL;和CROSSCHECK BACKUP;—— 把 OS 上已删但控制文件还记着的“幽灵文件”标为EXPIRED - 再运行
DELETE EXPIRED;—— 清掉这些标记，释放元数据压力 - 最后运行
DELETE OBSOLETE;—— 按当前 RMAN 保留策略（如CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS）删真正过期的备份和归档 - 清理后务必执行
LIST RECOVERY AREA;确认空间已释放，不要只信 DELETE 输出的 “deleted 3 objects”
扩容 db_recovery_file_dest_size 的两种方式
清理后仍不够？必须调大配额。注意生效方式取决于 Oracle 版本和配置：
- 若支持动态修改（Oracle 10gR2+ 单实例常见）：
ALTER SYSTEM SET db_recovery_file_dest_size=10G SCOPE=BOTH; - 若报
ORA-02095: specified initialization parameter cannot be modified，说明是静态参数：需ALTER SYSTEM SET db_recovery_file_dest_size=10G SCOPE=SPFILE;+SHUTDOWN IMMEDIATE; STARTUP; - 扩容前确认
name所在文件系统真有足够物理空间，否则启动后很快又满
最容易被忽略的一点：FRA 空间释放不是即时的。RMAN 删除操作只是标记并触发后台清理，v$recovery_file_dest 中的 space_used 可能延迟几分钟才下降。等完再验证，别删完立刻看数就慌着扩。
