不会。data guard不感知rac节点故障，仅面向整个数据库进行同步；主库节点宕机由crs自动处理，dg不受影响；备库无需强制rac，但rac备库可实现双中心双活并缩短rto。
主库RAC节点故障时，DG备库是否自动接管？
不会。Data Guard本身不感知RAC内部节点状态，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 或 Broker 的 switchover 操作都面向整个数据库（即整个RAC集群），不是单个实例。节点宕机由CRS自动重启或failover到其他节点，但主库身份不变，DG同步不受影响。
备库也必须是RAC才能实现“双中心双活”？
不是必须，但强烈建议。单实例备库在主RAC故障后只能提供只读服务（ADG模式下），无法承担写负载；而双节点RAC备库可在switchover后立即承接全部读写流量，且自身具备节点级高可用能力。若灾备中心只有单实例，DB_UNIQUE_NAME 和 LOG_ARCHIVE_DEST_2 配置仍有效，但容灾RTO会显著拉长——需人工干预启动、验证、切应用DNS/VIP等。
配置DG时，RAC主库的tnsnames.ora要怎么写？
关键点在于：主库和备库各自的连接描述符必须明确区分角色，且不能依赖SCAN IP做跨中心解析。
- 主库侧
tnsnames.ora中定义备库服务名时，用备库两个节点的VIP或公网IP（非SCAN），例如：ipccs = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.2.10)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ipccs))) - 备库侧同理，指向主库VIP（如
192.168.1.10和192.168.1.11），禁用SCAN别名，避免DNS解析失败导致归档传输中断 - 所有节点的
listener.ora必须监听对应物理IP+端口，不能只监听*，否则DG日志传输可能因绑定地址不匹配失败
FSFO（Fast-Start Failover）在RAC+DG中能真正“无人值守”吗？
能，但条件苛刻。启用FSFO前必须确认：
- Observer进程必须部署在第三方主机（不能在主/备RAC任一节点上），且网络连通性稳定
- 主库和备库都必须开启
FLASHBACK DATABASE，否则failover后无法回退 - RAC备库所有节点的
LOG_ARCHIVE_DEST_n参数中VALID_FOR必须设为(ALL_LOGFILES,STANDBY_ROLE)，否则Observer可能误判备库不可用 - FSFO切换后，原主库RAC集群不会自动shutdown，需手动清理或等待observer重置状态，否则下次failover可能冲突
实际生产中，多数团队仍倾向用Broker手动switchover——可控性强，且RAC多实例在切换过程中由Broker自动协调实例启停，比FSFO更易排查问题。
