ORA-16191 根本原因是主备密码文件不匹配或认证被拒，表现为LNS连接被拒绝；需确保主备orapw<sid>字节级一致、remote_login_passwordfile均为EXCLUSIVE、SYS或SYSDG用户权限正确，且12c+需注意大小写敏感性。
ORA-16191 报错直接说明主备密码文件不匹配或认证被拒
这个错误不是传输延迟或网络抖动导致的，而是 oracle data guard 在尝试建立 log writer（lns）到远程 standby 的连接时，被 oraagent 或 lgwr 进程明确拒绝——根本原因是密码文件校验失败。它通常出现在首次搭建、主库密码文件更新后未同步、或启用了强密码验证（remote_login_passwordfile=exclusive 但备库没跟上）的场景。
常见错误现象包括：ALTER SYSTEM SWITCH LOGFILE 后主库归档日志卡在 STATUS=VALID 但备库收不到；DG_BROKER 显示 Transport Lag 持续增长且无错误日志；SELECT STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2; 返回 ERROR: ORA-16191: User not authorized to log on to standby database。
- 必须确认主备两端的
orapw<sid>文件是否完全一致（字节级），尤其注意大小写、空格、换行符 - 检查主备
remote_login_passwordfile参数值是否均为EXCLUSIVE（SHARED不支持 SYS 登录 DG 传输） - 若使用 Oracle 12c 及以上，
sys密码区分大小写，且备库密码文件必须包含主库中用于 DG 传输的用户（通常是SYS，也可能是自定义的SYSDG） - 密码文件路径必须正确：默认是
$ORACLE_HOME/dbs/orapw<sid>，RAC 环境下每个实例都要有且内容一致
怎么验证密码文件是否真的同步了
别只看文件名和时间戳，Oracle 校验的是内部哈希和记录条目。最稳妥的方式是用 orapwd 工具导出用户列表并比对。
在主库执行：orapwd describe file=$ORACLE_HOME/dbs/orapw<sid>，输出类似：
USERID USERNAME SYSDBA SYSOPER SYSASM 0 SYS TRUE TRUE FALSE
同样在备库执行该命令，逐行比对输出。重点看 USERNAME 和对应权限列是否一致；如果备库输出为空、或缺少 SYS 行、或 SYSDBA 列为 FALSE，就坐实了密码文件不一致。
- 不要用
scp复制后直接覆盖——先停掉备库实例（shutdown immediate），再替换，否则 Oracle 可能缓存旧文件句柄 - 如果主库用
orapwd重新生成过密码文件（例如改了force=y），必须重新拷贝整份文件，不能只追加用户 - RAC 环境下，每个节点的
orapw<sid>必须完全相同，建议用md5sum校验
为什么改了 sys 密码后 DG 就断了
因为 ALTER USER sys IDENTIFIED BY ... 默认只更新数据字典，不会自动刷新密码文件——除非你显式指定 IDENTIFIED BY VALUES 或用 orapwd 重建。DG 传输依赖的是密码文件里的哈希值，不是数据字典里的密码。
- 主库改
sys密码后，必须立刻运行：orapwd file=$ORACLE_HOME/dbs/orapw<sid> password=<new_pwd> entries=10 force=y - 然后把新文件 scp 到备库相同路径，并重启备库实例（仅重启实例即可，不用重启监听）
- 如果主库启用了
SEC_CASE_SENSITIVE_LOGON=TRUE（12c+ 默认），备库也必须保持一致，否则即使密码文件一样，SYS登录也会因大小写策略差异被拒 - 不建议在生产环境用
orapwd的ignorecase=y参数来绕过大小写问题，这会削弱安全性且不符合 Oracle 最佳实践
SYSDG 用户比 SYS 更适合做 DG 传输账号吗
是的，而且 Oracle 官方文档明确推荐。用独立账号隔离职责，避免 SYS 密码轮换频繁触发 DG 中断。
创建方式很简单：CREATE USER sysdg IDENTIFIED BY <pwd>; GRANT SYSDG TO sysdg;，然后用 orapwd 把 sysdg 加进密码文件（orapwd ... add=y user=sysdg password=<pwd>）。主备两边都操作完后，在主库设置：ALTER SYSTEM SET log_archive_dest_2='SERVICE=standby_db LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db' SCOPE=BOTH; 并确保 log_archive_dest_2 的连接串里用的是 sysdg/<pwd>@standby_db。
- SYSDG 权限最小够用，只允许执行 DG 相关操作，不涉及数据字典修改
- 后续只需轮换
sysdg密码，不影响SYS的其他管理任务 - 注意：11g 不支持 SYSDG，最低需 12.1；12c 中该用户默认不存在，必须手动创建
- 如果用了 SYSDG，
V$DATAGUARD_CONFIG和DGMGRL的连接信息里也得对应更新，否则 Broker 仍会尝试用 SYS 连接
真正麻烦的从来不是发现 ORA-16191，而是以为“文件拷过去了就完了”，结果忘了 RAC 节点多副本、忘了密码文件不随 ALTER USER 自动更新、忘了大小写策略跨版本不兼容——这些点漏一个，DG 就静默挂起，日志里连个 WARNING 都不打。
