Far Sync是主库与远端备库间必须插入的同步中继节点，非可选组件；它无数据文件，仅靠控制文件、密码文件和参数文件启动，不执行CREATE DATABASE或RESTORE，控制文件须由主库ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE生成，且需配置VALID_FOR、SYNC AFFIRM、standby redo log及网络连通性。
Far Sync不是可选组件，而是主库与远端备库之间必须插入的同步中继节点；不配它，主库在跨地域场景下无法兼顾零丢失和低延迟。
Far Sync实例没有数据文件，只靠控制文件 + 密码文件 + 参数文件启动
很多人卡在启动阶段，报错 ORA-01102: cannot mount database in EXCLUSIVE mode 或 ORA-01507: database not mounted，本质是误把它当完整数据库来建。Far Sync 实例不存数据，所以：
• 不需要 CREATE DATABASE，也不执行任何 RESTORE 或 DUPLICATE
• 控制文件必须用主库上 ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE 生成，不能用 BACKUP CURRENT CONTROLFILE
• 密码文件直接从主库复制，但需确保 remote_login_passwordfile=EXCLUSIVE 且用户名一致（通常是 SYS）
• pfile 中必须显式指定 DB_UNIQUE_NAME、FAL_SERVER 和 LOG_ARCHIVE_CONFIG，漏掉任意一个都会导致归档传输失败
LOG_ARCHIVE_DEST_n 配置必须区分角色和日志类型
主库上的归档目标配置是 Far Sync 能否正常收发 redo 的核心。常见错误是把 LOG_ARCHIVE_DEST_2 和 LOG_ARCHIVE_DEST_3 的 VALID_FOR 值写反或混用：
• LOG_ARCHIVE_DEST_2 指向 Far Sync，必须设为 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，且带 SYNC AFFIRM
• LOG_ARCHIVE_DEST_3 指向终端备库，必须设为 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 或 (STANDBY_LOGFILES,STANDBY_ROLE)，并用 ASYNC NOAFFIRM
• LOG_ARCHIVE_DEST_STATE_n 必须显式设为 ENABLE，不能依赖默认值
• 如果启用了 Broker，所有 LOG_ARCHIVE_DEST_n 配置会被覆盖，必须先停用 Broker 或改用 DGMGRL 管理
Far Sync 启动后必须手动添加 standby redo log 组
Far Sync 实例虽无数据文件，但必须有 standby redo log 才能接收并转发 redo。遗漏这步会导致主库归档挂起、ARCH 进程持续报错 ORA-16055: FAL request rejected：
• 大小建议与主库 online redo log 一致（例如 SIZE 200M）
• 组数至少比主库 online redo log 多 1 组（如主库有 3 组，则 Far Sync 至少建 4 组）
• 路径需提前创建，且 Oracle 用户要有写权限，否则 ALTER DATABASE ADD STANDBY LOGFILE 会静默失败
• 添加后必须重启 Far Sync 实例才能生效，仅 ALTER SYSTEM SWITCH LOGFILE 不触发加载
网络连通性和防火墙规则最容易被忽略
Far Sync 对网络延迟极度敏感，但实际部署中 70% 的问题出在基础连通性上：
• 主库 → Far Sync 必须双向开放 1521 端口（TNS 监听 + redo 传输）
• Far Sync → 备库同样要开 1521，且 TNSNAMES.ora 中 service_name 必须与备库 DB_UNIQUE_NAME 完全一致
• OCI 或 Azure 环境下，VCN 对等互连路由表里必须包含对方 subnet CIDR，并启用动态路由网关（DRG）
• 不要用 tnsping 验证，它只测监听，必须用 sqlplus /@farsync_service 实际连接测试
Far Sync 的脆弱点不在配置逻辑，而在于它对环境假设极强：控制文件必须由主库生成、密码文件必须原样复制、standby redo log 必须手工添加、网络路径必须单向低延迟——四个条件缺一不可，任一环节走捷径都会导致同步链路静默中断。
