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 客户端会自动尝试其他存活节点，无需人工干预。

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

---

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，是生产环境最常踩的坑——表面正常，一节点挂就断传。