通常不会。Data Guard 并不感知 RAC 单个节点的故障状态，它面向的是整个数据库级别的日志同步与角色切换；当主库某个 RAC 节点宕机时，一般由 CRS 自动接管和恢复，DG 同步关系不会因此中断；备库也不要求必须部署为 RAC，但如果采用 RAC 备库，更有利于构建双中心高可用架构，并有效缩短 RTO。
主库RAC节点故障时，DG备库是否自动接管？
一般不会。Data Guard 本身不会感知 RAC 集群内部某一个节点的运行状态变化，无论是 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE，还是 Broker 的 switchover，操作对象始终都是整个数据库，也就是完整的 RAC 集群，而不是某个单独实例。某个节点发生宕机后，通常由 CRS 自动重启实例，或由其他节点继续承载业务；但主库角色不会因此发生变化，Data Guard 的主备同步机制通常也不会受到影响。
备库也必须是RAC才能实现“双中心双活”？
这不是强制条件，但从生产环境的高可用与容灾实践来看，通常都建议备库同样采用 RAC。原因也很明确：单实例备库即使在主 RAC 出现故障后，通常也只能在 ADG 模式下提供只读服务，无法真正承接主库写入压力；而双节点 RAC 备库在完成 switchover 后，可以快速接管全部读写流量，同时自身也具备节点级别的高可用能力。反过来说，如果灾备中心仅部署单实例数据库，那么 DB_UNIQUE_NAME 和 LOG_ARCHIVE_DEST_2 等 Data Guard 配置依然可以正常生效，只是整体容灾恢复时间 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 和端口，不能仅监听*，否则 Data Guard 日志传输可能因为地址绑定不一致而失败
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 更便于问题定位和故障排查。
