ORA-16401不是错误，而是RFS发现重复归档时的信息性提示；只要v$archive_gap无缺口、APPLIED持续更新，就无需干预，其本质是多归档源写入同一路径导致的重复尝试。
ORA-16401不是错误，是RFS的日志提示
ORA-16401 archivelog rejected by RFS 本质不是故障，而是备库 RFS 进程发现重复归档文件时写入的诊断信息。只要 v$archive_gap 查询结果为空、APPLIED 列持续更新，就说明日志应用正常，无需处理。
为什么RFS会频繁报ORA-16401？
根本原因是多个归档源往同一物理路径写入相同序列号的归档文件。典型场景包括：
- 主库通过
log_archive_dest_2向备库传输归档，目标路径设为/u01/arch - 备库自身又配置了
log_archive_dest_1 = LOCATION='/u01/arch'或standby_archive_dest = '/u01/arch' - 结果：主库传来的
1_34801_692846987.dbf和备库自己归档生成的同名文件冲突，RFS拒绝二次写入
怎么确认是路径重叠导致的？
检查备库 alert.log 中 ORA-16401 前后几行：
- 是否有连续两条
Media Recovery Log /path/to/1_xxx_yyy.dbf？→ 表明该日志已被成功应用 - 是否有
RFS[2]: Successfully opened standby log？→ 表明RFS进程工作正常 - 执行
show parameter log_archive_dest和show parameter standby_archive_dest，看是否存在路径完全一致
如何安全调整归档路径避免重复？
不建议禁用归档目标，应明确分离本地归档与接收归档的路径：
- 备库的
log_archive_dest_1必须设为LOCATION=USE_DB_RECOVERY_FILE_DEST或独立目录（如/u02/arch_local），不能和standby_archive_dest相同 -
standby_archive_dest应保持默认值（?/dbs/arch）或显式指向主库传输归档的专用目录（如/u01/arch_remote） - 修改后执行
alter system set log_archive_dest_1='' scope=both;即可生效，无需重启实例 - 切勿在备库启用
log_archive_dest_2（除非真要做级联 DG），否则它会主动归档并再次撞上主库传来的文件
真正需要警惕的是 ORA-16401 伴随 Media Recovery Waiting for thread X sequence Y 长时间不推进——这时该查 FAL 配置、网络连通性、磁盘空间，而不是盯着 ORA-16401 本身。
