查v$pwfile_users是唯一可靠方式确认sysdba/sysoper登录权限，其sysdba/sysoper字段为布尔值；需结合remote_login_passwordfile参数配置及密码文件重载机制综合判断。
查 V$PWFILE_USERS 是唯一可靠方式
想确认谁真能以 SYSDBA 或 SYSOPER 身份登录，必须查 V$PWFILE_USERS。它不依赖角色、不看 DBA_SYS_PRIVS，只读密码文件内容；sysdba 和 sysoper 字段是布尔值（TRUE/FALSE），不是字符串。
执行以下语句即可：
SELECT username, sysdba, sysoper FROM V$PWFILE_USERS;
常见错误包括：
- 在
DBA_SYS_PRIVS里搜'SYSDBA'—— 语法合法但永远空，因为SYSDBA不是系统权限，不走数据字典授权路径 - 用
SHOW USER看当前会话就断定“只有这个用户有权限”——这只是当前连接身份，不代表全局配置 - 查
DBA_ROLE_PRIVS找DBA角色成员来推断——DBA角色 ≠SYSDBA，前者是权限集合，后者是底层认证入口
用 strings 解析密码文件仅作辅助验证
当数据库不可连或权限不足时，可直接用操作系统命令检查密码文件内容。Oracle 密码文件（如 orapw<oracle_sid></oracle_sid>）是二进制格式，但用户名和哈希片段通常以明文形式嵌入其中。
在 Linux/Unix 下运行：
strings $ORACLE_HOME/dbs/orapw<oracle_sid> | grep -E "^[A-Z][A-Za-z0-9_]*$"</oracle_sid>
Windows 下对应路径为 %ORACLE_HOME%\database\PW%ORACLE_SID%.ora，可用 findstr 替代 grep。
该方法的限制：
-
strings不区分SYSDBA和SYSOPER，仅表明用户名被写入密码文件；是否启用仍需结合V$PWFILE_USERS的布尔值判断 - 密码文件可能被加密或混淆（尤其在较新版本中），
strings结果不完整 - RAC 环境下，每个节点独立维护密码文件，
strings只反映当前节点状态 - 文件权限需为 Oracle 用户可读，否则报
Permission denied
REMOTE_LOGIN_PASSWORDFILE 参数决定密码文件是否生效
即使密码文件存在且含用户记录，若初始化参数 REMOTE_LOGIN_PASSWORDFILE 设为 NONE，Oracle 就完全忽略它，只走操作系统认证。
该参数可设为：
-
NONE：禁用密码文件，所有SYSDBA登录依赖 OS 组（如dba组） -
EXCLUSIVE：允许除SYS外的用户写入密码文件，且仅一个实例可用 —— 这是启用V$PWFILE_USERS中非SYS用户的前提 -
SHARED：允许多实例共享，但只认SYS，其他用户即使出现在文件中也无效
检查当前设置：
SHOW PARAMETER remote_login_passwordfile;
若为 SHARED 却期望看到非 SYS 用户出现在 V$PWFILE_USERS 中，结果必然为空 —— 这不是查询错，是配置不匹配。
授予权限后必须重载或重启才生效
执行 GRANT SYSDBA TO user 后，V$PWFILE_USERS 不会立刻更新。Oracle 不实时同步数据字典变更到密码文件，而是依赖实例重启或显式重载机制。
触发重载的方法只有两个：
- 重启数据库实例（最稳妥）
- 执行
ALTER SYSTEM CHECKPOINT+ALTER SYSTEM FLUSH SHARED_POOL并不能刷新V$PWFILE_USERS；真正有效的重载动作是重建或覆盖密码文件（如用ORAPWD工具重新生成）
这意味着：刚授完权就查 V$PWFILE_USERS，很可能看不到新用户 —— 不是失败，只是还没落地。别急着删用户重试，先确认实例状态和参数配置。
