Oracle 19c中读写分离依赖Active Data Guard（ADG）而非基础Data Guard；需启用READ ONLY WITH APPLY模式并设置ADG_REDIRECT_DML=TRUE，DML才透明重定向至主库执行，实现“读多数、写偶尔”的混合负载分发。
Oracle 19c 中 Data Guard 本身不直接提供读写分离能力，真正支撑「读写分离」的是 Active Data Guard（ADG）——它是在物理备库基础上启用的可读功能。单纯配置 Data Guard（如仅搭建物理备库并保持 READ ONLY）无法执行查询，更谈不上读写分离；必须显式开启 ADG，并配合 ADG_REDIRECT_DML 才能实现「多数读、偶尔写」的混合负载分发。
ADG 必须启用 READ ONLY WITH APPLY 模式
物理备库默认是 MOUNTED 状态，无法连接。要让应用连上去查数据，必须启动到 READ ONLY WITH APPLY：
- 执行
ALTER DATABASE OPEN READ ONLY后，MRP 进程会自动启动日志应用（前提是已配置LOG_ARCHIVE_DEST_n和STANDBY_FILE_MANAGEMENT） - 若看到
OPEN_MODE是READ ONLY但没有WITH APPLY，说明 MRP 没跑起来，V$MANAGED_STANDBY中PROCESS = 'MRP0'状态不是APPLYING_LOG，需检查归档传输是否正常、standby redo log 是否存在且大小匹配 - 未启用 ADG 许可证（
SELECT * FROM V$OPTION WHERE PARAMETER = 'Active Data Guard';返回 FALSE）时，强行OPEN READ ONLY会报 ORA-16004 或 ORA-01153
ADG_REDIRECT_DML 是读写分离的关键开关
19c 之前，备库上执行 INSERT/UPDATE 直接报 ORA-16000（只读数据库）。19c 引入 ADG_REDIRECT_DML 后，DML 不再失败，而是被透明重定向到主库执行：
- 参数默认为
FALSE，需显式启用：ALTER SYSTEM SET ADG_REDIRECT_DML = TRUE SCOPE=BOTH;（主库和备库都得设，否则重定向链路不通） - 重定向本质是内部 DB Link 调用，依赖主备间网络连通性及
TNSNAMES.ORA中主库服务名可达；若出现 ORA-02067（事务或保存点回滚失败），大概率是 2PC 协调异常，需检查DBA_2PC_PENDING - 不支持 XA 事务中的 DML，也不支持自治事务（
PRAGMA AUTONOMOUS_TRANSACTION）内的 DML 重定向 - 会话级启用优先级更高：
ALTER SESSION ENABLE ADG_REDIRECT_DML;，适合只对特定应用用户开放写能力
客户端连接必须区分角色，不能靠应用硬编码
读写分离不是数据库自动分流，而是靠客户端连接串指向不同数据库实例：
- 读请求走备库监听地址（如
adg-scan:1521/adg_srv），写请求走主库地址（如primary-scan:1521/prd_srv） - 不能在应用里写死
SELECT ... FROM table@primary做“读主库”，这会绕过 ADG 的一致性保障；所有读应直连备库，由 ADG 保证 SCN 一致性和只读隔离 - 若用 Oracle RAC + ADG，备库也是双节点 RAC，则需配置 SCAN + 负载均衡策略（如
LOAD_BALANCE=on），但注意：ADG 的READ ONLY WITH APPLY不支持跨实例并行查询（PX），所以SERVICE的CLB_GOAL应设为LONG，避免短连接被轮询打散
最易被忽略的一点：ADG_REDIRECT_DML 开启后，备库上的 DML 会带来额外网络往返和主库 CPU/redo 压力，频繁执行等价于把写负载又导回主库。它解决的是「偶发误写」或「轻量交互式更新」场景，不是替代主库的写入口。真正的读写分离架构中，写路径必须收敛到主库，读路径才可弹性伸缩到多个 ADG 实例 —— 这个边界一旦模糊，高可用和性能优势都会坍塌。
