rac与data guard是分层协作关系：rac解决机房内实例级故障，data guard解决跨机房数据级灾难；强行将异地节点纳入同一rac集群会因网络延迟（rtt≥20ms）导致grd超时、lms hang及节点驱逐。
RAC 与 Data Guard 不是叠加关系，而是分层协作：RAC 解决单机房内实例级故障，Data Guard 解决跨机房数据级灾难；强行把异地节点塞进同一 RAC 集群，反而会因网络延迟引发 GRD 超时、LMS hang、节点驱逐——这不是高可用，是主动制造故障点。
为什么不能把备库节点加进同一个 RAC 集群
Cache Fusion 要求 RTT ≤ 5ms，而跨机房网络普遍 ≥ 20ms 且抖动剧烈。一旦超时：
-
GRD同步失败，LMD/LMS进程持续等待或崩溃 - 出现大量
gc cr block busy、gc buffer busy acquire等待事件，SQL 响应不可控 - 集群心跳中断，
cssd强制驱逐节点，触发非计划宕机
所谓“RAC 跨机房双活”在 12c 中无官方支持，所有成功案例都是两个独立 RAC 集群 + DG 连接。
主备都必须是完整 RAC 集群（不是 RAC 主库 + 单机备库）
SLA 要求主备对等：主站点 2 节点 RAC（如 rac1、rac2），备站点也必须是 2 节点 RAC（如 stby1、stby2），共享 ASM 存储，物理隔离 ≥ 50km。
- 主库参数中
log_archive_dest_2必须用LGWR ASYNC，禁用ARCH—— RAC 下 ARCH 进程不保证归档实时性，极易丢日志 - 备库监听必须配置静态服务，
GLOBAL_DBNAME设为<db_unique_name>_DGMGRL</db_unique_name>，不能复用 SCAN 监听器 - 密码文件需手动复制到所有主库节点，并用
orapwd重建，srvctl不同步该文件
物理备库 open read only 前必须验证的三项状态
否则即使 SELECT * FROM V$DATABASE 显示 OPEN，也会报 ORA-16000 或查询结果延迟不可控：
- 主库已执行
ALTER DATABASE FORCE LOGGING，且V$DATABASE.FORCE_LOGGING = 'YES' - 备库已添加 standby redo log（SRL），组数 ≥ 主库 online redo log 组数 + 1，大小 ≥ 主库最大日志尺寸
- 已启动实时应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT（注意是USING CURRENT LOGFILE，不是NOREDO）
验证是否生效：查 V$MANAGED_STANDBY.PROCESS 中 RFS 和 MRP0 是否均为 APPLYING_LOG，且 V$DATAGUARD_STATS.DELAY_MINS = 0。
DB_NAME、DB_UNIQUE_NAME、INSTANCE_NAME 的配对规则
这是 DG 通信的基础识别依据，配错直接导致传输失败：
-
DB_NAME主备必须完全一致（物理 DG 强制要求） -
DB_UNIQUE_NAME主备必须不同（如主库设为orcl，备库设为orcl_dg），否则报ORA-16057: DGID mismatch -
INSTANCE_NAME可相同（如都叫orcl1、orcl2），但每个节点的ORACLE_SID仍需按节点区分（orcl1、orcl2），避免混淆
真正容易被忽略的是：备库节点的 ORACLE_HOME 和 GRID_HOME 必须与主库版本严格一致，哪怕小版本号差一个 patch，MRP 进程都可能无法启动或中途 abort。
