ORA-19809错误本质是FRA逻辑配额（db_recovery_file_dest_size）耗尽，非磁盘物理空间不足；须查v$recovery_file_dest和v$flash_recovery_area_usage确认实际使用率与文件类型占比，再通过RMAN清理归档或合理扩容配额。
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持续增长？保留策略太松 -
show parameter db_recovery_file_dest和show parameter db_recovery_file_dest_size确认参数是否生效（scope是both还是memory）
如果数据库起不来，就去 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）删“不再用于恢复”的归档和备份——但它不一定立刻腾出大量空间
清理后跑 LIST RECOVERY AREA 确认空间释放，别只看 DELETE 输出的 “deleted”。
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
数据库 hang 住登不进去怎么办
19c+ 版本中，FRA 耗尽后 sqlplus / as sysdba 也可能卡住，不是网络或监听问题，就是 FRA 满导致内部等待：
- 别硬等，先
ps -ef | grep pmon找到主进程 PID，kill -9强制终止实例 - 用
CREATE PFILE FROM SPFILE导出参数文件，手动修改db_recovery_file_dest_size - 再
CREATE SPFILE FROM PFILE，重启库 - 起来后第一件事：查
v$flash_recovery_area_usage，优先清理归档，而不是立刻扩容
真正容易被忽略的是：FRA 路径（db_recovery_file_dest）挂载的文件系统本身是否有足够物理空间——参数调得再大，底层没空间，照样崩。
