ORA-19809 是因 db_recovery_file_dest_size 逻辑配额满而非磁盘物理空间不足；需查 v$recovery_file_dest 确认实际使用率，Pct Used ≥ 95% 时应执行 CROSSCHECK → DELETE EXPIRED → DELETE OBSOLETE 清理，并确保扩容时 SCOPE=BOTH 且验证生效。
ORA-19809 不是磁盘满了，而是 db_recovery_file_dest_size 这个逻辑配额被占满了。哪怕 df -h 显示 FRA 所在文件系统还有 100G 空闲，只要这个参数设为 2G 且已用光，RMAN 就会直接拒绝写入并报错。
查真实占用率：别信 SHOW PARAMETER，要看 v$recovery_file_dest
参数值只是上限，不反映实际使用。必须进数据库执行：
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 字段才是 FRA 实际路径，要确认该路径所在挂载点是否有物理空间余量——但即使有，逻辑配额满也照样报错。
RMAN 清理归档必须按顺序执行：CROSSCHECK → DELETE EXPIRED → DELETE OBSOLETE
手动 rm 归档文件是高危操作，会破坏控制文件中记录的归档状态，后续 RMAN 可能报 ORA-19625 或备份失败。正确流程是：
-
CROSSCHECK ARCHIVELOG ALL：让 RMAN 去扫描磁盘上真实存在的归档，标记控制文件里已不存在的为EXPIRED -
DELETE EXPIRED ARCHIVELOG ALL：清理控制文件中已标记为EXPIRED的记录（不删磁盘文件） -
DELETE OBSOLETE：按当前 RMAN 保留策略（如RECOVERY WINDOW OF 7 DAYS）删除真正过期的备份和归档
跳过 CROSSCHECK 直接 DELETE EXPIRED 是无效的；DELETE OBSOLETE 不会动未过期的归档，哪怕 FRA 已满。
扩容 db_recovery_file_dest_size 要用 SCOPE=BOTH 并验证生效
临时改参数不重启只对新会话生效，RMAN 后台进程可能仍读旧值。执行：
ALTER SYSTEM SET db_recovery_file_dest_size = 8G SCOPE=BOTH;
然后必须验证是否真正生效：
- 再次查
v$recovery_file_dest，确认space_limit已更新 - 检查
db_recovery_file_dest对应路径所在文件系统，物理空间是否真够（比如你设了 8G，但挂载点只剩 3G，就会触发 ORA-19804） - 若用的是 ASM，还要确认对应 diskgroup 有足够 free space
单纯 ALTER SYSTEM ... SCOPE=SPFILE 后不重启，或者改完没验证，等于没做。
最常被忽略的一点：FRA 占用率高往往不是因为备份太多，而是归档日志堆积——尤其当应用产生大量事务、又没配置自动删除策略时。DELETE OBSOLETE 不清理归档，除非你显式加 BACKUP ARCHIVELOG 或设置 ARCHIVELOG DELETION POLICY。这点不厘清，扩容只是拖延问题爆发时间。
