ORA-01031在RMAN远程连接中根本不是角色授权问题，而是密码文件缺失或错误、SQLNET.AUTHENTICATION_SERVICES配置不当（如设为(NONE)）、或备库未同步正确命名的orapw文件所致。
RMAN远程连接报ORA-01031，根本不是角色没授够
ora-01031在rman里基本不看v$pwfile_users里有没有你这个用户——它只认密码文件里预置的、且必须是sys或显式写入密码文件的超级用户。哪怕你用grant sysdba to cata把角色授全了，rman照样拒绝，因为它压根不走数据字典查角色，只读密码文件。
常见错误现象：本地sqlplus / as sysdba能进，但rman target cata/cata@YONGDB就报错；或者rman target /也失败，说明连OS认证路径都卡住了。
- 确认连接串是否用了
sys@DB as sysdba格式（注意as sysdba不能省） - 检查
$ORACLE_HOME/dbs/orapw$ORACLE_SID是否存在，文件名必须严格匹配orapw+实际SID（比如orapworcl，不是orapwORCL或PWDorcl.ora） - 运行
orapwd file=orapw$ORACLE_SID list=y，输出里必须有SYS且TRUE在SYSDBA列
SQLNET.AUTHENTICATION_SERVICES设成(NONE)反而让RMAN连不上
很多人看到Windows下用(NTS)就照搬到Linux，结果RMAN直接挂掉。Linux/Unix环境里，如果sqlnet.ora里写了SQLNET.AUTHENTICATION_SERVICES=(NONE)，等于主动关掉了密码文件认证通道，RMAN连尝试读密码文件的机会都没有。
正确做法是删掉这行，或改成SQLNET.AUTHENTICATION_SERVICES=(ALL)。别信“设成(NONE)更安全”这种过时说法——RMAN依赖的就是密码文件这条路，堵死它就全瘫。
- 编辑
$ORACLE_HOME/network/admin/sqlnet.ora - 找到
SQLNET.AUTHENTICATION_SERVICES这一行，要么注释掉，要么改成(ALL) - 改完不用重启数据库，但建议
lsnrctl reload让监听器重载配置
辅助实例或备库连不上？先盯住密码文件拷没拷对
Data Guard建备库、RMAN duplicate时最容易栽在这儿：主库密码文件生成了，但没拷到备库相同路径，或者拷了但文件权限不对（oracle:oinstall组不可读），或者文件名写错了（比如PWDstandby.ora而不是orapwstandby）。
现象很典型：RMAN报ORA-01031，但tnsping通、监听lsnrctl services里服务也注册了——说明网络和监听都没问题，问题就在认证入口被堵死。
- 在备库执行
ls -l $ORACLE_HOME/dbs/orapw*，确认文件存在且属主是oracle，权限是-rw-r----- - 如果文件名是
PWDxxx.ora，立刻重命名为orapwxxx（xxx为实际SID） - 重建命令示例：
orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=your_sys_password entries=10
多租户环境下PDB连接失败，default role可能是隐形坑
12c+多租户架构里，公共用户（如c##admin）连特定PDB报ORA-01031，但连CDB$ROOT正常——大概率是DEFAULT ROLE被手动改过。即使你给用户授了SYSDBA，如果ALTER USER c##admin DEFAULT ROLE NONE过，那登录PDB时就不会激活该角色。
这不是RMAN特有问题，但RMAN target连接PDB时会触发同样的权限校验链。
- 查当前默认角色：
SELECT default_role FROM dba_users WHERE username = 'C##ADMIN'; - 恢复默认行为：
ALTER USER c##admin DEFAULT ROLE ALL; - 验证：
CONNECT c##admin/password@pdb_name AS SYSDBA，再试RMAN
真正麻烦的是密码文件路径、文件名、SQLNET配置这三处，任何一个字符错，RMAN就拒绝握手——它不像SQL*Plus那样给你多一次试错机会。
