跨地域data guard无法消除网络延迟，因rtt由物理距离决定（如北京到新加坡rtt≥120ms），sync模式要求主库等待备库确认，导致事务响应变慢、tps断崖下跌，故仅适用于同城或同az场景。
跨地域 Data Guard 无法消除网络延迟，但可以通过 Far Sync + 异步复制组合把对主库的影响降到最低。
为什么不能靠调参数解决跨地域延迟
往返延迟（RTT）是物理距离决定的，比如北京到新加坡单向约 60ms，RTT 就至少 120ms。Oracle 同步模式（SYNC）要求主库等备库确认才提交，这直接拖慢事务响应。哪怕你把 SDU 调到 32767、SEND_BUF_SIZE 算出 9MB，也改变不了光速限制。
常见误操作是强行在跨地域场景配 LOG_ARCHIVE_DEST_n 的 SYNC 属性，结果主库大量 log file sync 等待，TPS 断崖下跌。
- 同步模式只适合同城或同 AZ（RTT
- 跨地域必须用异步（ASYNC），否则主库性能不可控
-
STANDBY_MAX_DATA_DELAY=0在跨地域下无效，它不强制实时，只影响监控字段显示
Far Sync 是跨地域低延迟的关键组件
Far Sync 实例不是真正备库，它不存数据、不提供查询，只做重做日志中转。主库和 Far Sync 之间走 SYNC，Far Sync 和远端备库之间走 ASYNC。这样主库只承担本地网络延迟，而远端延迟由 Far Sync 承担。
部署要点：
- Far Sync 必须和主库在同一 Azure 区域（或 OCI region），确保 RTT ≤ 2ms
- Far Sync 的
LOG_ARCHIVE_DEST_2指向远端备库，且必须设为ASYNC NOREGISTER - 主库的
LOG_ARCHIVE_DEST_1指向 Far Sync，设为SYNC AFFIRM - Far Sync 实例本身不需要开启
RECOVER MANAGED STANDBY DATABASE，只需启动并监听归档传输
网络层必须配合调整，否则 Far Sync 会成瓶颈
Far Sync 是流量中继点，它的网卡、TCP 栈、Oracle Net 配置都要单独优化，否则会卡在中间。
重点配置项（主库、Far Sync、备库三端都要检查）：
-
sqlnet.ora中统一设DEFAULT_SDU_SIZE=32767，避免大小不一致导致分片重传 -
tnsnames.ora连接描述符里加SEND_BUF_SIZE和RECV_BUF_SIZE，值按公式3 * 带宽(Mbps) * 延迟(ms) / 8算（例如 1Gbps + 2ms → ≈ 750KB） - Linux 上调大网卡队列：
ip link set dev eth0 txqueuelen 10000，并确认net.core.netdev_max_backlog≥ 5000 - 禁用 Far Sync 主机上的 Network Virtual Appliance（NVA）、防火墙深度包检测（DPI），每个额外跃点增加 0.5–2ms
监控不能只看 V$DATAGUARD_STATS
这个视图里的 apply lag 是估算值，跨地域场景误差常达数秒。真正要盯的是：
- 主库查
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER FROM DUAL，记下 SCN - 立刻在 Far Sync 上执行同样语句，差值除以每秒 SCN 增速（查
V$DATAGUARD_STATS的estimated startup time反推）→ 得出真实传输延迟 - Far Sync 的
V$MANAGED_STANDBY中PROCESS='LNS'状态必须是WRITING，PROCESS='RFS'在远端备库上必须是IDLE或WAITING FOR LOG，若长期CONNECTING说明网络连通性有问题
Far Sync 本身不落盘、不应用日志，所以它的磁盘 I/O 和 CPU 压力极低；一旦发现它 CPU 占用高或 RFS 进程卡住，基本就是 Oracle Net 层配置没对齐，或者底层网络抖动被 TCP 重传掩盖了。
