查V$PWFILE_USERS是唯一可靠方式确认SYSDBA登录权限，其sysdba/sysoper字段为布尔值；strings解析密码文件仅显示用户名存在，不区分权限类型；授予权限后需重启或重载密码文件才生效。
查 V$PWFILE_USERS 是唯一可靠方式
想确认谁真能以 sysdba 身份登录，必须查 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>）是二进制格式，但用户名和哈希片段通常以明文形式嵌入其中。
在 Oracle 安装目录的 $ORACLE_HOME/dbs（Linux/Unix）或 %ORACLE_HOME%\database（Windows）下运行：
strings orapw<oracle_sid> | grep -E "^[A-Z][A-Za-z0-9_]*$"</oracle_sid>
输出中能看到类似 WZDBRA、TEST 这样的用户名行，说明它们被写入了密码文件——但注意：strings 不区分 SYSDBA 和 SYSOPER，仅表明存在记录；是否启用仍需结合 V$PWFILE_USERS 的布尔值判断。
该方法的限制：
- 密码文件可能被加密或混淆（尤其在较新版本中），
strings结果不完整 - RAC 环境下，每个节点独立维护密码文件，
strings只反映当前节点状态 - 文件权限需为 Oracle 用户可读，否则报
Permission denied
授予权限后必须触发密码文件重载
执行 GRANT SYSDBA TO user 后，V$PWFILE_USERS 不会立刻更新。Oracle 不实时同步数据字典变更到密码文件，而是依赖实例重启或显式重载机制。
生效条件如下：
- 数据库重启（最稳妥）
- 使用
ALTER DATABASE OPEN RESETLOGS（仅适用于特定恢复场景） - 或手动重建密码文件：用
orapwd工具重新生成，但注意orapwd默认只设置SYS密码，其他用户权限需在重建前已存在于原文件中，否则会丢失
orapwd 常见误用：
- 漏掉
force=y导致 “file exists” 错误 - 指定
entries过小，后续再GRANT新用户会失败（报 ORA-01994） - 在 RAC 中只在单节点运行
orapwd，其他节点密码文件未更新，导致跨节点登录失败
查到用户≠能真正登录，必须验证可用性
V$PWFILE_USERS 显示 username 和 sysdba=TRUE，只代表该用户“被登记在密码文件中”，不保证账户本身可用。还需检查：
- 用户是否被锁定：
SELECT account_status FROM dba_users WHERE username = 'WZDBRA';—— 状态不能是LOCKED或EXPIRED & LOCKED - 密码是否过期：
SELECT password_expired FROM dba_users WHERE username = 'WZDBRA'; - OS 层权限（尤其
SYSOPER）：Linux 下需属于oinstall或dba组，Windows 下需属于ORA_DBA组
最直接的验证方式是实测连接：
sqlplus WZDBRA/password@db_alias AS SYSDBA
若报 ORA-01017: invalid username/password 或 ORA-01031: insufficient privileges，说明虽然进了密码文件，但凭证或 OS 权限链断裂——这种细节最容易被忽略。
