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