Far Sync在21c中配置逻辑与19c一致，但须避开两大陷阱：一是禁用已废弃的CREATE FAR SYNC INSTANCE语法；二是LOG_ARCHIVE_DEST_n中SYNC模式必须显式设置NET_TIMEOUT（建议180）和REOPEN（建议300），且控制文件须由主库生成并拷贝，实例仅能MOUNT STANDBY DATABASE，不可OPEN。
Far Sync在21c中配置逻辑与19c一致，但必须避开两个关键兼容性陷阱：一是不能用CREATE FAR SYNC INSTANCE语法（该命令在21c已废弃），二是LOG_ARCHIVE_DEST_n中SYNC模式必须搭配NET_TIMEOUT显式设置，否则主库会因默认超时过短而频繁中断传输。
Far Sync控制文件必须从主库生成，不能用CREATE CONTROLFILE
Far Sync实例没有数据文件，控制文件只能由主库生成并拷贝过去。直接在Far Sync端执行CREATE CONTROLFILE会报错ORA-01503: CREATE CONTROLFILE failed，因为缺少DATAFILE子句且不被允许。
- 主库执行：
ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/tmp/fs_control.ctl'; - scp拷贝到Far Sync主机对应路径，例如
/u01/app/oracle/oradata/fsdb/controlfs/ - Far Sync端启动前，必须用
STARTUP NOMOUNT，再用RESTORE CONTROLFILE FROM '/path/to/fs_control.ctl'（RMAN方式）或直接替换（非RMAN方式） - 切记：控制文件里
DB_NAME和DB_UNIQUE_NAME必须与主库一致，但INSTANCE_NAME需设为Far Sync实例名（如fs_toronto）
LOG_ARCHIVE_DEST_2必须显式指定NET_TIMEOUT和REOPEN
跨地域场景下网络抖动更常见，21c默认NET_TIMEOUT=30太激进，主库在30秒内未收到Far Sync确认就会标记目标为DEFERRED，导致日志堆积、ARCH进程卡住。
- 正确写法：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=fs_toronto SYNC AFFIRM NET_TIMEOUT=180 REOPEN=300 DB_UNIQUE_NAME=fs_toronto VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'; -
NET_TIMEOUT=180给足3分钟握手缓冲；REOPEN=300表示失败后每5分钟重试一次，避免瞬断引发持续告警 - 若漏掉
AFFIRM，Far Sync将无法保证同步写入磁盘，RPO≠0；若误配ASYNC，则失去Far Sync核心价值 - 验证是否生效：
SELECT DEST_ID, STATUS, TARGET, TRANSMIT_MODE, AFFIRM, NET_TIMEOUT FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;
Far Sync实例的init.ora只需最小化参数，禁用所有数据库服务
Far Sync不是普通备库，它不启动SMON、DBWn等写进程，也不挂载数据文件。任何试图让它“打开”或“应用日志”的操作都会失败。
- 必需参数：
DB_NAME（同主库）、DB_UNIQUE_NAME（唯一标识，如fs_syd）、CONTROL_FILES（指向刚拷贝的控制文件）、FAL_SERVER（可为空，但必须存在）、STANDBY_FILE_MANAGEMENT=MANUAL（禁用自动管理） - 严禁设置：
SGA_TARGET、MEMORY_TARGET、UNDO_TABLESPACE、DB_CREATE_FILE_DEST——这些会触发实例尝试加载数据文件，导致ORA-01102: cannot mount database in EXCLUSIVE mode - 启动命令严格限定为：
sqlplus / as sysdba→STARTUP NOMOUNT→ALTER DATABASE MOUNT STANDBY DATABASE;（注意不是OPEN）
最易被忽略的是：Far Sync实例的监听器必须单独配置，且tnsnames.ora中服务名要带_DGMGRL后缀（如fs_syd_DGMGRL），否则DG Broker无法识别其状态。这在21c中不是可选，而是强制要求——Broker会拒绝把未带该后缀的服务纳入SHOW CONFIGURATION输出。
