oracle 19c adg本身不支持异地多活，因其物理备库基于块级重做日志应用，要求主备数据结构、scn及块头校验完全一致；若双节点同时写入，重做流冲突导致mrp0报错中止、apply lag持续飙升无法收敛。
oracle 19c adg 本身不支持“多活”——它只允许一个主库写入，其余备库默认只读；所谓“异地多活”必须拆解为“同城双写+异地只读同步”，否则直接配 adg 多主会触发 ora-16664 / ora-16826 等 broker 不兼容错误。
为什么不能直接用 ADG 做异地多活
ADG 的物理备库（Physical Standby）基于块级重做日志应用，要求主备数据文件结构、SCN、甚至块头校验完全一致。一旦两个节点同时接受 DML，重做流立即冲突，MRP0 进程报错中止，V$DATAGUARD_STATS 中 apply lag 持续飙升且无法收敛。真实案例：某券商曾尝试在两地启用 ACTIVE DATA GUARD 并开放各自只读连接池，但因未禁用 DB_FILE_NAME_CONVERT 导致归档路径错乱，ARCH 进程反复失败，最终手动清空 standby redo log 才恢复同步。
真正可行的“异地多活”分层架构
把“多活”需求按读写能力切开，交给不同组件承担：
- 同城机房（≤100km）：部署 RAC 主库 + RAC 物理备库，启用
MAXIMUM AVAILABILITY模式 +Real-Time Apply，保障 RPO≈0；通过SCAN IP和FAILOVER_TYPE=SESSION实现应用侧无感切换 - 异地机房（如贵阳/内蒙）：仅部署单实例物理备库，配置为
MAXIMUM PERFORMANCE+DELAY=3600，用于防误删和逻辑错误回滚，不参与读流量分流 - 跨地域读写分离：用 Oracle Global Data Services（GDS）或应用层路由（如 ShardingSphere）将写请求固定打向同城主 RAC，读请求按地域标签分发到本地 ADG 只读实例——这才是“活”的来源，不是 ADG 自身多活
关键参数与避坑点
以下配置直接影响异地链路稳定性与切换可靠性：
- 必须关闭
ARCHIVE_LAG_TARGET：该参数会强制归档切换，干扰 Broker 对transport lag的判断；改用 Broker 内置条件：TRANSPORT LAG IS 30 SECONDS+APPLY LAG IS 60 SECONDS -
LOG_ARCHIVE_DEST_2中务必指定SYNC或ASYNC显式模式，避免依赖默认值；异地链路要加NET_TIMEOUT=120防止 WAN 抖动导致 LGWR 挂起 - 所有节点严格运行
ntpd或chronyd，ntpdate -q输出误差需 ≤50ms；时间不同步会导致RFS进程注册失败，V$MANAGED_STANDBY中状态卡在IDLE - 备库
STANDBY_FILE_MANAGEMENT必须设为AUTO，否则主库新增表空间时，备库报ORA-01274无法自动添加数据文件
演练时最容易被忽略的验证项
Switchover 后别只查 OPEN_MODE 是不是 READ WRITE，这些才是真问题：
- 检查
V$DATABASE.SWITCHOVER_STATUS是否为TO PRIMARY（原备库）或SESSIONS ACTIVE（原主库），否则 Broker 认为角色未彻底切换 - 用
tnsping测试新主库的 SCAN VIP 是否响应，很多故障源于 DNS 缓存未刷新或监听未注册新实例 - 执行
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES'，对比主库当前SEQUENCE#，确认归档已完整应用，而非仅传输到位 - 应用连接池是否捕获
ORA-03113或ORA-12545并自动重连——这需要在 JDBC URL 中显式配置oracle.net.CONNECT_TIMEOUT=3000和oracle.net.RECV_TIMEOUT=6000
异地链路永远比想象中脆弱，真正的容灾能力不在配置多华丽，而在每次 FAIL OVER 后能否让应用连上、查出、写入——其他都是锦上添花。
