ORA-19809 是因 FRA 逻辑配额耗尽而非磁盘满，须查 v$recovery_file_dest 确认使用率；清理应先 CROSSCHECK 再 DELETE OBSOLETE/EXPIRED，扩容仅作临时手段。
ORA-19809 不是磁盘满了，而是 FRA（闪回恢复区）的逻辑配额耗尽了；直接删文件或看 df -h 会误判，必须进数据库查 v$recovery_file_dest 真实使用率。
查 FRA 实际使用率，别信 df
操作系统层面磁盘有空闲 ≠ FRA 有空间。FRA 是 Oracle 自己管理的一块逻辑区域，上限由参数 db_recovery_file_dest_size 控制，默认常为 8GB 或 10GB。即使挂载点还有几十 GB，只要这个值被占满，就会报 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;
- 重点看
Pct Used—— 超过 95% 就大概率触发错误；name字段才是 FRA 实际路径，确认该路径所在文件系统是否真有余量 -
SHOW PARAMETER db_recovery_file_dest只显示配置路径，不反映实际占用，不能替代上面的查询
RMAN 清理过期/无效文件，优先于扩容
清理比改参数更快、更安全，且无需重启实例。关键顺序不能错：先标记再删除，否则可能删掉还在用的归档。
- 进 RMAN 后先做交叉校验：
CROSSCHECK ARCHIVELOG ALL和CROSSCHECK BACKUP—— 把 OS 层已删但控制文件还记着的“幽灵文件”标为EXPIRED - 删真正过期的备份：
DELETE OBSOLETE（按当前保留策略判断，比如CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS） - 只删标记为
EXPIRED的记录：DELETE EXPIRED ARCHIVELOG ALL或DELETE EXPIRED BACKUP - 强制清理指定时间前的归档（慎用）：
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7'—— 适用于归档未被备份、且业务允许丢 7 天内数据的场景 - 清理后必须运行：
LIST RECOVERY AREA确认空间释放，别只信 DELETE 输出的 “deleted”
别误用 BACKUP RECOVERY AREA
这条命令不是清理命令，也不会释放 FRA 空间。它只是把当前有效的备份片和归档日志复制到另一个位置，相当于“镜像”，原 FRA 文件一个不少。
- 常见误操作：执行
BACKUP RECOVERY AREA后发现ORA-19809依旧，甚至报RMAN-06207: WARNING: 1289 objects could not be deleted - 它不备份控制文件自动备份（autobackup）和闪回日志（flashback logs）
- 真正腾空间，只能靠
DELETE OBSOLETE、DELETE EXPIRED或DELETE ARCHIVELOG
临时扩容 db_recovery_file_dest_size
清理后仍不够用，才考虑调大配额。该参数可动态修改，无需重启：
- SQL*Plus 中执行：
ALTER SYSTEM SET db_recovery_file_dest_size = 20G SCOPE=BOTH; - 注意单位：支持
G、M、K，不要写成20GB（会报错） - 如果 FRA 路径在 ASM 磁盘组，还要确认对应磁盘组（如
FRA）本身有足够free_mb，否则扩了也写不进去 - 扩容只是缓兵之计，长期需配合定期清理策略，否则很快又满
最容易被忽略的是：FRA 使用率是累计计算的，哪怕你刚删了一批归档，只要没执行 CROSSCHECK，控制文件里还记着它们，空间就不会释放。所以清理动作必须成对出现——先 CROSSCHECK，再 DELETE，中间不能跳步。
