结论：必须在备库启用adg_redirect_dml且满足实时应用、srl启用、非common用户等5个硬性前提，否则insert/update直接报ora-16397或ora-16000；该功能仅支持单表dml及无绑定变量pl/sql，不支持ctas、xa事务等，实际执行在主库，存在延迟与性能开销。
直接说结论：必须在备库启用 adg_redirect_dml，且主备库需满足实时应用、srl启用、非common用户等硬性前提，否则 insert/update 会直接报 ora-16397 或 ora-16000。
备库执行DML前必须确认的5个前提条件ADG_REDIRECT_DML 不是开关一按就灵的功能，它依赖底层Data Guard状态和权限模型：
- 主库和备库都已启用
real time apply（v$archive_dest_status.status = 'APPLYING_LOG'）
- 备库已配置并正在使用
standby redo logfile (SRL)（v$standby_log 非空且 status != 'UNASSIGNED'）
- 当前连接用户不能是
SYS、SYSTEM、C##SYS 等 common user；必须是 PDB 中的本地用户或带 C## 前缀的可插拔用户（如 C##HBHE）
- 备库
open_mode 必须是 READ ONLY WITH APPLY（不是 READ ONLY）
- 主库与备库的数据库唯一名（
db_unique_name）已在 tnsnames.ora 中正确定义，且备库能通过内部 DB Link 连通主库（无需手动建 link，但网络和监听必须通）
会话级启用比系统级更安全，推荐用 ALTER SESSION ENABLE ADG_REDIRECT_DML
系统级设置（ALTER SYSTEM SET adg_redirect_dml=TRUE）会影响所有新会话，一旦误配 COMMON 用户或未校验前提，容易引发批量失败。而会话级只对当前连接生效，可控性强：
- 执行前先确认当前用户身份：
SHOW USER 和 SELECT sys_context('USERENV','CON_NAME') FROM DUAL
- 在备库以目标用户登录后立即执行：
ALTER SESSION ENABLE ADG_REDIRECT_DML
- 该设置不持久——断开重连即失效，适合测试或临时业务场景
- 若执行后仍报
ORA-16397，优先检查 trace 文件（启用 ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'），错误原因通常落在「主库不可达」或「undo incarnation 不一致」上
INSERT/UPDATE 能跑通，但 CREATE TABLE AS SELECT 和含绑定变量的 PL/SQL 会失败
DML重定向不是全功能代理，Oracle 明确限制了部分语法：
- ✅ 支持：单表
INSERT、UPDATE、DELETE、简单 MERGE，以及 PL/SQL 块中不含绑定变量的 DML（如 EXECUTE IMMEDIATE 'INSERT INTO t VALUES(1)'）
- ❌ 不支持：
-
CREATE TABLE AS SELECT（报 ORA-16397，文档明确列出）
- PL/SQL 中带
:b1 类绑定变量的 DML（即使变量已赋值）
- 全局临时表（GTT）的 CTAS 操作
- XA 分布式事务中的任何 DML
- ⚠️ 注意：重定向后的 DML 实际在主库执行，所以主库的触发器、约束、审计策略全部生效；备库侧看不到这些逻辑的执行痕迹，只看到最终提交结果
最容易被忽略的性能与一致性陷阱
表面上“备库写数据”，实则是“主库扛压 + 日志双程传输”，这带来两个隐性成本：
- 每次 DML 提交前，备库会等待该变更的 redo 传回并应用完毕（即所谓“同步可见”），网络延迟高时，
COMMIT 耗时可能翻倍
- 主库 undo 表空间压力增大——因为重定向事务的 undo 也由主库管理，若备库高频写入，可能触发主库
ORA-01555
- 所有重定向 DML 对其他备库实例不可见，直到提交；如果业务依赖“写后立刻查”，且查询发往其他备库节点，会出现数据不一致假象
real time apply（v$archive_dest_status.status = 'APPLYING_LOG'）standby redo logfile (SRL)（v$standby_log 非空且 status != 'UNASSIGNED'）SYS、SYSTEM、C##SYS 等 common user；必须是 PDB 中的本地用户或带 C## 前缀的可插拔用户（如 C##HBHE）open_mode 必须是 READ ONLY WITH APPLY（不是 READ ONLY）db_unique_name）已在 tnsnames.ora 中正确定义，且备库能通过内部 DB Link 连通主库（无需手动建 link，但网络和监听必须通）ALTER SESSION ENABLE ADG_REDIRECT_DML
系统级设置（ALTER SYSTEM SET adg_redirect_dml=TRUE）会影响所有新会话，一旦误配 COMMON 用户或未校验前提，容易引发批量失败。而会话级只对当前连接生效，可控性强：
- 执行前先确认当前用户身份：
SHOW USER和SELECT sys_context('USERENV','CON_NAME') FROM DUAL - 在备库以目标用户登录后立即执行：
ALTER SESSION ENABLE ADG_REDIRECT_DML - 该设置不持久——断开重连即失效，适合测试或临时业务场景
- 若执行后仍报
ORA-16397，优先检查 trace 文件（启用ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'），错误原因通常落在「主库不可达」或「undo incarnation 不一致」上
INSERT/UPDATE 能跑通，但 CREATE TABLE AS SELECT 和含绑定变量的 PL/SQL 会失败
DML重定向不是全功能代理，Oracle 明确限制了部分语法：
- ✅ 支持：单表
INSERT、UPDATE、DELETE、简单 MERGE，以及 PL/SQL 块中不含绑定变量的 DML（如 EXECUTE IMMEDIATE 'INSERT INTO t VALUES(1)'）
- ❌ 不支持：
-
CREATE TABLE AS SELECT（报 ORA-16397，文档明确列出）
- PL/SQL 中带
:b1 类绑定变量的 DML（即使变量已赋值）
- 全局临时表（GTT）的 CTAS 操作
- XA 分布式事务中的任何 DML
- ⚠️ 注意：重定向后的 DML 实际在主库执行，所以主库的触发器、约束、审计策略全部生效；备库侧看不到这些逻辑的执行痕迹，只看到最终提交结果
最容易被忽略的性能与一致性陷阱
表面上“备库写数据”，实则是“主库扛压 + 日志双程传输”，这带来两个隐性成本：
- 每次 DML 提交前，备库会等待该变更的 redo 传回并应用完毕（即所谓“同步可见”），网络延迟高时，
COMMIT 耗时可能翻倍
- 主库 undo 表空间压力增大——因为重定向事务的 undo 也由主库管理，若备库高频写入，可能触发主库
ORA-01555
- 所有重定向 DML 对其他备库实例不可见，直到提交；如果业务依赖“写后立刻查”，且查询发往其他备库节点，会出现数据不一致假象
INSERT、UPDATE、DELETE、简单 MERGE，以及 PL/SQL 块中不含绑定变量的 DML（如 EXECUTE IMMEDIATE 'INSERT INTO t VALUES(1)'）-
CREATE TABLE AS SELECT（报ORA-16397，文档明确列出） - PL/SQL 中带
:b1类绑定变量的 DML（即使变量已赋值） - 全局临时表（GTT）的 CTAS 操作
- XA 分布式事务中的任何 DML
- 每次 DML 提交前，备库会等待该变更的 redo 传回并应用完毕（即所谓“同步可见”），网络延迟高时，
COMMIT耗时可能翻倍 - 主库 undo 表空间压力增大——因为重定向事务的 undo 也由主库管理，若备库高频写入，可能触发主库
ORA-01555 - 所有重定向 DML 对其他备库实例不可见，直到提交；如果业务依赖“写后立刻查”，且查询发往其他备库节点，会出现数据不一致假象
别把 DML 重定向当成读写分离的万能解。它适合低频、偶发、强一致要求的场景（比如报表系统补一条状态标记），不适合替代主库承载常规业务写入。
