far sync是oracle 12c引入的轻量级中继节点，仅接收并转发redo，不应用、不开库、不承载业务；用于拆分长距离dg链路以保障rpo=0。
Far Sync 不是 Extended RAC，也不替代 Data Guard Broker；它只是 DG 物理备库链路中的一个“中继节点”，必须配合 ADG 使用，且不能承担业务流量。
Far Sync 实例的本质和适用场景
Far Sync 是 Oracle 12c 引入的轻量级物理 standby 类型，只做重做接收与转发，不应用、不开库、不提供服务。它的唯一价值是：在主库与异地物理备库之间网络延迟高（如跨城 >5ms）、带宽受限或抖动明显时，把“主库 → 备库”的单跳长链路拆成“主库 → Far Sync → 备库”两段短链路，从而规避因网络问题导致的主库归档阻塞（ARCH hang）或 LGWR SYNC 超时失败。
典型使用场景包括：
- 主库在 A 机房，物理备库在 C 机房（距离远、RTT 高），中间 B 机房部署 Far Sync 实例（与 A 同城或近距，RTT ≤2ms）
- 主库启用
MAXIMUM AVAILABILITY模式，但直接连异地备库常报ORA-16198（timeout in network communication） - 希望保留同步保护级别，又无法拉通 A↔C 的低延迟二层网络（即不具备 Extended RAC 条件）
Far Sync 部署的四个硬性前提
漏掉任意一条，DGMGRL ENABLE CONFIGURATION 会直接失败或后续切换异常：
-
DB_UNIQUE_NAME必须三地互异：主库（如rac_primary）、Far Sync（如far_sync01）、物理备库（如adg_standby），且全部显式设置，不可用默认值 - Far Sync 实例必须运行在独立主机（不能与主库或备库共节点），且操作系统时间与主库偏差
≤5s（ntpq -p验证） - Far Sync 的
CONTROL_FILES必须指向本地磁盘（不能 ASM 或共享存储），且DB_CREATE_FILE_DEST也必须是本地路径——它不参与数据块管理 - Far Sync 的监听器必须静态注册
GLOBAL_DBNAME = <db_unique_name>_DGMGRL.<domain></domain></db_unique_name>，例如far_sync01_DGMGRL.example.com；否则dgmgrl连不上，报ORA-12154
Far Sync 初始化的关键操作顺序
不能先启实例再加进 Broker，也不能用 DUPLICATE TARGET DATABASE FOR STANDBY 直接克隆——Far Sync 必须从主库备份 + 归档恢复构建，且跳过应用阶段：
- 在主库执行
BACKUP DATABASE PLUS ARCHIVELOG，将备份集及归档拷至 Far Sync 主机本地 - Far Sync 主机上用
RMAN DUPLICATE TARGET DATABASE FOR STANDBY，但必须加NOFILENAMECHECK和DORECOVER，且SET UNTIL SCN要略高于备份完成 SCN - 恢复完成后，立即执行
ALTER DATABASE CONVERT TO FAR SYNC（不是PHYSICAL STANDBY） - 启动 Far Sync 实例到
MOUNT状态，确认V$DATABASE.DATABASE_ROLE = 'FAR SYNC'，再用dgmgrl加入配置
常见错误：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 在 Far Sync 上执行会报 ORA-16661（not allowed for far sync instance）——它压根不跑 MRP 进程。
Broker 配置中容易被忽略的三个参数
Far Sync 在 Broker 中不是“普通备库”，它的角色决定了以下三项必须显式设置，否则主库归档可能卡住或自动降级为异步：
-
LogXptMode在 Far Sync 上必须设为SYNC（即使主库是ASYNC，Far Sync 到主库这段也应强同步） -
ReopenSecs建议设为30（默认 300），避免网络瞬断后长时间不重连 -
NetTimeout必须 ≤ 主库LOG_ARCHIVE_DEST_n的NET_TIMEOUT，否则 Broker 会误判 Far Sync “不可达”而切走流量
验证是否生效：主库上查 V$ARCHIVE_DEST_STATUS，对应 Far Sync 的 STATUS 应为 VALID，TRANSMIT_MODE 为 SYNC，DELAY_MINS 为 0。若出现 DEFERRED 或 ERROR，优先检查 Far Sync 的监听日志和 ALERT.log 中的 TNS 连接尝试记录。
Far Sync 最脆弱的环节不在 Oracle 层，而在网络可达性与时间同步精度——它不像物理备库有容错缓冲，一旦 Far Sync 实例不可达，主库会立即降级为异步传输，RPO 保障失效。上线前务必用 tnsping 和 sqlplus /@far_sync01_DGMGRL 在主库所有节点上交叉验证连通性，并持续监控 MRP 进程在 Far Sync 上的存活状态（虽然它不启动，但 Broker 依赖其监听端口响应心跳）。
