ORA-16401不是故障，而是RFS发现归档日志已存在时发出的信息性提示；只要v$archive_gap无缺口、APPLIED持续更新，就无需干预，其本质是主库因日志切换过快或网络延迟触发重复归档尝试，19c因默认启用LGWR ASYNC及更激进GAP检测机制使该提示更频繁。
ora-16401 不是故障，而是 rfs 进程发现归档日志已存在时发出的信息性提示；只要备库 v$archive_gap 无缺口、applied 状态持续更新，就无需干预。
为什么 ORA-16401 在 19c 中仍频繁出现
该错误本质是“重复归档尝试”：主库因日志切换过快或网络延迟，触发 FAL 请求补传某序列号归档，但此时该归档已在传输中或已落盘，RFS 拒绝二次写入。19c 并未改变这一行为逻辑，反而因默认启用 LGWR ASYNC 和更激进的 GAP 检测机制，使该信息更容易被记录。
常见诱因包括：
-
log_archive_dest_n配置了多个指向同一备库的 destination（例如log_archive_dest_2和log_archive_dest_3同时指向 standby A） - 主库刚完成 Switchover，但
log_archive_config未同步更新，残留旧db_unique_name，导致部分归档路径解析失败后重试 - 备库
standby_archive_dest与log_archive_dest_1路径相同，造成主库归档和 RFS 接收归档写入同一目录 - 网络抖动或带宽不足，使 ARC 进程未能及时确认前一个归档传输完成，便发起下一个
检查是否真影响同步的三个关键命令
别只看 alert.log 报错，先确认数据一致性：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; —— 若返回空行，说明无物理 GAP
SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG WHERE NAME IS NOT NULL ORDER BY FIRST_TIME DESC FETCH FIRST 5 ROWS ONLY; —— 查看最近 5 条归档的 APPLIED 值是否为 YES
SELECT STATUS, GAP_STATUS, ERROR FROM V$MANAGED_STANDBY WHERE PROCESS IN ('RFS', 'MRP0'); —— RFS 状态应为 IDLE 或 RECEIVING，MRP0 应为 APPLYING_LOG
必须改的配置项（19c 实际生效要点）
Oracle 19c 对参数校验更严格，以下修改需在 spfile 中执行并重启实例才可靠：
- 若备库
standby_archive_dest和log_archive_dest_1路径重叠，用ALTER SYSTEM RESET standby_archive_dest SCOPE=SPFILE;清除它 —— 19c 默认不依赖该参数，RFS 会按log_archive_dest_n的LOCATION或SERVICE自动路由 - 主库上禁用冗余归档路径：
ALTER SYSTEM SET log_archive_dest_3='' SCOPE=BOTH;（假设_3是误配项），再查v$archive_dest确认STATUS变为INACTIVE - 确保
log_archive_config两端一致：ALTER SYSTEM SET log_archive_config='DG_CONFIG=(primary_db,standby_db)' SCOPE=BOTH;，其中primary_db和standby_db必须与各自db_unique_name完全匹配（区分大小写）
真正需要警惕的伴随现象
ORA-16401 单独出现基本无害，但若同时观察到以下任一情况，说明底层链路已出问题：
-
v$managed_standby中RFS的STATUS长期为CONNECTED但无RECEIVING，且MRP0状态卡在WAIT_FOR_LOG - alert.log 中紧随
ORA-16401出现ORA-16055或ORA-16766（表示 FAL 请求连续失败） - 备库
trace文件（如*_rfs_*.trc）里反复出现kcrrwkx: unknown error:16401+Log read is SYNCHRONOUS though disk_asynch_io is enabled!—— 这暗示 I/O 层异常，需检查存储挂载、权限或 ASM diskgroup 状态
这类组合信号才代表归档传输通道实质性中断，不能仅靠“忽略错误”应对。
