Far Sync实例必须用专用控制文件，因其无数据文件、不应用日志、不维护SCN，Oracle强制要求主库显式生成不含物理结构元数据的最小化控制文件，否则启动报错ORA-01122或ORA-16664。
Far Sync 实例不能直接用 RMAN duplicate 创建，必须用 ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE 生成专用控制文件；否则实例无法启动到 STARTUP NOMOUNT 之后的阶段。
为什么 Far Sync 实例必须用专用控制文件？
Far Sync 不是普通物理备库，它没有数据文件、不应用日志、不维护 SCN 一致性，只做 redo 中转。Oracle 强制要求其控制文件由主库显式生成，且该控制文件里不含数据文件路径、检查点信息等物理结构元数据。
常见错误现象：
- 手动复制主库控制文件后启动 Far Sync，报错
ORA-01122: database file 1 failed verification check - 用
RMAN DUPLICATE TARGET DATABASE FOR STANDBY创建，启动时报ORA-16664: unable to receive the result from a database
正确做法：
- 在主库执行：
ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/path/to/farsync.ctl'; - 该语句仅生成一个最小化控制文件，不触发 checkpoint，也不校验数据文件
- 生成后立即 scp 到 Far Sync 主机对应路径，并确保权限为
oracle:oinstall
Far Sync 的 pfile 必须禁用所有数据文件相关参数
Far Sync 实例启动时若读到 db_file_name_convert、standby_file_management=AUTO 或任何含 DB_CREATE_FILE_DEST 的配置，会尝试解析或创建数据文件，直接导致 ORA-01102: cannot mount database in EXCLUSIVE mode 或挂起。
关键参数差异：
- 必须显式设置：
DB_UNIQUE_NAME=farsync_name（需与LOG_ARCHIVE_CONFIG中一致） - 必须清空或注释掉：
control_files（由启动时指定）、db_create_file_dest、db_recovery_file_dest、standby_file_management -
LOG_ARCHIVE_DEST_2必须指向主库，且带SERVICE=primary_db UNIQUE和SYNC AFFIRM -
LOG_ARCHIVE_DEST_3指向下游备库，必须用ASYNC NOAFFIRM，且设VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
示例最小 pfile 片段：
*.db_name='ORCL' *.db_unique_name='orcl_fs' *.compatible='19.0.0' *.control_files='/u01/oradata/farsync/control01.ctl' *.log_archive_config='DG_CONFIG=(orcl,orcl_fs,orcl_stby)' *.log_archive_dest_2='SERVICE=orcl SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl' *.log_archive_dest_3='SERVICE=orcl_stby ASYNC NOAFFIRM VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=orcl_stby'
密码文件和监听配置最容易被忽略的两个点
Far Sync 实例虽不存数据，但仍需与主库、备库建立双向认证连接。密码文件名必须严格匹配 DB_UNIQUE_NAME，且监听必须启用 DEDICATED 模式——因为 SHARED SERVER 在 Far Sync 场景下不支持 LGWR SYNC AFFIRM 传输。
常见坑：
- 复制主库密码文件后没重命名，例如主库是
orapworcl，Far Sync 必须是orapworcl_fs，否则DGMGRL连接失败 - 监听配置中漏掉
(UR=A)参数，导致主库 LGWR 报ORA-12514: TNS:listener does not currently know of service requested - tnsnames.ora 中 Far Sync 条目未加
(CONNECT_DATA=(SERVICE_NAME=orcl_fs)(UR=A))，主库无法强制连接
验证命令（在主库执行）：
SELECT DEST_ID, STATUS, PROTECTION_MODE, DESTINATION FROM V$ARCHIVE_DEST WHERE DEST_ID IN (2,3);
正常应看到 STATUS = VALID，且 PROTECTION_MODE = MAXIMUM AVAILABILITY 或 MAXIMUM PROTECTION。
Far Sync 启动后必须立刻验证 redo 传输链路
Far Sync 启动成功 ≠ 链路就通。它不写 alert 日志中的 “Media Recovery Started”，也不会生成归档日志，唯一可观测指标是主库 V$ARCHIVE_DEST_STATUS 的 TRANSMIT_MODE 和 DELAY_MINS。
必须检查：
-
SELECT DEST_ID, TRANSMIT_MODE, DELAY_MINS, BINDING FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;——TRANSMIT_MODE应为SYNC，DELAY_MINS为0 - 在 Far Sync 主机执行：
ls -lt $ORACLE_HOME/dbs/arch_*.arc—— 应有不断新增的归档（来自主库），但无应用日志行为 - 下游备库的
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;中，MRP0进程应从 Far Sync 拉取日志（CLIENT_PROCESS = ARCH，CLIENT_PID显示 Far Sync 的 SID）
如果主库 LOG_ARCHIVE_DEST_STATE_2 是 DEFER 或 ALTERNATE，即使配置全对，redo 也不会发往 Far Sync —— 这个状态常被运维脚本静默修改，务必人工确认。
