如何部署Far Sync实例_零数据丢失与长距离传输的结合-Oracle-PHP中文网

far sync部署前必须满足三个前提：主库开启force logging；log_archive_dest_n配置sync affirm与net_timeout≤30并指向far sync的db_unique_name；far sync主机能稳定访问主库传输端口且时间偏差≤5秒。

far sync 实例部署前必须确认的 3 个前提

Far Sync 不是加台机器就能用的“插件”，它本质是 Oracle Data Guard 架构中一个特殊角色的物理 standby，依赖主库的实时归档（ARCHIVELOG + FORCE LOGGING）和网络低延迟同步能力。没满足这三点，部署完也起不来，或者起得来但不生效。

FORCE LOGGING 必须在主库开启：否则 DML 操作可能绕过重做记录，Far Sync 收不到完整变更流
主库 LOG_ARCHIVE_DEST_n 配置必须包含 SYNC AFFIRM + NET_TIMEOUT（建议 ≤30），且目标指向 Far Sync 的 DB_UNIQUE_NAME
Far Sync 实例所在主机必须能稳定访问主库的 standby redo logs 传输端口（默认 1521），且时间偏差 ≤5 秒（ntpd 或 chronyd 必须跑着）

创建 Far Sync 实例时最容易配错的参数

Far Sync 不开实例进程、不挂数据文件、不启 MRP，但它对 init.ora 参数极其敏感。常见错误是照搬普通 standby 的配置，结果启动报 ORA-16664: unable to retrieve the result from a database 或反复断连。

FAL_SERVER 和 FAL_CLIENT 必须设为空（''）：Far Sync 不参与归档缺失拉取，设了反而触发无意义重试
DB_UNIQUE_NAME 必须与 LOG_ARCHIVE_DEST_n 中指定的一致，大小写敏感；主库配置里写的是 far_sync_01，这里就不能写成 FarSync01
STANDBY_FILE_MANAGEMENT 必须为 MANUAL：Far Sync 不管理数据文件，设 AUTO 会导致启动卡在控制文件验证阶段
LOG_ARCHIVE_CONFIG 要显式列出所有参与节点，例如：'DG_CONFIG=(primary_db,far_sync_01,physical_standby_01)'，漏掉任意一个，DGMGRL 就认不出拓扑

Far Sync 启动后立刻要验证的 2 个关键状态

启动 SQL*Plus 连上去看到 OPEN MODE = READ ONLY WITH APPLY 并不表示 Far Sync 在工作——它压根不该 open。真正有效的状态藏在后台日志和 DG 视图里。

查 V$DATAGUARD_STATS：重点关注 transport lag 和 apply lag，二者都应稳定在 +00 00:00:00；若 transport lag 持续增长，说明主库归档没成功推到 Far Sync 的 standby redo log
查 V$ARCHIVE_DEST_STATUS：对应 Far Sync 的 DEST_ID 行，STATUS 必须是 VALID，ERROR 列为空，TRANSMIT_MODE 是 SYNC，DELAY_MINS 是 0
别信 SELECT DATABASE_ROLE FROM V$DATABASE：Far Sync 返回 PHYSICAL STANDBY 是对的，不是 bug；但它不会显示 FAR SYNC 字样——这个角色只在 DGMGRL SHOW CONFIGURATION 里体现

主库切换后 Far Sync 自动失效的典型表现与修复

Far Sync 在 switchover 后不会自动重连新主库，这是设计使然，不是故障。现象是原主库变 standby 后，Far Sync 日志里持续刷 ORA-16778: redo transport error，DG Broker 显示 Warning: ORA-16778，但不报错也不告警。

必须手动在新主库上执行：ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=far_sync_01 SYNC AFFIRM NET_TIMEOUT=30 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=far_sync_01';（注意 DEST_2 编号要和原配置一致）
Far Sync 本体不需要重启，但需在新主库上执行 ALTER SYSTEM SWITCH LOGFILE 触发一次归档推送，之后观察 V$ARCHIVE_DEST_STATUS 是否恢复 VALID
如果用了 DGMGRL，切完后立即运行 EDIT DATABASE 'far_sync_01' SET PROPERTY 'LogXptMode'='SYNC';，否则 Broker 可能沿用旧模式缓存

Far Sync 的“零丢失”保障完全依赖主库归档流的完整性校验，而这个校验只发生在主库侧。任何网络抖动、防火墙策略变更、甚至临时 DNS 解析失败，都会让 transport lag 突然跳升——监控不能只看是否连接，得盯住秒级 lag 值本身。