REDO传输用户必须拥有SYSOPER权限，因LGWR/ARCH需调用系统级实例管理接口，且须主备库均授予并用AS SYSOPER验证连接，密码文件需同步、路径正确、权限为640。

为什么 REDO 传输用户必须有 SYSOPER？

因为 oracle data guard 的 lgwr 或 arch 进程在远端实例上执行日志传输时，需要调用底层实例管理接口（比如启动/关闭备用实例、挂载数据库），这些操作不走普通 sql 权限体系，而是依赖 sysoper 的系统级特权。没有它，alter system switch logfile 或主库归档触发后，备库收不到日志，v$archived_log 停滞，dg broker 报 ora-16703 或 ora-16826。

给 REDO 传输用户授 SYSOPER 的正确姿势

不能只在主库授，也不能只在备库授——必须两边都授，且必须用 AS SYSOPER 方式连接验证。常见错误是只在主库执行 GRANT SYSOPER TO dg_user，结果备库的 MRP 进程连不上主库归档源。

• 主库和备库都要执行：GRANT SYSOPER TO <redouser></redouser>
• 用户密码文件必须同步：修改任一端密码后，需用 ORAPWD 重建并手动拷贝到另一端，否则 ORA-01031: insufficient privileges
• 验证方式不是 CONNECT <redouser>/pwd</redouser>，而是：CONNECT <redouser>/pwd AS SYSOPER</redouser>
• 如果用的是 Oracle 12c 及以后的统一账户（如 CDB$ROOT 中创建），确保该用户在 PDB 中也有对应映射，否则 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 会失败

SYSOPER 和 SYSDBA 能否混用？

能连上，但不推荐。Oracle 官方文档明确建议：Data Guard 传输用户仅需 SYSOPER，授予 SYSDBA 属于权限过度。实际中，SYSDBA 用户可能意外执行 DROP DATABASE 或 SHUTDOWN ABORT，而 SYSOPER 天然禁止这些操作。更关键的是，某些安全审计策略（如 Oracle Database Vault）会拦截 SYSDBA 登录，却放行 SYSOPER，混用反而导致传输中断。

密码文件路径与权限容易被忽略的点

Oracle 默认从 $ORACLE_HOME/dbs/orapw<oracle_sid></oracle_sid> 读取密码文件，但 RAC 或使用 ASM 的环境常把密码文件放在 ASM 磁盘组里。此时必须确认：REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE，且 srvctl config database -d <db_name></db_name> 显示的密码文件路径与实际一致。否则即使授了权，LGWR 进程仍报 ORA-01017: invalid username/password——它根本没读到你刚加的用户。

另外，Linux 下该文件权限必须是 640，属主 oracle:oinstall；若为 600 或属组不对，ARCn 进程因无法读取而静默失败，日志里只留一句模糊的 password file not accessible。