Extended Distance RAC（EDRAC）在Oracle 19c中不可行，因其违反官方“同城双中心”定义（RTT≤5ms），跨机房部署将导致ORA-29702启动失败、ASM磁盘组频繁offline、Cache Fusion退化、DLM锁等待飙升等不可规避问题。
extended distance rac（edrac）不是oracle官方支持的跨机房高可用方案。它在技术上存在严重缺陷，无法满足生产级容灾要求，不建议在任何关键系统中启用或尝试部署。
为什么 Extended Distance RAC 在 Oracle 19c 中不可行
Oracle 官方明确将 RAC 定义为「同城双中心」架构：所有节点必须位于同一地理区域（通常要求 RTT ≤ 5ms），依赖低延迟私网完成 Cache Fusion 和全局资源协调。EDRAC 尝试拉长私网距离（如跨城、跨省），直接触发以下不可规避问题：
-
ORA-29702：集群服务启动失败，因cssd无法在超时窗口内完成节点心跳确认 - ASM 磁盘组频繁 offline：网络抖动导致 voting disk 读写超时，引发强制驱逐（eviction）
- 数据块争用加剧：Cache Fusion 协议在 >10ms 延迟下退化为“伪同步”，大量 block transfer 转为 disk I/O，TPS 断崖式下跌
- DLM（Distributed Lock Manager）锁等待飙升：全局队列（GCS/GES）消息往返时间突破内部阈值，
gc cr/cu busy等待事件占比超 40%
真实案例：某银行曾将 rac1（上海）、rac2（杭州）通过 20ms 光纤互联测试 EDRAC，DBCA 建库后 3 分钟内即发生节点 1 自动重启，ASM 日志持续刷出 WARNING: Lost 3 heartbeats from node 2。
Oracle 19c RAC 实际可落地的跨机房容灾路径
真正可行的方案必须绕开 RAC 的跨节点实时协同机制，改用「主备分离 + 异步复制」模型：
-
Data Guard + Far Sync（推荐）
- 主库（同城 RAC）→ Far Sync 实例（异地机房，单节点，仅转发 redo）→ 备库（异地机房，单实例或 RAC）
- Far Sync 不承载业务，无数据文件，仅需极小资源；redo 传输由 LGWR SYNC AFFIRM 保障零丢失
- 切换时使用
switchover或failover，RTO < 2 分钟，RPO = 0
-
Active Data Guard + Broker 自动故障转移
- 备库开启只读+ADG，通过
DGMGRL配置 Fast-Start Failover（FSFO） - 监控主库心跳与 redo 应用延迟，延迟超阈值（如 30 秒）自动触发 failover
- 注意：FSFO 要求备库为单实例或同构 RAC，且必须关闭备库上的
cluster_database参数
- 备库开启只读+ADG，通过
-
GoldenGate 双向复制（非 Oracle 原生，但灵活）
- 适用于异构数据库或需双向写入场景
- 通过抽取 trail 文件 + 过滤逻辑实现跨机房事务同步
- 缺点：无法保证严格一致性（存在微秒级窗口），需应用层配合解决冲突
配置 Far Sync 时最容易被忽略的三个细节
- Far Sync 实例的
db_unique_name必须与主库、备库全局唯一，且不能和任意节点的ORACLE_SID重名，否则 DG Broker 识别失败 - 主库的
LOG_ARCHIVE_DEST_2必须显式指定SYNC AFFIRM和NET_TIMEOUT=30，默认 30 秒超时在高延迟链路下极易误判 - Far Sync 的
standby_file_management必须设为AUTO，否则添加新表空间时备库无法自动创建数据文件，导致归档中断
Far Sync 本身不存数据，但它是一道脆弱的“信任闸门”——配置错一个参数，整个跨机房链路就失去零丢失能力。不要跳过 DGMGRL SHOW CONFIGURATION VERBOSE 的逐项核对。
