Far Sync实例必须部署在主库网络延迟≤5ms处，同机房或同城双中心，启用FORCE LOGGING且禁用SACK；Broker配置需显式ADD FAR_SYNC，监听器须注册主库DB_UNIQUE_NAME。
Far Sync 实例必须部署在主库网络延迟 ≤ 5ms 的位置
Far Sync 不是“随便放个中间节点”，它本质是主库 LGWR 进程的延伸。Oracle 要求 LGWR SYNC AFFIRM 到 Far Sync 的往返时间（RTT）稳定低于 5ms，否则会触发日志传输超时、ORA-16709 或持续重传。某次客户把 Far Sync 部署在跨城机房（RTT=18ms），结果主库每秒产生 200+ log file sync 等待，TPS 直接腰斩。
实操建议：
- 用
ping -c 5 far-sync-host和tcpping -x 5 far-sync-host 1521双测，确认平均 RTT ≤ 3ms、无丢包 - Far Sync 主机必须与主库同机房或同城双中心（光纤直连），禁止跨省、跨运营商骨干网
- 操作系统内核需关闭
tcp_tw_reuse和启用net.ipv4.tcp_sack=0（避免 SACK 在高延迟链路引发重传放大）
Far Sync 实例不能有数据文件，但必须启用 FORCE LOGGING
Far Sync 是纯日志中继节点，不存储任何用户数据块，所以它的 DATAFILE 目录为空，DB_CREATE_FILE_DEST 可设为 /dev/null 或只读挂载点。但它必须全程参与主库的 redo 生成闭环——一旦主库开启 FORCE LOGGING，Far Sync 就必须能接收并确认每一条 LGWR 发出的 redo stream。
常见错误现象：
- 主库报错
ORA-16826: unable to apply redo：Far Sync 未启用FORCE LOGGING - Broker 显示
STATUS = ORA-16766: Redo Transport Service is suspended：Far Sync 的LOG_ARCHIVE_DEST_2指向了自身（循环配置）
关键命令（在 Far Sync 实例执行）：
SQL> ALTER DATABASE FORCE LOGGING; SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=primary_db ASYNC VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=primary_db' SCOPE=BOTH;
Data Guard Broker 配置 Far Sync 时必须显式声明 FAR_SYNC 属性
Broker 不会自动识别 Far Sync 实例，如果只用 ADD DATABASE 加入，它会被当作普通物理备库处理，导致 switchover 失败、DGMGRL 无法正确计算 RPO、甚至误将 Far Sync 切换为主库。
正确做法是使用 ADD FAR_SYNC 子句，并确保其 DB_UNIQUE_NAME 与主库 LOG_ARCHIVE_CONFIG 中声明的一致：
DGMGRL> ADD FAR_SYNC 'fsync01' AS CONNECT IDENTIFIER IS fsync01; DGMGRL> EDIT DATABASE 'primary_db' SET PROPERTY 'LogXptMode'='SYNC'; DGMGRL> EDIT FAR_SYNC 'fsync01' SET PROPERTY 'PreferredApplyInstance'='';
注意：PreferredApplyInstance 必须为空（不是 NULL），否则 Broker 会尝试启动一个不存在的 APPLY 进程，报错 ORA-16778。
级联路径中 Far Sync 到备库必须用 ASYNC，且备库不可再配置 Far Sync
Far Sync 的设计目标是卸载主库同步压力，不是构建多跳日志链。Oracle 明确不支持 Far Sync → Far Sync → 备库这种嵌套结构。真实生产中唯一被验证的拓扑是：primary_db → fsync01 (SYNC) → standby_db (ASYNC)。
性能与风险提示：
- 从 Far Sync 到备库的
LOG_ARCHIVE_DEST_3必须设为ASYNC，否则 Far Sync 自身会成为单点瓶颈 - 备库若也配 Far Sync，Broker 无法确定角色转换路径，
SWITCHOVER TO standby_db会卡在Waiting for far sync instance to become ready - Far Sync 故障时，主库自动降级为异步直传备库（前提是主库配置了
LOG_ARCHIVE_DEST_3备用路径），这是最大可用性模式的核心保障机制
最易被忽略的一点：Far Sync 实例的 listener.ora 中，SID_LIST_LISTENER 必须包含主库的 DB_UNIQUE_NAME，否则主库 LGWR 连不上——这个细节在 tnsping fsync01 成功但日志传输失败时，往往要查到 $ORACLE_HOME/network/log/listener.log 才能定位。
