RAC主库归档传输由LOG_ARCHIVE_DEST_n的SERVICE指向的SCAN服务决定，需配置LOAD_BALANCE=on和FAILOVER=on；ARCH进程不跨节点迁移，但多节点冗余保障传输连续性。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 不会自动切换传输节点——RAC 主库的归档日志传输由 LOG_ARCHIVE_DEST_n 配置驱动，不是靠备库命令触发的。真正决定“哪个 RAC 节点负责发日志”的，是主库上 LOG_ARCHIVE_DEST_2（或对应备库目标）的 SERVICE 属性指向的 TNS 服务名，以及该服务在 tnsnames.ora 中的配置方式。
LOG_ARCHIVE_DEST_n 的 SERVICE 必须指向 SCAN 名称或负载均衡服务
RAC 主库多节点环境下，归档传输不能硬编码到单个实例（如 service=racdb1），否则当该节点宕机，ARCH 进程无法连接，传输中断，V$ARCHIVE_DEST_STATUS.STATUS 会变成 ERROR，GAP_STATUS 可能变为 YES。
正确的做法是：
-
LOG_ARCHIVE_DEST_2中的SERVICE指向一个定义在tnsnames.ora中的 SCAN 服务名（例如SERVICE = racdb_scan） - 该 SCAN 服务在
tnsnames.ora中必须启用LOAD_BALANCE=on和FAILOVER=on - 示例：
racdb_scan = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = racdb) (FAILOVER_MODE = (TYPE = SESSION)(METHOD = BASIC)) ) (LOAD_BALANCE = on) )
这样，当 ARCH 进程尝试连接时，即使当前节点宕机，Oracle 客户端会自动尝试其他存活节点，无需人工干预。
ARCH 进程本身不跨节点迁移，但归档传输可自动恢复
RAC 中每个实例有独立的 ARCH 进程，只归档本实例生成的 redo。某节点宕机后：
- 该节点的
ARCH进程终止，它未完成的归档任务不会被其他节点接管 - 但只要其他节点仍在运行且 redo 日志正常切换（
log switch），这些节点的ARCH就会继续归档并发送到备库 - 所以传输“看起来”没断，实际是靠剩余存活节点持续工作，不是“自动切换传输源”，而是“多源冗余下天然具备连续性”
关键前提是：所有节点的 LOG_ARCHIVE_DEST_n 配置一致，且都指向同一个高可用 TNS 服务。
常见错误现象与排查点
-
V$ARCHIVE_DEST_STATUS.ERROR出现ORA-12545或ORA-12170→ 检查tnsnames.ora中 SERVICE 对应的 HOST 是否可解析、端口是否通、监听是否运行（lsnrctl status） -
GAP_STATUS = YES且STATUS = VALID→ 表示归档已传过去，但备库还没应用，和主库节点宕机无关，要查备库的 MRP 进程状态（V$MANAGED_STANDBY中PROCESS = MRP0且STATUS = APPLYING_LOG） - 切换后发现备库
transport lag突增 → 很可能是主库剩余节点的ARCH进程压力陡增，或网络带宽被挤占，需检查V$ARCHIVE_DEST_STATUS.DELAY_MINS和操作系统网络队列
自动传输不依赖 Broker，也不需要重启数据库；但它极度依赖 TNS 层的容错配置。漏掉 FAILOVER=on 或误用 VIP 地址代替 SCAN，是生产环境最常踩的坑——表面正常，一节点挂就断传。
