物理备库不支持dml重定向，仅逻辑备库在dg broker启用、apply-on、主库force logging、表有主键等条件下才可启用adg_redirect_dml，且dml实际由主库执行。
不能直接在物理备库上“开启DML重定向”来执行写操作——这是最常见的误解。ADG_REDIRECT_DML 参数只对逻辑备库生效，而标准 Active Data Guard（即物理备库）默认只读，执行 DML 会立即报 ORA-16000。
确认你的备库类型是物理还是逻辑
这是所有配置的前提。物理备库（PHYSICAL STANDBY）和逻辑备库（LOGICAL STANDBY）底层机制完全不同：
- 查当前角色：
SELECT database_role, open_mode FROM v$database; - 若返回
PHYSICAL STANDBY且READ ONLY WITH APPLY，那就是标准 ADG —— 此时ADG_REDIRECT_DML参数根本不可见（SHOW PARAMETER adg_redirect_dml查不到），设了也无效 - 若返回
LOGICAL STANDBY，才可能启用 DML 重定向，但必须满足后续条件 - 物理备库上强行
ALTER SESSION ENABLE ADG_REDIRECT_DML会报错ORA-00922: missing or invalid option，因为该语法不被识别
逻辑备库启用 DML 重定向的硬性条件
即使你是逻辑备库，ADG_REDIRECT_DML=TRUE 也只是开关，不是自动生效的魔法。以下四点缺一不可：
- 逻辑备库必须处于
APPLY-ON状态：ALTER DATABASE START LOGICAL STANDBY APPLY; - 主库已启用
FORCE LOGGING：ALTER DATABASE FORCE LOGGING; - 被操作的表必须有主键，或启用了
ENABLE ROW MOVEMENT；含LONG、未启用SECUREFILE的 LOB 列会失败 - 该表不能被
DBMS_LOGSTDBY.SKIP显式跳过，例如：EXEC DBMS_LOGSTDBY.SKIP('DML','SCOTT','EMP');会阻断重定向
ADG_REDIRECT_DML 的实际生效方式
它不是让备库“自己写”，而是把 DML 请求通过内部 DB Link 转发到主库执行，再等 redo 回传应用。这意味着：
- 事务延迟明显高于本地执行：主库执行 + redo 传输 + 备库应用 + 客户端返回，整个链路都参与
- 不支持 XA 分布式事务，也不支持
SYS用户会话（文档明确排除） - 会话级设置优先于系统级：
ALTER SESSION ENABLE ADG_REDIRECT_DML比ALTER SYSTEM SET ADG_REDIRECT_DML=TRUE更快生效 - 启用后，
INSERT/UPDATE/DELETE和 PL/SQL 块内 DML 都会被重定向，但TRUNCATE不支持
DG Broker 是前提，不是可选项
官方文档强制要求 DG Broker 启用，否则 DML 重定向无法建立主备间可信代理通道：
- 主库和备库都需设置：
ALTER SYSTEM SET dg_broker_start = TRUE SCOPE=BOTH; - 必须用
DGMGRL创建并验证配置，例如：CREATE CONFIGURATION 'myconf' AS PRIMARY DATABASE IS 'orcl' CONNECT IDENTIFIER IS orcl; - 若未配置 DG Broker，即使其他条件全满足，DML 仍会报
ORA-16664: unable to receive the result from a database
真正容易被忽略的是：这个功能本质是“伪装成备库写，实则全是主库扛”。高频率或大批量 DML 会迅速拖垮主库 Redo 生成和网络带宽，监控必须覆盖主库的 log file sync 等待事件和 2PC 事务状态（v$transaction 中 pending 数量）。别只盯着备库的 open_mode 变了就以为万事大吉。
