Oracle RAC 无法实现跨中心 Active-Active 容灾，因其 Cache Fusion 依赖低延迟共享存储，仅支持同城 stretch cluster（RTT≤5ms）；异地双活需存储复制+应用路由+冲突规避，RAC 仅作本地高可用组件。
oracle rac 本身不提供跨站点的 active-active 存储容灾能力；所谓“双活存储容灾”必须依赖底层存储或第三方复制技术，rac 只能保障单站点内多实例并发访问同一份数据。
为什么 RAC 不能直接实现跨中心 Active-Active 同步
RAC 的 Cache Fusion 机制只在共享存储（如 ASM diskgroup）上运行，所有节点必须低延迟、高带宽访问同一组磁盘。跨数据中心部署 RAC（即 stretch cluster）虽有支持，但要求 RTT ≤ 5ms、带宽 ≥ 10Gbps，且仅限同城双中心——这本质仍是单存储域下的高可用，不是异地双活。
-
ORA-00600或节点驱逐（eviction）在跨中心网络抖动时高频出现 - Oracle 官方明确不支持将两个独立 RAC 集群（不同存储）通过应用层切换伪装成“双活”
-
ASM不支持跨站点镜像；DATAFILE无法同时被两个物理隔离的存储系统实时写入
真正可行的 Active-Active 容灾组合方案
要达成业务侧感知的“双中心同时读写”，必须拆解为：存储层异步/同步复制 + 应用层路由 + 数据库层冲突规避。RAC 在其中仅作为本地高可用组件存在。
- 主中心部署一套 RAC（如 rac-prod1），使用本地
ASM；灾备中心部署另一套 RAC（rac-prod2），也用本地ASM - 底层存储用支持
TrueCopy（Hitachi）、Synchronous Replication（Dell PowerStore）、或Oracle Data Guard SYNC（需配置LOG_ARCHIVE_DEST_2+SYNC AFFIRM）实现块级或日志级强一致复制 - 禁用灾备中心 RAC 的自动启动：确保
CRS不拉起实例，避免脑裂；只在故障切换后手动srvctl start database - 应用连接串必须区分
service_name，并通过 DNS/GSLB 实现读写分离或故障重定向，不能靠 RAC 的TAF自动跨中心跳转
常见误配导致的“伪双活”问题
很多团队把 DG Physical Standby 搭配 RAC 主库，再开启 READ ONLY WITH APPLY，就认为是双活——但这只是单写双读，不满足“Active-Active”的核心定义（双向可写）。
- 误启灾备端 RAC 实例并开放写权限 → 触发
ORA-16136（standby database is not open for writing）或更严重的逻辑损坏 - 用
GoldenGate做双向复制却未配置冲突检测（如MAP ... COLMAP (USEDEFAULTS, on update conflict ...)）→ 主键冲突、序列错乱、丢失更新 - 将
DB_UNIQUE_NAME配置相同 →ARCH日志归档路径混乱，DG broker 判断失准 - 未关闭灾备端
cluster_database = TRUE下的INSTANCE_TYPE = RAC自动注册 → 导致 OCR 中残留无效实例信息
真正的跨中心 Active-Active 是个系统工程，RAC 只管好自己那一亩三分地；存储复制的 RPO/RTO、应用事务边界划分、全局序列生成策略（比如用 DBMS_SCHEDULER 分段分配或外部号段服务），这些比 RAC 配置本身更关键。别让 srvctl status database 显示“ONLINE”就误以为容灾已就绪。
