Oracle Data Guard日志传输不依赖用户账号，因由LGWR/ARCH进程直接发送重做流，无需SQL层认证；所谓“同步用户”实为Broker执行Switchover等管理操作所需的身份凭证，须用最小权限专用用户（如dg_user），授予SELECT相关V$视图及ALTER SYSTEM权限，而非SYS或普通DBA。
为什么不能用SYS或普通DBA账号做DG同步
Oracle Data Guard日志传输不走SQL层，而是由LGWR或ARCH进程直接调用网络协议发重做流，所以根本不需要“用户密码”参与传输过程。所谓“同步用户”，其实是Broker（DGMGRL）执行SWITCHOVER、FAILOVER、状态检查等管理操作时需要的身份凭证——不是用来传日志，而是用来连库发命令。
用SYS账号风险高：一旦Broker配置泄漏或Observer被入侵，攻击者可直接获得最高权限；用普通DBA角色账号又容易漏掉关键系统视图访问权限，导致DGMGRL SHOW DATABASE VERBOSITY报错或FSFO卡在Waiting for primary to become unavailable。
必须授予的最小权限集
专用DG用户只需具备以下四类权限，无需DBA或SYSDBA：
-
SELECTonV_$DATABASE,V_$ARCHIVE_DEST_STATUS,V_$MANAGED_STANDBY,V_$DATAGUARD_STATS -
SELECTonV_$INSTANCE（用于判断当前角色和启动时间） -
EXECUTEonDBMS_LOGSTDBY（仅当启用逻辑备库时需要） -
ALTER SYSTEM（Broker执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE等操作必需）
建用户示例：
CREATE USER dg_user IDENTIFIED BY "StrongPass123!" ACCOUNT UNLOCK; GRANT CREATE SESSION TO dg_user; GRANT ALTER SYSTEM TO dg_user; GRANT SELECT ON V_$DATABASE TO dg_user; GRANT SELECT ON V_$ARCHIVE_DEST_STATUS TO dg_user; GRANT SELECT ON V_$MANAGED_STANDBY TO dg_user; GRANT SELECT ON V_$DATAGUARD_STATS TO dg_user; GRANT SELECT ON V_$INSTANCE TO dg_user;
Broker里怎么绑定这个用户
不是在log_archive_dest_2里填用户名，而是在Broker配置中为每个数据库对象显式指定连接凭据：
- 主库上执行：
EDIT DATABASE 'primary_db' SET PROPERTY ConnectIdentifier = 'primary_db/dg_user/StrongPass123!'; - 备库上执行：
EDIT DATABASE 'standby_db' SET PROPERTY ConnectIdentifier = 'standby_db/dg_user/StrongPass123!';
注意：ConnectIdentifier值必须是TNS别名+/+用户名+/+密码三段式，且该TNS别名在Broker所在主机（通常是主库或Observer）的$ORACLE_HOME/network/admin/tnsnames.ora中已定义。如果Broker连的是RAC，还要确保ConnectIdentifier指向SCAN地址或含所有实例的LOAD_BALANCE配置。
最容易被忽略的验证点
配完不等于生效。必须手动触发一次Broker级探测：
- 运行
DGMGRL> VALIDATE DATABASE 'primary_db';，确认输出中Connection succeeded且无ORA-01017或ORA-00942 - 查
V$DATAGUARD_CONFIG，确认DB_NAME列显示的数据库都处于VALID状态，不是ERROR - 如果启用了FSFO，必须再查
SELECT FSFO_STATUS FROM V$DATABASE;——只有返回SYNCHRONIZED才算真正就绪，否则ENABLE FAST_START FAILOVER只是假启用
密码过期、TNS解析失败、视图授权遗漏这三类问题，在DGMGRL日志（$ORACLE_HOME/rdbms/log/drc*.log）里通常只报Failed to connect，不会说明具体缺哪个权限或哪行TNS写错，得逐项回溯。
