far sync实例通过将主库sync压力转移至轻量节点，在保障rpo=0前提下提升主库稳定性；其控制文件须由主库显式创建，仅含基础结构且不可打开，必须配置sync affirm指向far sync才能实现零丢失。
Far Sync 实例不能直接“降低延迟”，而是把主库的 SYNC 压力和网络抖动风险转移到一个轻量节点上，从而让主库在保持 RPO=0 的前提下更稳定——这是它真正起作用的方式。
Far Sync 实例必须用 CREATE FAR SYNC INSTANCE CONTROLFILE 创建控制文件
普通 standby 控制文件无法复用：Far Sync 是无数据文件、不打开数据库的特殊角色，它的控制文件必须由主库显式生成。如果直接拷贝主库或备库的控制文件，启动时会报 ORA-16794: database is not in far sync instance role 或卡在 MOUNT 状态。
- 主库执行：
ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/path/to/fs.ctl'; - 该控制文件只含基础结构（DBID、thread、redo 日志位置等），不含任何数据文件记录
- 传输到 Far Sync 节点后，必须用它启动，且不能执行
ALTER DATABASE OPEN——它永远处于 MOUNT 状态
LOG_ARCHIVE_DEST_n 中的 SYNC AFFIRM 必须指向 Far Sync，不能指向远端备库
这是实现 RPO=0 的关键链路。主库配置 LOG_ARCHIVE_DEST_2='SERVICE=fs_inst SYNC AFFIRM ...' 后，LGWR 进程才会等待 Far Sync 写入并确认 redo；而 Far Sync 自身再通过 ASYNC 方式转发给远端备库，这样既保障主库不因跨机房网络波动挂起，又避免了单次传输失败导致主库事务阻塞。
- 主库侧：只有
SYNC AFFIRM到 Far Sync 才算“最大可用性”模式；若误配成ASYNC，RPO 就不再是 0 - Far Sync 侧：自身不需要
LOG_ARCHIVE_DEST_n指向主库（它不拉日志），只需配置指向备库的异步路径即可 - 常见错误：把
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)错写成(ALL_LOGFILES,STANDBY_ROLE)，导致归档不触发
Far Sync 实例无需数据文件，但密码文件、tnsnames.ora 和监听必须严格对齐
Far Sync 节点资源开销极小（内存可压到 512MB 以内），但它依赖完整的网络身份认证链。少一个环节，主库就无法推送 redo。
- 密码文件必须从主库拷贝（
orapw<db_unique_name></db_unique_name>），且REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE不能改 -
tnsnames.ora中 Far Sync 的服务名要和主库LOG_ARCHIVE_DEST_n里写的完全一致（大小写、下划线都不能错） - Far Sync 节点监听必须启用静态注册，且
SID_NAME与DB_UNIQUE_NAME一致，否则主库连接时报ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
最容易被忽略的是 Far Sync 的 DB_UNIQUE_NAME 必须全局唯一，且不能和主库、备库重名——哪怕只是测试环境。一旦重名，Broker 会混淆角色，DG_CONFIG 配置失效，后续 switchover 会直接失败。这个值不是“逻辑名”，而是 Oracle 内部识别实例身份的硬编码标识。
