能，但需满足dg_broker_start=true、实时应用启用、配置srl、使用本地用户四个硬性条件，否则报ora-16397；adg_redirect_dml支持会话级和系统级启用，会话级优先。
能，但必须满足几个硬性条件，否则直接报 ora-16397。这不是“开了参数就能用”的功能，而是依赖底层同步机制和权限模型的严格协同。
ADG_REDIRECT_DML 参数启用方式与作用范围
该参数控制 DML 是否被透明转发到主库执行，它只在备库生效，且分两级：
- 会话级优先：执行
ALTER SESSION ENABLE ADG_REDIRECT_DML后，当前会话后续所有 DML（INSERT/UPDATE/DELETE）自动重定向；会话退出即失效 - 系统级持久：执行
ALTER SYSTEM SET adg_redirect_dml=TRUE SCOPE=BOTH，对所有新会话生效；但已存在的会话仍需手动启用 - 两者不互斥，会话级设置会覆盖系统级设置
备库执行 DML 前必须确认的 4 个前提
缺一不可，否则哪怕参数开着也会失败：
-
DG_BROKER_START=TRUE必须在主库和备库都设为TRUE，否则内部重定向通道无法建立 - 备库必须启用实时应用（
REAL TIME APPLY），即v$managed_standby中PROCESS列含MRP0且状态为APPLYING_LOG - 使用 SRL（Standby Redo Log），不能只靠归档日志；可通过
SELECT * FROM v$standby_log验证是否存在 ACTIVE 状态的 SRL 组 - 当前用户不能是
SYS、SYSTEM或其他 common user（如C##xxx），必须是 PDB 内创建的本地用户（例如askscuti）
常见失败场景与对应错误原因
ORA-16397 是最典型的报错，背后实际原因差异很大：
- 主库连接串未配置或不可达：检查备库
tnsnames.ora中主库服务名是否可解析、监听是否正常、网络连通性是否 OK - 主备 undo 表空间模式不一致：主库是
AUTO，备库却是MANUAL（或反之），需统一为AUTO - 用户上下文不匹配：备库登录用户是
askscuti，但主库同名用户不存在或密码不同；注意重定向不是“用备库账号连主库”，而是用相同用户名+密码直连主库 - PL/SQL 块中含绑定变量：目前不支持重定向带
:b1这类 bind 的 PL/SQL 执行；纯 SQL DML 没问题，但BEGIN ... INSERT ... END;若含 bind 就会失败
验证重定向是否真正生效
光看语句执行成功不够，得确认变更确实走主库路径：
- 在备库会话中开启 10046 trace：
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12'，然后执行INSERT；跟踪文件里会出现类似*** REDIRECT TO PRIMARY ***的标记 - 查主库
v$transaction：DML 提交前，在主库执行SELECT xidusn,xidslot,xidsqn FROM v$transaction，应能看到新增事务（说明重定向已触发） - 观察备库
v$archive_dest_status中STATUS为VALID且ERROR为空，否则重定向链路中断
最关键的细节是：重定向 DML 在提交前仅对当前会话可见，其他会话（包括同一备库其他连接）看不到未提交数据——这和普通主库事务行为一致，但容易误判为“没同步”。别急着查表，先 COMMIT 再验证。
