查DBA角色权限需满足四条件：GRANTED_ROLE='DBA'（必须大写单引号）；GRANTEE为真实用户（需关联DBA_USERS或排除DBA_ROLES）；同步查询V$PWFILE_USERS中SYSDBA='TRUE'的口令文件用户；DEFAULT_ROLE='YES'才属活跃DBA。
查 DBA_ROLE_PRIVS 视图必须用大写 'DBA' 作为角色名
Oracle 内部把所有角色名统一存为大写，GRANTED_ROLE = 'DBA' 是唯一能命中记录的写法。GRANTED_ROLE = 'dba' 或 GRANTED_ROLE = "DBA" 都查不到结果。别在大小写或引号上浪费时间调试——直接写死大写单引号字符串。
只看真实用户，得排除中间角色（比如 APP_ADMIN）
DBA_ROLE_PRIVS 的 GRANTEE 字段可能是用户名，也可能是另一个角色。如果你只想知道“谁可以直接登录并执行 DROP USER”，就得过滤掉非用户实体：
- 加条件
AND GRANTEE IN (SELECT USERNAME FROM DBA_USERS) - 或者更稳妥地用
AND GRANTEE NOT IN (SELECT ROLE FROM DBA_ROLES)
漏掉这步，结果里会出现一堆角色名，干扰判断。
V$PWFILE_USERS 必须同步查，它不走角色体系
一个用户可能没被授予 DBA 角色，却在口令文件里被标记为 SYSDBA——这意味着他能绕过密码验证、跳过审计、直接以最高权限登录。这种账号不会出现在 DBA_ROLE_PRIVS 里，但风险等同。
执行：SELECT USERNAME, SYSDBA FROM V$PWFILE_USERS WHERE SYSDBA = 'TRUE';
注意：V$PWFILE_USERS 需要 SELECT ANY DICTIONARY 或 SELECT_CATALOG_ROLE 权限；普通 DBA 用户默认无权访问，得提前授权或换 SYS 账号执行。
DEFAULT_ROLE = 'YES' 才算“活跃”，否则需手动 SET ROLE
DBA_ROLE_PRIVS.DEFAULT_ROLE 是关键字段：只有值为 'YES'，用户登录后才自动激活 DBA 角色。如果是 'NO'，哪怕授了角色，也得显式执行 SET ROLE DBA; 才能生效——而生产环境多数会禁用该命令。
所以真正“活跃”的 DBA 用户，应满足：
GRANTED_ROLE = 'DBA'-
GRANTEE是真实用户名（非角色） DEFAULT_ROLE = 'YES'
别忽略 DEFAULT_ROLE，这是最容易被跳过的判断点——很多审计报告只列名单，不区分“已激活”和“仅授予”。
