oracle rac 本身不支持跨数据中心 active-active 架构；其 cache fusion 依赖低延迟共享存储（rtt≤5ms），仅适用于同城 stretch cluster，异地部署会因网络延迟引发 ora-00600 或节点驱逐，官方明确不支持；所谓“rac 双活”实为误解，真正跨中心双向可写需依赖存储复制+应用路由+冲突规避，rac 仅作单中心高可用组件。
oracle rac 本身不支持跨数据中心的 active-active 架构，所谓“rac 双活”是常见误解。真正的跨中心双向可写（active-active）必须绕开 rac 的 cache fusion 机制，用存储复制 + 应用路由 + 冲突规避组合实现，rac 在其中只承担单中心内高可用角色。
为什么 cluster_database=TRUE 不能跨中心启用 Active-Active
RAC 节点依赖低延迟共享存储（如 ASM diskgroup）同步内存块，所有节点必须实时访问同一份数据文件。跨中心部署时，网络 RTT 超过 5ms 就会触发 ORA-00600 或节点驱逐（eviction），官方明确不支持异地双活。即使强行配置 stretch cluster，也只是同城双中心下的单存储域高可用，不是业务侧定义的 Active-Active。
- Cache Fusion 要求私有网络延迟
-
ASM不支持跨站点镜像，DATAFILE无法被两个物理隔离的存储系统同时写入 - 若在灾备中心误启
srvctl start database，且未禁用 CRS 自动拉起，极易引发脑裂与数据损坏
真正可行的 Active-Active 容灾组合方案
要让两个中心都可读可写，必须拆解为三层协同：存储层复制、应用层路由、数据库层冲突控制。RAC 只部署在每个中心内部，作为本地多实例并发访问的载体。
- 主中心部署一套 RAC（如
rac-prod1），使用本地ASM；灾备中心部署另一套独立 RAC（rac-prod2），也用本地ASM - 底层存储用支持强一致复制的技术：
TrueCopy（Hitachi）、Synchronous Replication（Dell PowerStore）或Oracle Data Guard SYNC AFFIRM（需配LOG_ARCHIVE_DEST_2） - 灾备中心 RAC 必须保持
cluster_database=FALSE（截至 2026 年 4 月仍适用），CRS 不启动实例；仅在故障切换后手动srvctl start database - 应用连接串必须区分
service_name，通过 DNS/GSLB 实现读写分离或故障重定向；绝不能依赖 RAC 的TAF自动跨中心跳转
常见伪双活配置及致命后果
很多团队把 DG Physical Standby 搭配 RAC 主库 + READ ONLY WITH APPLY 当成双活，这本质是单写双读，不满足 Active-Active 的双向可写前提。
- 开启只读备库后执行 DML → 报
ORA-16136（standby database is not open for writing） - 用
GoldenGate做双向复制但未配冲突检测（如MAP ... on update conflict）→ 主键冲突、序列错乱、丢失更新 -
DB_UNIQUE_NAME配置相同 → 归档路径混乱，DG broker判断失准，日志传输中断 - 灾备端遗漏关闭
cluster_database = TRUE→ CRS 启动实例后与主中心争抢资源，触发 OCR 锁争用或静默数据覆盖
最易被忽略的是：RAC 的“高可用”和“双活容灾”是正交能力——前者解决单中心节点故障，后者解决数据中心级故障。混用两者而不分层隔离，大概率在第一次网络抖动时就丢数据。
