Oracle 19c ADG物理备库不自动同步CREATE USER等安全DDL，因日志应用机制跳过用户元数据操作；需手动导出主库用户DDL并在备库MOUNT状态执行，密码修改可自动同步，但权限、角色、Wallet需单独处理。
Oracle 19c ADG 不自动同步新增用户
主库上用 CREATE USER 新建的普通用户（非 Oracle 内置账户）不会自动同步到物理备库（Physical Standby），这是设计使然，不是配置遗漏或故障。ADG 的日志应用机制只重放 DML 和部分 DDL 的逻辑变更，但用户创建、密码、权限等元数据操作在物理备库上被跳过——因为备库的控制文件、数据字典结构与主库严格一致，且不允许直接写入。
为什么 CREATE USER 在备库不可见
物理备库处于 READ ONLY WITH APPLY 或 MOUNT 状态，其数据字典由主库归档日志驱动恢复，而非实时执行 SQL。Oracle 明确将以下操作标记为“non-logged”或“not propagated”：
-
CREATE USER、ALTER USER（含密码修改）、DROP USER -
GRANT/REVOKE系统权限或对象权限 -
CREATE ROLE、SET PASSWORD等安全相关 DDL
即使你看到主库的 CREATE USER u1 IDENTIFIED BY pwd1; 被记录进归档日志，备库在应用时也会静默忽略——这不是 bug，是 Oracle Data Guard 的行为契约。
手动同步用户的可行路径
若业务确实需要备库存在同名用户（例如用于 GoldenGate 抽取、监控连接、或切换后立即可用），必须人工干预。关键点是：不能在备库直接执行 DDL（会破坏同步），而应通过主库触发可传播的操作：
- 对新用户启用
DEFAULT ROLE或分配PROXY CONNECT权限前，先确认该角色/代理用户已在主备库都存在 - 若用户需访问特定表，优先用
CREATE SYNONYM+ 公共同义词（需主备库均创建），而非依赖用户级对象权限 - 最稳妥方式：在主库创建用户后，立刻导出其 DDL（用
DBMS_METADATA.GET_DDL('USER', 'U1')），再在备库切换至MOUNT状态下，用SQL*Plus手动执行（仅限备库未启用实时应用时；启用中则必须停应用） - 密码同步无需额外操作：19c 起，
ALTER USER ... IDENTIFIED BY修改密码会通过密码文件同步机制自动传播（见 MOS Doc ID 2307365.1），但仅限密码本身，不包括用户创建动作
容易被忽略的权限同步陷阱
即使你把用户建到了备库，权限仍可能不生效：
- 备库的
SELECT ANY DICTIONARY权限默认不继承主库授予状态，需单独授权 -
SELECT_CATALOG_ROLE等预定义角色，在备库中需显式启用（SET ROLE SELECT_CATALOG_ROLE）才能生效 - 如果使用 Oracle Wallet 存储凭证，主库更新 wallet 后，必须手动拷贝
ewallet.p12到备库对应路径并重启监听，否则CONNECT / AS SYSDBA可能失败
真正需要“自动同步用户”的场景，往往暴露了架构问题：物理备库不该承担连接认证职责。考虑用统一目录服务（如 OID/LDAP）或前置代理层解耦身份管理，比硬同步更可持续。
