Extended RAC 不支持真正意义上的“异地双活”，仅限≤100 km同城双中心，须同时满足裸光纤+DWDM+大二层网络；超远距离（如北京—广州）必须采用ADG、GoldenGate等逻辑复制方案。
Extended RAC 本质不是“异地双活”，而是超低延迟跨机房RAC
直接说结论：Extended RAC 不支持真正意义上的“异地双活”（比如北京—广州、上海—贵阳这种超远距离）。它只接受 ≤100 km 的物理距离，且必须满足裸光纤+DWDM+大二层网络三者同时成立。所谓“异地双活”在 Oracle 官方语境里，是 Oracle Data Guard（ADG）或异构同步方案的事，不是 Extended RAC 的职责范围。
混淆这点会导致严重后果：你按“双活”目标去规划 Extended RAC，结果集群起不来、节点反复驱逐、ORA-29702 频发——这不是配置错了，是物理前提不满足。
常见错误现象包括：
-
cluvfy comp peer验证失败，提示私网延迟超标或 ARP 不可达 - 启动
crsctl start crs后，cssd进程卡住或报misscount超时 - 节点上线后频繁出现
gc cr block busy、gc buffer busy acquire等等待事件
必须由基础设施团队先完成的三类硬性验证
Oracle 层配置前，网络与存储团队必须出具书面报告，确认以下全部达标：
- 用
ping -s 8192持续压测 1 小时，最大 RTT ≤ 2.5 ms，丢包率 = 0%（注意：不是ping -c 10测 10 次） - 所有 RAC 节点私网 MAC 地址可互相
arp -a解析（要求 L2 可达，禁止走三层路由） - 共享存储支持跨站点同步写入：要么是 IBM DS8000 / Dell EMC PowerMax 等带 metro mirror 功能的 SAN，要么是 ASM 使用
EXTERNAL REDUNDANCY+ 存储层双活复制；绝不能依赖 ASM 自身的NORMAL或HIGH冗余
OCR/voting disk 必须放在跨机房容灾 LUN 上，并挂载为 ASM diskgroup；本地备份路径（如 ocrconfig -backuploc）也必须指向该共享存储，否则节点重启后可能因 OCR 备份缺失而无法恢复仲裁。
Oracle 层关键参数不可绕过的设置项
即使底层达标，Oracle 层几个参数若未显式调整，集群仍会在高并发下随机 hang：
-
css misscount必须设 ≥ 60（默认 30），否则网络抖动易触发节点驱逐 -
disk_repair_time设为 12960 秒（即 3.6 小时），避免 ASM disk 因短暂网络中断进入DISMOUNTED状态 - SCAN IP 和各节点 VIP 必须在 DNS 中实现跨机房双生效（不能只配一个机房的 A 记录）
- 12cR2+ 必须启用
ora.cluster_interconnect.haip，且 HAIP 地址段不能与业务网/私网重叠 -
LOCAL_LISTENER和REMOTE_LISTENER必须按机房精准配置，例如机房A节点只注册机房A的 SCAN，不能混写
这些不是“建议值”，而是 Extended RAC 在跨机房场景下的生存底线。漏掉任意一项，上线后都可能表现为间歇性连接超时或事务 hang 住不提交。
为什么不要把 Extended RAC 当作“双活”来用
Extended RAC 的设计目标从来就不是负载分担或故障自动接管，而是：在单点物理故障（如某机房断电）时，剩余节点能继续提供服务——但它仍是一个单一数据库实例，所有 SQL 执行计划、锁管理、全局队列（GES/GCS）都是强耦合的。一旦跨机房链路波动，性能下降不是线性的，而是阶跃式的（RTT 从 2ms → 4ms，gc 等待可能翻 5 倍）。
真正需要“双活读写”的场景，应选：
- 同城双活：用
Oracle ADG+ 应用路由（如 F5 GSLB + 读写分离中间件） - 超远距离双活：用
Oracle GoldenGate或金仓异构同步工具，走逻辑日志解析，容忍秒级延迟 - 完全解耦架构：应用无状态化 + Redis 多中心部署 + 最终一致性补偿
Extended RAC 是一把高精度手术刀，不是万能扳手。把它插进不符合物理定律的环境里，最可能的结果是刀断，而不是病除。
