Oracle 12c RAC + Data Guard 是两个独立RAC集群通过Data Guard互联，而非单集群；主备库DB_NAME必须相同、DB_UNIQUE_NAME必须不同，INSTANCE_NAME可相同但ORACLE_SID需按节点区分，且DG通信须专用静态监听、LGWR ASYNC传输、备库启用MRP并验证日志实时应用。
Oracle 12c RAC + Data Guard 不是“一个集群”，而是两个独立集群
跨机房高可用不能靠把远端节点硬塞进同一个rac集群——cache fusion在rtt >5ms时就会频繁超时，lms进程卡住、实例驱逐、数据库hang死是常态。真实方案是：主站点部署2节点rac（如orcl1/orcl2），备站点也部署2节点rac（如orcl_stby1/orcl_stby2），两者通过data guard连接，各自独立运行，互不共享存储或心跳网络。
常见错误现象：
- 误配
db_unique_name相同，导致DG日志传输失败，ORA-16057: DGID mismatch - 主库用
ARCH归档传输模式，RAC环境下因各节点ARCH进程异步归档，出现日志丢失，failover后数据不一致 - 备库未配置
standby redo log组数与主库redo线程数匹配，导致MRP无法实时应用
主库必须启用LGWR ASYNC传输，且监听需支持DG专用服务名
RAC主库的归档传输必须绕过ARCH进程，直接由LGWR捕获并推送redo——这是唯一能保证所有节点日志不丢的方式。同时，DG通信不能复用SCAN监听器，必须单独配置静态监听服务，否则备库无法注册、tnsping通但connect失败。
实操要点：
- 主库参数设为：
log_archive_dest_2='SERVICE=tns_albindg LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=albindg' -
listener.ora中新增静态服务段，绑定GLOBAL_DBNAME为albindg_DGMGRL，不是albindg - 密码文件必须复制到所有主库节点，且用
orapwd统一生成（RAC下srvctl不自动同步密码文件） - 验证传输状态：
SELECT dest_id, status, error FROM v$archive_dest WHERE dest_id = 2;，非VALID即失败
备库RAC节点的实例名可与主库相同，但db_unique_name必须不同
很多人以为备库实例名要改成orcl_stby1之类，其实不必——只要db_unique_name不同（如主库orcl，备库orcl_dg），实例名仍可用orcl1/orcl2。这样能简化tnsnames和服务名管理，避免应用层改连接串。
关键区别点：
-
DB_NAME主备必须一致（物理DG要求） -
DB_UNIQUE_NAME主备必须不同（DG识别依据） -
INSTANCE_NAME可相同，但每个节点的ORACLE_SID仍需按节点区分（orcl1/orcl2） - 备库启动时必须用
STARTUP MOUNT，不能OPEN；启用MRP前需先ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT
Switchover切换前必须检查所有节点的redo应用状态
RAC环境下的DG切换不是单点操作，DGMGRL执行switchover to albindg后，原主库RAC所有节点会自动shutdown，新主库RAC所有节点需全部open read-write。若任一节点v$managed_standby中PROCESS为ARCH而非MRP0，说明该节点没在实时应用日志，切换后立刻丢失数据。
检查命令（在备库所有节点执行）：
SELECT process, status, sequence#, block#, blocks FROM v$managed_standby;
必须看到：
- 至少一个
MRP0行，status为APPLYING_LOG - 所有
ARCH进程status为CONNECTED（非IDLE） -
sequence#与主库v$archived_log最新归档序号差≤1
真正容易被忽略的是：RAC备库的MRP只在一个节点运行，其他节点只是空闲实例——但切换后它们必须能立即参与读写，所以init.ora里cluster_database=true和remote_listener指向SCAN必须提前验证通。
