extended rac 是需严格满足≤100 km距离、专用裸光纤+dwdm、低延迟大二层网络三者缺一不可的物理架构约束型部署；其敏感性源于cache fusion对毫秒级私网响应的硬性要求，rtt超5ms即引发显著等待事件，超10ms易触发ora-29702；光速限制使100km单程延迟达0.5ms，叠加设备开销后rtt难压至3ms内；必须由网络与存储团队出具书面验证报告，确认ping -s 8192持续1小时最大rtt≤2.5ms且零丢包、跨机房大二层arp可达、共享存储支持同步写入（高端san或asm external+存储双活）、ocr/voting disk位于异地容灾lun并挂载为asm；oracle层须设css misscount≥60、disk_repair_time=12960秒、scan/节点vip跨机房dns双生效、12cr2+启用ora.cluster_interconnect.haip且地址段不重叠；致命检查项包括cluvfy全节点验证、私网mtu一致、ocr备份路径统一指向共享存储、local/remote_listener按机房精准配置——任一缺失都将导致上线后高并发随机hang。
远距离 rac（extended rac）不是简单改几个参数就能启用的模式，它本质是物理架构强约束下的特殊部署形态——必须满足 ≤100 km、专用裸光纤 + dwdm、低延迟大二层网络打通 三者同时成立，否则集群无法稳定运行，甚至在启动阶段就失败。
为什么 Extended RAC 对距离和网络如此敏感
Oracle RAC 的缓存融合（Cache Fusion）依赖节点间毫秒级响应的私网通信。Extended RAC 将节点跨机房部署后，网络延迟直接叠加进全局队列（GES/GCS）等待路径中：
- RTT > 5 ms 时，
gc cr block busy和gc buffer busy acquire等等待事件显著上升 - RTT > 10 ms 时，
lmd进程可能频繁超时，触发ORA-29702（cluster database error） - 若使用 ASM Mirror 而非存储复制，跨站点镜像同步会因网络抖动导致 ASM disk group 处于
DISMOUNTED状态
这不是配置问题，而是物理定律限制：光在光纤中传播速度约 200,000 km/s，单程 100 km 就有 0.5 ms 基础延迟，再加设备转发、队列排队，实际 RTT 很难压到 3 ms 以内。
必须提前确认的底层基础设施条件
在执行任何 Oracle 层操作前，先由网络与存储团队出具书面验证报告，重点包括：
-
ping -s 8192持续 1 小时，最大 RTT ≤ 2.5 ms，丢包率 = 0% - FC 或 InfiniBand 网络已打通跨机房大二层，且所有 RAC 节点能互相
arp到对方私网 MAC 地址（不能仅靠三层路由） - 共享存储必须支持跨站点同步写入：要么是带
metro mirror功能的高端 SAN（如 IBM DS8000、Dell EMC PowerMax），要么是 ASM 使用EXTERNAL REDUNDANCY+ 存储层双活复制，绝不能只靠 ASM NORMAL/ HIGH REDUNDANCY - OCR 和 voting disk 所在磁盘组必须位于具备异地容灾能力的存储 LUN 上，且挂载方式为
ASM（不支持 NFS/OCFS2 用于 OCR/Voting）
Oracle 层关键配置差异点
与本地 RAC 相比，Extended RAC 的 crsctl 和 srvctl 命令无新增选项，但以下参数必须显式校验和调整：
-
css misscount必须设为 ≥ 60（默认 60），避免心跳误判：crsctl set css misscount 60
，且所有节点需一致 -
disk_repair_time在 voting disk 所在 ASM disk group 中建议设为3.6h（12960 秒），防止短暂网络闪断触发磁盘驱逐：ALTER DISKGROUP dg_voting SET ATTRIBUTE 'disk_repair_time'='12960';
- SCAN VIP 和节点 VIP 的 DNS 解析必须返回跨机房可达的 IP，不能绑定到单侧子网；
srvctl config scan输出的 SCAN 名称需在两侧 DNS 同时生效 - 如果使用 Oracle Grid Infrastructure 12cR2 及以后版本，
ora.cluster_interconnect.haip资源必须启用，且 HAIP 地址段不能与任一机房的生产网段重叠
最容易被跳过的致命检查项
多数 Extended RAC 部署失败，卡在最后一步启动数据库实例，原因几乎全是以下三项之一未闭环：
- 未在所有节点上运行
cluvfy comp nodecon -n all -verbose，漏掉某台机器私网 MTU 不一致（例如一侧是 9000，另一侧是 1500） - OCR 备份位置（
ocrconfig -showbackup）指向本地文件系统，而非共享存储上的统一路径，导致跨机房恢复时找不到最新备份 - 监听器配置中
LOCAL_LISTENER和REMOTE_LISTENER的地址未区分机房归属，造成连接请求被错误路由到远端节点再打回，形成环路
这些不是“可选优化”，而是 Extended RAC 正常运行的刚性前提。少验证一项，上线后就可能在高并发下随机 hang 住。
