Far Sync通过分离主库与远端备库的同步路径来规避高延迟，而非降低延迟；其必须无数据文件、仅含控制文件/SPFILE/密码文件/备用日志，且主库归档目标须指向Far Sync的SCAN并启用SYNC AFFIRM，Far Sync至备库必须ASYNC并开启STANDBY_FILE_MANAGEMENT=AUTO。
far sync 不能“减少延迟”，它绕过延迟——主库只和它同步，不和远端备库直接同步。 这是关键前提。强行让主库直连百公里外的备库走 lgwr sync，事务会卡死在 net_timeout 上；far sync 的价值在于把“高延迟链路”从主库路径里切出去，换成两条低延迟链路（主→far sync、far sync→备库）。
Far Sync 实例必须没有数据文件，否则就不是 Far Sync
这是最容易被误操作的点：有人用 DUPLICATE TARGET DATABASE FOR STANDBY 创建 Far Sync，结果生成了完整数据库（含 SYSTEM、SYSAUX 等数据文件），后续会报 ORA-16778 或启动失败。Far Sync 只能有：
-
CONTROLFILE（用ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/path/to/fs.ctl'创建） -
SPFILE或PFILE（必须含FAR_SYNC=TRUE） -
STANDBY REDO LOG（至少比在线日志多一组，如主库有 3 组，则 Far Sync 至少配 4 组） -
PASSWORD FILE（必须复制自主库，且所有节点REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE）
任何数据文件、临时表空间、undo 表空间的存在，都会导致实例无法以 MOUNT 状态启动，或在 DG Broker 中显示为 INVALID。
主库 LOG_ARCHIVE_DEST_n 必须指向 Far Sync 的 SCAN 名，且启用 SYNC AFFIRM
如果写成单节点 VIP 或主机名，DG Broker 在 Failover 后会因 SCAN 切换而断连；AFFIRM 是强制 Far Sync 将 redo 写入磁盘才返回 ACK，缺它等于白配 SYNC。
典型配置（主库执行）：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=fsync-scan SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=fsync01' SCOPE=BOTH;
注意三点：
-
SERVICE值必须解析到 Far Sync 集群的 SCAN VIP（不是某节点的 VIP） -
DB_UNIQUE_NAME必须与 Far Sync 的实际DB_UNIQUE_NAME完全一致，且已加入主库的LOG_ARCHIVE_CONFIG - 不能漏掉
VALID_FOR，否则 DG Broker 无法识别该路径在主库角色下的有效性
Far Sync 到备库必须用 ASYNC，且备库需开启 STANDBY_FILE_MANAGEMENT=AUTO
Far Sync 本身不应用日志，只转发；它到备库的链路若也设 SYNC，等于把延迟又加回去了，违背设计初衷。但这里有个隐性陷阱：
- Far Sync 转发用的是自己的
LNS进程，不是主库的——所以备库的LOG_ARCHIVE_DEST_1（接收 Far Sync 日志）必须配置ASYNC，且VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) - 主库新增表空间/数据文件时，Far Sync 不感知，但备库必须自动创建——否则
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE会报ORA-16401 - 备库的
STANDBY_FILE_MANAGEMENT=AUTO必须显式开启，不能依赖默认值（某些版本默认为MANUAL）
真正难调的不是命令怎么敲，而是网络抖动下 NET_TIMEOUT 和 REOPEN 的组合策略——主库到 Far Sync 的链路一旦超时，LGWR 会中断事务，但 Far Sync 自身无业务，它不关心重试节奏；这个窗口期里主库的可用性完全取决于你设的 NET_TIMEOUT 和底层网络稳定性，而不是 DG 配置本身。
