根本原因是RAC双节点不共享FRA空间使用状态，各自独立检查db_recovery_file_dest_size；必须确保两节点的db_recovery_file_dest指向完全相同的ASM磁盘组路径（如+FRA/orcl/），且DB_UNIQUE_NAME与路径中数据库名严格一致。
ORA-19809 超出FRA空间限制，但db_recovery_file_dest_size明明设得够大
根本原因不是参数没调够，而是双节点rac下两个实例各自往同一fra目录写归档，却**不共享fra空间使用状态**。每个实例只管自己写的量，各自检查db_recovery_file_dest_size，导致实际总用量超限却无感知。
实操建议：
- 必须启用
archive_lag_target配合log_archive_dest_1显式指向共享FRA路径（如+FRA/orcl/archivelog），禁用隐式归档到本地文件系统 - 确认两个节点的
db_recovery_file_dest指向**完全相同的ASM磁盘组路径**（不是相同挂载点名，是ASM别名一致），且该磁盘组为NORMAL或HIGH冗余 - 定期在任一节点执行：
sqlplus / as sysdba <<EOF SELECT * FROM V$RECOVERY_FILE_DEST; SELECT * FROM V$FLASH_RECOVERY_AREA_USAGE; EXIT EOF
注意看SPACE_LIMIT和SPACE_USED是否跨节点同步更新——若不一致，说明FRA未真正被双实例识别为共享资源
归档日志在节点A生成，节点B却查不到V$ARCHIVED_LOG记录
RAC中归档日志物理文件虽在共享存储上，但V$ARCHIVED_LOG是实例级视图，默认只显示本实例归档过的日志。这不是数据丢失，是视图范围问题。
实操建议：
- 查全局归档状态，必须用
GV$ARCHIVED_LOG，加INST_ID列区分来源：SELECT INST_ID, NAME, FIRST_TIME, NEXT_TIME FROM GV$ARCHIVED_LOG WHERE TRUNC(FIRST_TIME) = TRUNC(SYSDATE) ORDER BY FIRST_TIME;
- 确保
cluster_database = TRUE且两个实例都已启动并加入集群（crsctl stat res -t | grep ora.orcl.db应显示ONLINE） - 检查
log_archive_dest_1是否含VALID_FOR=(ALL_LOGFILES,ALL_ROLES)，缺这个会导致备库角色切换后归档路径失效
手动删除FRA里旧归档后，RMAN DELETE ARCHIVELOG报错ORA-19602
直接用OS命令删ASM里的归档文件，会破坏RMAN仓库与物理文件的一致性。RMAN仍认为这些日志存在，下次备份或清理时就撞上ORA-19602: cannot backup or copy active file in NOARCHIVELOG mode这类误报。
实操建议：
- 永远通过RMAN删除：
RMAN TARGET / DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';
而非asmcmd rm或操作系统rm - 如果已误删，先运行
CROSSCHECK ARCHIVELOG ALL;再DELETE EXPIRED ARCHIVELOG ALL;，强制同步元数据 - 在RAC中，该RMAN会话需连接到任意一个实例（无需分别连两节点），RMAN自动处理跨实例元数据刷新
配置FRA时db_recovery_file_dest该用ASM路径还是NFS挂载点
用NFS挂载点看似简单，但在RAC中极易引发I/O争用、锁等待甚至脑裂。Oracle官方明确要求FRA在RAC中必须位于**集群可访问的共享存储**，ASM是首选，NFS仅限测试且需满足特定内核参数与挂载选项。
实操建议：
- 生产环境只接受ASM磁盘组，路径格式必须是
+DISKGROUP_NAME/dbname/...，不能是/u01/app/oracle/fast_recovery_area这种本地路径 - 若非用NFS不可，挂载时必须加
hard,intr,rsize=32768,wsize=32768,noac，且所有节点挂载参数严格一致 - 验证共享性：在节点A创建空文件
touch +FRA/test.$$，立刻在节点B执行ls +FRA/test.$$，失败即说明ASM别名未同步或权限不对
最易被忽略的是：FRA路径中的数据库名（如+FRA/orcl/）必须与DB_UNIQUE_NAME完全一致，大小写敏感，拼错一个字符，两个节点就会各自建私有子目录，彻底失去共享效果。
