Oracle 11g RAC主库不支持单实例物理备库，官方明确禁止该组合；因RAC多节点并发生成重做流，单实例备库缺乏多实例协调能力，无法正确解析和应用日志，必然触发ORA-16789、ORA-16664等错误，MRP进程无法启动。
不能配置 Oracle 11g RAC 主库 + 单实例物理备库 的高可用 Data Guard 架构——这不是配置问题，而是 Oracle 官方明确不支持的组合，强行部署会直接触发 ORA-16789、ORA-16664 等错误，MRP 进程无法启动，日志应用中断。
为什么 RAC 主库必须配 RAC 备库（或至少支持 Real-Time Apply 的物理备库）
RAC 主库的每个节点都独立生成重做流，且归档行为跨实例不一致。单实例备库没有多实例协调能力，无法正确解析和应用来自多个主库节点的并发归档日志流。尤其当主库发生节点切换（如 instance crash），归档路径、日志序列号跳变、SCN 同步点都会错乱，单实例备库的 MRP0 进程会卡在 WAIT_FOR_LOG 或报 ORA-16057: DGID mismatch。
真实场景中常见现象：
- 主库节点 1 切换日志后归档到
+FRA/rac_primary/.../1_100.arc，节点 2 同时归档到+FRA/rac_primary/.../1_100.arc—— 文件名冲突，RFS 进程写失败 - 备库
V$ARCHIVED_LOG中出现重复SEQUENCE#、不同THREAD#但FIRST_TIME相差数秒，APPLIED='NO'持续为真 -
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY显示 MRP0 状态为WAIT_FOR_GAP，但V$ARCHIVE_GAP查不到缺口
LOG_ARCHIVE_DEST_n 必须按 DB_UNIQUE_NAME + VALID_FOR 显式区分角色
RAC 主库不能只用一个 LOG_ARCHIVE_DEST_2 指向单实例备库服务名。必须为每个目标单独配置，且 DB_UNIQUE_NAME 值必须与备库实际设置完全一致（大小写敏感），否则 DG Broker 或手动模式下都会拒绝启用传输。
主库 SPFILE 中必须包含（所有节点共享）：
LOG_ARCHIVE_CONFIG='DG_CONFIG=(rac_primary,single_stby)' LOG_ARCHIVE_DEST_2='SERVICE=single_stby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=single_stby' LOG_ARCHIVE_DEST_3='LOCATION=+FRA VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=rac_primary'
关键点：
-
LGWR ASYNC是必须项：RAC 下ARCH进程不保证归档实时性，极易丢日志；LGWR才能捕获在线日志流 -
VALID_FOR必须写全括号内两项，缺一不可；写成VALID_FOR=ALL_LOGFILES会被忽略 - 备库端也必须配
LOG_ARCHIVE_DEST_2指回主库（用于 Switchover），且DB_UNIQUE_NAME要反过来写成rac_primary
密码文件、FORCE LOGGING 和 Standby Redo Log 缺一不可
单实例备库看似简单，但 RAC 主库对它的要求反而更苛刻：
- 主库所有节点的密码文件必须同步，且含
SYSBACKUP权限：orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=xxx entries=10 force=y format=12，然后手工复制到每个节点相同路径 - 主库必须全局启用
FORCE LOGGING：在任一节点执行ALTER DATABASE FORCE LOGGING后，需确认SELECT FORCE_LOGGING FROM V$DATABASE返回YES（不是YES带空格） - 备库必须创建足够数量的 standby redo log（SRL）：组数 ≥ 主库最大
THREAD#对应的 online redo log 组数 + 1，大小 ≥ 主库最大日志文件尺寸；否则USING CURRENT LOGFILE会报ORA-3172
漏掉任意一项，备库即使 OPEN READ ONLY 成功，查询也会返回过期数据或直接报 ORA-16000（database open for read-only access）。
监听器与服务名配置最容易被忽略的细节
单实例备库的监听器不能复用主库 SCAN 监听器，也不能用动态注册。必须配置静态服务，且 GLOBAL_DBNAME 必须设为 <db_unique_name>_DGMGRL（例如 single_stby_DGMGRL），否则 RFS 进程连接后无法完成角色握手。
TNSNAMES.ORA 中的服务定义必须显式指向备库 IP + 静态端口，不能写 VIP 或 SCAN：
single_stby =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.5.100)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = single_stby_DGMGRL)
)
)验证方式：
- 主库上
TNSPING single_stby必须成功，且返回中包含Service "single_stby_DGMGRL" - 主库上
sqlplus sys@single_stby as sysdba能连上，且SELECT DATABASE_ROLE FROM V$DATABASE返回PHYSICAL STANDBY - 检查备库
lsnrctl status输出中，Service "single_stby_DGMGRL"的状态是READY，不是UNKNOWN
真正决定成败的，从来不是“能不能连上”，而是 RFS 进程是否注册了正确的服务名、MRP0 是否拿到了带完整 thread/scn 上下文的归档流——这些细节在单实例备库上比 RAC 备库更难调试，因为错误日志更分散，等待事件更隐蔽。
