Oracle RAC本身不支持跨机房Active-Active容灾，因其Cache Fusion依赖低延迟共享存储，仅适用于同城（RTT≤5ms）；真实跨机房容灾必须采用RAC+Data Guard架构，即本地双节点RAC主库与异地双节点RAC备库通过DG同步，RAC保障本地高可用，DG负责异地接管。
跨机房容灾不是靠RAC单集群解决的
rac本身只支持同机房（低延迟、高带宽）内的多节点协同，跨机房网络延迟高、抖动大，cache fusion会频繁超时甚至崩溃，强行拉远距离节点进同一rac集群等于自毁高可用。真实跨机房容灾必须用data guard，rac只负责本地高可用，data guard负责异地接管。
Oracle 12c RAC + Data Guard 的标准拓扑怎么搭
典型部署是“本地RAC主库 + 远程RAC备库”，两边各自是完整RAC集群，通过DG同步；不能是“单节点主库 + 跨机房RAC备库”，因为主库单点会破坏整体SLA。
- 主站点：2节点RAC（如rac1、rac2），共享ASM存储，运行在机房A
- 备站点：2节点RAC（如standby1、standby2），共享ASM存储，运行在机房B（物理隔离，≥50km）
- 网络要求：主备间需专线或MPLS，带宽≥50Mbps，RTT ≤ 80ms（否则LGWR SYNC模式不可靠）
- 归档传输必须用LGWR ASYNC而非ARCH——RAC环境下ARCH进程不保证实时归档，会丢日志
关键配置项和容易踩的坑
配置不是简单跑DGMGRL就完事，RAC+DG有几处必须手工对齐：
-
LOG_ARCHIVE_CONFIG里必须显式列出所有DB_UNIQUE_NAME，包括主备各节点的，漏一个就同步中断 -
LOG_ARCHIVE_DEST_2的SERVICE值必须指向备库SCAN名称（如standby-scan），不能写单节点VIP，否则RAC备库切换后路径失效 - 备库
STANDBY_FILE_MANAGEMENT=AUTO必须开启，否则RAC主库加数据文件，备库不会自动创建，ORA-16401报错 - 主库启动时，确保
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE且密码文件已复制到所有备节点，否则ALTER DATABASE RECOVER MANAGED STANDBY DATABASE会报ORA-16191
Failover后怎么让应用连上新主库
DG failover后，原备库升为主库，但它的RAC服务名、监听配置、TNS别名全变了，应用不会自动感知。
- 必须提前在应用侧配置TNS，使用
FAILOVER_MODE=(TYPE=SESSION)(METHOD=BASIC)(RETRIES=5)(DELAY=10)，否则连接池会卡死 - 不能依赖
tnsnames.ora静态配置——要配合GNS或DNS轮询，把服务名（如orcl_svc）解析指向当前主库SCAN - failover后立刻执行
srvctl modify service -d orcl -s orcl_svc -n standby1,standby2，把服务绑定到新主库节点，否则新主库上的实例不提供服务
跨机房容灾真正难的不是配置命令，而是网络链路质量、密码文件同步节奏、以及应用层是否真能承受秒级中断和连接重试——这些地方一漏，DG切换就变成停机事件。
