ORA-19809是FRA逻辑配额db_recovery_file_dest_size耗尽所致，与磁盘物理空间无关；需查v$recovery_file_dest确认使用率，按CROSSCHECK→DELETE EXPIRED→DELETE ARCHIVELOG→DELETE OBSOLETE顺序清理，并验证归档路径是否抢占FRA资源。
ORA-19809 不是磁盘满了，是 Oracle 闪回恢复区（FRA）的逻辑配额 db_recovery_file_dest_size 被耗尽了。哪怕 df -h 显示还有几十 GB 空闲，只要这个参数设为 2G 且已用满，RMAN 就会拒绝写入并报错。
查 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%？—— 表示配额已实质撑爆 -
name字段路径是否真实可写？—— 比如指向 ASM diskgroup，得再查v$asm_diskgroup.free_mb -
space_reclaimable是否为 0？—— 若为 0，说明没过期文件可自动回收，必须人工干预
RMAN 清理必须先 CROSSCHECK 再 DELETE
手动 rm 归档日志或备份文件是高危操作：控制文件里还记着这些文件，后续 RMAN 会报 ORA-19625 或备份失败。
安全清理顺序如下（全部在 RMAN 中执行）：
-
CROSSCHECK ARCHIVELOG ALL—— 把 OS 上已删但控制文件仍记录的归档标为EXPIRED -
CROSSCHECK BACKUP—— 同理处理备份集 -
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL—— 只删元数据，零风险 -
DELETE NOPROMPT ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'—— 删真正完成超 7 天的归档（按COMPLETION_TIME，比UNTIL TIME更准） -
DELETE NOPROMPT OBSOLETE—— 按当前保留策略（如RECOVERY WINDOW OF 7 DAYS）删不再需要的备份
清理后务必跑 LIST RECOVERY AREA 确认空间释放，别只看 DELETE 输出的 “deleted”。
扩容 db_recovery_file_dest_size 前先确认生效方式
如果数据库能 MOUNT：
-
ALTER SYSTEM SET db_recovery_file_dest_size = 8G SCOPE=BOTH;—— 同时改内存和 spfile
如果数据库起不来（比如报 ORA-03113）：
- 先
STARTUP MOUNT，再执行上面的ALTER SYSTEM，最后ALTER DATABASE OPEN - 若 FRA 在 ASM 上，扩完还得确认对应 diskgroup 的
free_mb > 0，否则写不进去
注意：SHOW PARAMETER db_recovery_file_dest 只显示路径，不反映占用；df -h 看的是挂载点总空间，不是 FRA 配额 —— 这俩都不可靠。
归档路径冲突也会触发 ORA-19809
即使 FRA 有空间，如果显式设置了 log_archive_dest_1 指向其他目录，而该目录满了，归档会 fallback 到 FRA，连锁导致 ORA-19809。
检查命令：
SHOW PARAMETER log_archive_dest_1
若该路径所在文件系统已满，要么清空它，要么临时切回 FRA（设为 LOCATION=USE_DB_RECOVERY_FILE_DEST），避免归档卡死。
实际操作中，最常被忽略的是：清理后没验证 v$recovery_file_dest.space_used 是否下降，也没确认 log_archive_dest_1 是否正在抢占 FRA 资源。这两个点不排查，扩再多次配额也白搭。
