oracle 12c rac本身不支持跨机房active-active容灾，因其cache fusion依赖rtt≤5ms低延迟网络，跨机房延迟高、抖动大会导致grd超时、进程崩溃和节点驱逐；真实跨机房容灾必须采用rac+data guard架构，即本地双节点rac主库与异地双节点rac备库通过dg同步，rac保障本地高可用，dg负责异地接管。
oracle 12c rac 本身不能跨机房做 active-active 容灾，所谓“最高可用架构”不是靠拉远节点进同一个 rac 集群实现的，而是 rac + data guard 的组合：rac 解决本地实例级故障，data guard 解决异地数据级灾难。
为什么不能把异地节点加进同一个 RAC 集群
RAC 的 Cache Fusion 依赖亚毫秒级网络延迟（RTT ≤ 5ms），跨机房网络抖动大、延迟高（通常 ≥ 20ms），会导致：
-
GRD（Global Resource Directory）同步超时，LMD/LMS 进程频繁 hang 或崩溃 -
gc cr block busy、gc buffer busy acquire等等待激增，SQL 响应不可控 - 集群心跳失败，
cssd强制驱逐节点，反而引发计划外宕机
强行部署等于用高可用机制制造单点故障——这不是容灾，是自毁。
RAC + Data Guard 标准拓扑必须满足的硬性前提
主备两边都必须是完整 RAC 集群（非“RAC 主库 + 单机备库”），否则 SLA 不成立。关键配置项如下：
- 主站点：2 节点 RAC（如
rac1、rac2），共享 ASM 存储，运行在机房 A - 备站点：2 节点 RAC（如
standby1、standby2），共享 ASM 存储，运行在机房 B（物理隔离，≥50km） - 网络：主备间需专线或 MPLS，带宽 ≥50Mbps，RTT ≤80ms（否则
LGWR SYNC模式会持续 timeout） - 归档传输必须用
LGWR ASYNC，禁用ARCH—— RAC 下ARCH进程不保证实时归档，极易丢日志
物理备库启用只读前必须验证的三项状态
即使备库已 open read only，若以下任一条件未满足，就会报 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。
TNS 和服务名注册最容易被忽略的坑
tnsping 备库服务名通、sqlplus /@standby 能连，不代表应用能连 standby_ro：
- RAC 备库必须注册只读服务名（如
his_ro）到 SCAN 监听器，且该服务需显式绑定到所有节点的LOCAL_LISTENER - 不能只配静态监听；必须用
srvctl add service创建服务，并srvctl start service启动 - 检查
V$ACTIVE_SERVICES中该服务的CON_ID和STATE，确保为OPEN且非RESTRICTED
最常漏掉的是：没在备库所有节点的 listener.ora 里加 GLOBAL_DBNAME 映射，导致 SCAN 只转发到部分节点，连接随机失败。
