能配，但RAC备库必须设cluster_database=FALSE以启用MRP进程，否则因多实例争抢日志导致ORA-16789等错误；需为每个THREAD显式添加SRL、TNS指向单节点VIP并加UR=A、同步含SYSBACKUP的密码文件、确保节点时间同步。
能配，但单实例主库连 RAC 备库不是“主备关系”而是“主-集群备”，RAC 备库必须以 cluster_database=FALSE 启动（即伪装成单实例物理备库），否则 MRP 进程无法启动，报 ORA-16789 或卡在 STANDBY REDO LOG NOT ALLOCATED。
为什么 RAC 备库要关 cluster_database？
RAC 备库节点默认以集群模式运行，会尝试跨实例协调日志应用，但物理备库的 MRP（Managed Recovery Process）只允许单实例独占应用重做流。若 cluster_database=TRUE，Oracle 会拒绝启动 MRP，因为多个实例可能同时争抢同一份归档日志，破坏一致性。
实操要点：
- 备库所有节点的 SPFILE 中必须设置：
cluster_database=FALSE（不能只改一个节点） - 修改后需重启所有节点：
srvctl stop database -d→ 手动用sqlplus / as sysdba启动到MOUNT状态 → 再用srvctl start database拉起 - 验证：查
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'cluster_database'，返回必须是FALSE - 注意：此时 RAC 的 CRS 仍管理该数据库，只是 Oracle 实例层不启用集群逻辑——这是 Data Guard 官方支持的“RAC-as-Physical-Standby”模式
Standby Logfile 必须按 THREAD 显式添加，哪怕只用一个实例
即使你只打算让 RAC 备库的一个节点跑 MRP（实际也必须如此），仍要为每个 THREAD 预留 Standby Redo Log。因为主库是单实例，只有一个 THREAD，但 RAC 备库的 ASM 磁盘组、OCR 配置和初始化参数都隐含多线程能力，Oracle 在校验时会检查所有已知 THREAD 是否有对应 SRL。
常见错误现象：
-
V$ARCHIVE_DEST_STATUS.DEST_ID = 2显示STATUS = VALID，但V$DATAGUARD_STATS.TRANSPORT_LAG持续增长 -
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE报ORA-01274：无法添加 SRL，因未指定 THREAD
正确做法：
- 先确认主库 THREAD 数：
SELECT THREAD#, MAX(SEQUENCE#) FROM V$LOG_HISTORY GROUP BY THREAD#（单实例必为 1） - 在备库任一节点执行（注意 THREAD 1 是必须的，THREAD 2+ 可选但建议补全）：
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 200M;<br>ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 200M;<br>ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 200M;
- SRL 组数 ≥ 主库 Online Redo Log 组数 + 2，避免日志切换竞争
TNS 连接串和服务名必须指向单节点 VIP，且带 UR=A
RAC 备库虽为集群，但 Data Guard 只通过一个节点接收和应用日志。Broker 或 SQL*Plus 连接时若使用 SCAN 地址或负载均衡服务名，可能路由到非 MRP 节点，导致认证失败或连接超时。
关键配置项：
- 主库
tnsnames.ora中定义备库服务名时，HOST 必须写备库某节点的 VIP（如stb1-vip），不能写 SCAN；且必须加(UR=A)（即 “Unrestricted” 模式），否则 Oracle 默认尝试连接所有实例，而其他节点处于NOMOUNT状态会直接拒绝 - 示例（主库端）：
STB1 =<br> (DESCRIPTION =<br> (ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.10.13)(PORT = 1521))<br> (CONNECT_DATA =<br> (SERVER = DEDICATED)<br> (SERVICE_NAME = stbdb)<br> (UR = A)<br> )<br> )
- 主库
LOG_ARCHIVE_DEST_2中的SERVICE=STB1必须与该 TNS 名一致 - 备库监听器无需特殊配置，但确保该 VIP 对应节点的
listener.ora已注册SERVICE_NAME=stbdb
密码文件同步与 SYSBACKUP 权限不可省略
主库用 SYS 或 SYSBACKUP 身份连接备库发起日志传输，RAC 备库各节点的密码文件若不一致，或缺少 SYSBACKUP 权限，就会在 RFS 进程建立连接时失败，报 ORA-01017（用户名/密码错误）或 ORA-16664（无法联系主库）。
操作步骤：
- 主库生成含
SYSBACKUP的密码文件：orapwd file=$ORACLE_HOME/dbs/orapwpassword= entries=10 force=y ignorecase=y - 将该文件 scp 到 RAC 备库所有节点的
$ORACLE_HOME/dbs/下，文件名必须严格匹配实例名（如orapwstbdb1,orapwstbdb2） - 在备库任一节点验证：
SELECT USERNAME, SYSBACKUP FROM V$PWFILE_USERS，确认SYS和SYSBACKUP均为TRUE - 注意：不要用
srvctl modify database修改密码文件路径，Data Guard 不读取 CRS 元数据里的密码文件位置
最易被忽略的是：RAC 备库节点间时间不同步（NTP 未开启或误差 > 50ms）会导致 Broker 角色切换失败，报 ORA-16666；而这个错误日志分散在 ALERT.log 和 drc*.log 中，不专门搜 time drift 很难定位。
