查V$PWFILE_USERS是唯一可靠方式，因其直接读取密码文件中SYSDBA/SYSOPER授权记录，不依赖数据字典或角色；但需结合连接测试验证账户可用性，并注意OS认证用户不在该视图中。
查 V$PWFILE_USERS 是唯一能确认 SYSDBA/SYSOPER 的方式
oracle 中的 sysdba 和 sysoper 不是普通系统权限，不存于 dba_sys_privs 或角色体系里，而是靠密码文件认证。所以任何在 dba_sys_privs 里查 'sysdba' 的尝试都返回空——语法对，逻辑错。
真正有效的查询只有一条：
SELECT username, sysdba, sysoper FROM V$PWFILE_USERS;
注意：sysdba 和 sysoper 列是布尔值（TRUE/FALSE），不是字符串；该视图只反映“是否被写入密码文件”，不代表账户当前可用。
- 必须用具有
SELECT_CATALOG_ROLE或DBA权限的用户执行，普通用户查不到 - 如果刚用
GRANT SYSDBA TO user授权，但没重建密码文件（ORAPWD）并重启实例，这里不会立刻出现 -
username是大写的，哪怕建用户时用了小写或双引号，密码文件中仍以大写存储
别把 DBA 角色当成 SYSDBA
DBA 是一个预定义角色，包含大量系统权限（如 ALTER SYSTEM、CREATE USER），但它和 SYSDBA 完全无关。一个用户可以有 DBA 角色但无法以 SYSDBA 登录；反之，SYS 用户默认有 SYSDBA，但未必显式授予 DBA 角色。
检查谁被授了 DBA 角色，用：
SELECT grantee FROM DBA_ROLE_PRIVS WHERE granted_role = 'DBA';
- 结果里的用户 ≠ 能连
AS SYSDBA，只是拥有高权限操作能力 -
ADMIN_OPTION为YES表示该用户能把DBA角色再授给别人，这是权限扩散风险点 -
DEFAULT_ROLE为NO时，即使被授予DBA，登录后也不会自动激活——需手动SET ROLE DBA
警惕“匿藏用户”绕过 DBA_USERS 检查
有些用户不在 DBA_USERS 中显示，却能正常连接，这类用户叫“匿藏用户”（hidden users），常见于通过直接插入 SYS.USER$ 创建、或使用外部认证（如 OS 认证组）的账号。
排查方法不是依赖 DBA_USERS，而是查底层数据字典：
SELECT name FROM sys.user$ WHERE type# = 1 AND name NOT IN (SELECT username FROM dba_users);
- 返回的用户名需要人工核对：是否属于 Oracle 内部用户（如
XS$NULL）、是否被误删元数据、是否由 OS 组（dba组）成员直连 - 这类用户若同时出现在
V$PWFILE_USERS中，就构成双重隐蔽路径——既绕过常规用户视图，又具备SYSDBA能力 - 尤其注意
name字段含特殊字符或空格的情况，可能被过滤逻辑忽略
验证权限不能只看视图，必须实测连接
V$PWFILE_USERS 显示某用户有 sysdba = TRUE，不代表此刻就能登录。账户可能被锁、密码过期、或被 ALTER USER ... ACCOUNT LOCK 禁用。
最稳妥的验证方式是模拟连接：
sqlplus /nolog SQL> CONNECT username/password AS SYSDBA
- 成功则说明权限真实有效；失败时错误码比提示文字更有价值：
ORA-01017（密码错）、ORA-28000（账户锁定）、ORA-01031（权限不足）要分别对待 - OS 认证用户（如 Linux 下属于
dba组）无需密码即可连AS SYSDBA，这种路径不会出现在V$PWFILE_USERS中，必须结合id命令和sqlplus / as sysdba测试 - 生产环境审计时，仅靠 SQL 查询视图容易漏掉 OS 层或密码文件外的认证通道
