RAC到RAC的ADG必须为每个THREAD单独配置Standby Logfile，因各实例独立生成重做日志；备库需在所有节点listener.ora中声明GLOBAL_DBNAME=xxx_DGMGRL并使用SCAN连接串，否则Broker无法正确识别集群；MAXIMUM AVAILABILITY模式下任一节点RFS中断超NET_TIMEOUT即降级异步；Switchover后须确保SERVICE_NAMES含_DGB服务、监听注册该服务且NTP误差<50ms。
oracle 19c rac 到 rac 的 adg 架构，不是简单复制单实例 dg 配置就能跑通的。核心难点在于：rac 主库的多实例日志流、scan vip 的动态注册、standby logfile 的线程绑定、以及 broker 对集群节点的感知逻辑——这些地方配置错一个参数，同步就会卡在 arch 或 rfs 进程，transport lag 持续增长却查不到明显报错。
为什么必须为每个 RAC 实例单独配 Standby Logfile？
RAC 主库中，每个实例（THREAD）独立生成重做日志。如果只给 THREAD 1 加 Standby Logfile，而 THREAD 2 没有，那么当实例 2 提交事务时，RFS 进程会收到日志但无法写入 Standby Redo Log，导致传输挂起，V$DATAGUARD_STATS 中 transport lag 持续上涨，且 SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2 显示 STATUS = VALID，极具迷惑性。
实操要点：
- 先查主库各实例的 THREAD 数：
SELECT THREAD#, INSTANCE FROM GV$INSTANCE - 备库上必须为每个 THREAD 单独执行：
ALTER DATABASE ADD STANDBY LOGFILE THREAD N SIZE 200M（N 替换为实际线程号） - Standby Logfile 组数建议 ≥ 在线日志组数 + 2，避免日志切换竞争
SCAN IP 和 TNS 别名怎么让 Broker 正确识别 RAC 备库？
Broker 默认按单实例逻辑注册监听，若备库是 RAC 但未显式声明 SCAN，它会尝试连接第一个节点的 VIP，一旦该节点宕机或监听未注册，DGMGRL SHOW CONFIGURATION 就显示 WARNING: ORA-12545，自动切换失败。
关键动作：
- 备库 RAC 所有节点的
listener.ora中，必须包含GLOBAL_DBNAME = <code>db_unique_name_DGMGRL（如stddb_DGMGRL），否则 Broker 无法通过 SCAN 发现实例 -
tnsnames.ora中定义备库连接串时，不能只写一个节点地址，必须用 SCAN 格式：(ADDRESS=(PROTOCOL=TCP)(HOST=stddb-scan)(PORT=1521)) - 执行
ADD DATABASE前，先在备库所有节点运行：srvctl add database -d stddb -o $ORACLE_HOME -r PHYSICAL_STANDBY -s MOUNT，确保 Broker 能调用 CRS 接口管理
MAXIMUM AVAILABILITY 模式下，RAC 主库为何仍会降级为异步？
这不是 Bug，而是设计行为。当同城备库 RAC 中任一节点的 RFS 进程因网络抖动、磁盘满或归档路径不可写而中断超过 NET_TIMEOUT（默认 30 秒），主库 LGWR 会主动将该 LOG_ARCHIVE_DEST_n 置为 DEFERRED，整个保护模式降级为异步，V$DATAGUARD_CONFIG 中显示 PROTECTION_MODE = MAXIMUM PERFORMANCE。
排查与加固：
- 检查备库所有节点的归档路径空间：
df -h /u01/arch，并确认LOG_ARCHIVE_DEST_2中的VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE)是否匹配 - 显式设置超时容忍：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stddb SYNC AFFIRM NET_TIMEOUT=120 REOPEN=300' SCOPE=BOTH - 禁用
ARCHIVE_LAG_TARGET—— 它在 RAC+ADG 场景下与 Broker 冲突，会导致日志强制归档但不触发传输
Switchover 后应用连不上新主库？别只查 TNS
RAC 到 RAC 的 Switchover 不是改个连接串就完事。应用侧真正依赖的是 SCAN IP 背后的服务名注册状态。常见现象是：TNSPING 通、SQL*Plus 能连，但 JDBC 应用抛 ORA-12545 或连接池持续 timeout。
根本原因往往藏在这三处：
- 新主库（原备库）的
SERVICE_NAMES参数未包含 Broker 自动创建的服务名（如stddb_DGB），需手动追加：ALTER SYSTEM SET SERVICE_NAMES='stddb,stddb_DGB' SCOPE=BOTH - 新主库的监听未向 SCAN 注册该服务：
lsnrctl status查看输出中是否有Service "stddb_DGB" has 1 instance(s) - GSM（Global Service Manager）未启用或路由策略未更新 —— 若业务走 GSM，必须提前在
gsmadminservices中配置ADD SERVICE并绑定到新主库集群
最易被忽略的是时间同步：RAC 节点间 NTP 误差 > 50ms 时，RFS 进程注册失败，V$MANAGED_STANDBY 中 PROCESS 为 UNKNOWN，但错误日志里只有模糊的 ORA-01034，需要盯住 ALERT.log 里带 timestamp mismatch 的行。
