ORA-19809 根源是 FRA 逻辑配额 db_recovery_file_dest_size 耗尽，与操作系统磁盘剩余无关；须查 v$recovery_file_dest 和 v$flash_recovery_area_usage 定位占用类型，用 RMAN 安全清理归档，并确保 LOG_ARCHIVE_DEST_1 指向 USE_DB_RECOVERY_FILE_DEST。
ORA-19809 不是磁盘满了，是 Oracle 快速恢复区（FRA）的逻辑配额 db_recovery_file_dest_size 耗尽了。哪怕 /u01 还剩 50G，只要这个参数设为 4G 且已写满，RMAN 就会直接报错退出。
查清 FRA 真实使用率，别信 df -h
操作系统层面的磁盘剩余和 FRA 是否够用完全无关。必须进数据库查真实占用：
-
v$recovery_file_dest给出SPACE_LIMIT（即当前db_recovery_file_dest_size值）和SPACE_USED，可算出实际使用百分比 -
v$flash_recovery_area_usage显示哪类文件占得多——如果ARCHIVED LOG占 99%，说明归档没清理；BACKUP PIECE持续增长，说明保留策略太松 - 数据库起不来时，去
$ORACLE_BASE/diag/rdbms/*/trace/alert_*.log搜ORA-19815，它会明确告诉你“已使用 100.00%, 尚有 0 字节可用”以及当前限制值
RMAN 清理归档日志最安全，别手动 rm
手动删 OS 文件会破坏控制文件记录，下次 RMAN 可能报 ORA-19625 或备份失败。正确做法是进 RMAN 执行：
-
CROSSCHECK ARCHIVELOG ALL：把 OS 上已删但控制文件还记着的归档标为EXPIRED -
DELETE EXPIRED ARCHIVELOG ALL：只删标记为EXPIRED的记录（无风险） -
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-3'：强制删掉 3 天前的所有归档（仅在业务允许丢数据时使用） -
DELETE OBSOLETE：按当前保留策略（如CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS）删“不再用于恢复”的归档和备份——但它不一定立刻腾出大量空间
调大 db_recovery_file_dest_size 要匹配物理磁盘余量
设太大但挂载点实际空间不足，Oracle 启动时会检查并可能拒绝归档，甚至实例崩溃：
- 设太小（如默认 2G/4G）：高事务库几天就满，治标不治本
- 设太大（如 100G）但挂载点只剩 20G：Oracle 仍报
ORA-19809，甚至启动失败 - 执行命令必须带
SCOPE=BOTH：ALTER SYSTEM SET db_recovery_file_dest_size = 10G SCOPE=BOTH - 改完立刻查
v$recovery_file_dest确认SPACE_LIMIT已更新，再做CROSSCHECK和DELETE
归档路径没走 FRA 是常见隐形坑
扩完大小还是报错？很可能归档根本没写进 FRA：
- 检查
LOG_ARCHIVE_DEST_1是否仍指向非 FRA 路径，比如'LOCATION=/arch' - 必须设为
'LOCATION=USE_DB_RECOVERY_FILE_DEST'，否则归档绕过 FRA，RMAN 备份时找不到它们，又会因“找不到归档”转而尝试生成更多临时备份块，间接撑爆 FRA - 闪回日志（
FLASHBACK LOG）不受 RMAN 保留策略控制，若 FRA 紧张，Oracle 会优先清理归档而非闪回日志，导致闪回能力下降；可通过v$flashback_database_log查最早可闪回时间判断是否已被截断
SCOPE 未设为 BOTH、以及误以为 df -h 能反映 FRA 状态。 
