dba角色实际授予的用户需通过dba_role_privs视图查询，并关联dba_users验证账户状态为open且未过期；还需递归检查角色嵌套继承路径，排除sys/system等特殊账户及锁定过期账号。
查 DBA 角色实际授予了哪些用户
Oracle 中没有“最高管理员角色”这个官方定义，但 DBA 角色在实践中等价于最高权限集合——它包含几乎所有系统权限（如 CREATE ANY TABLE、DROP ANY PROCEDURE、ALTER DATABASE 等）。审计重点不是“谁该有”，而是“谁真有”。直接查 DBA_ROLE_PRIVS 视图最可靠：
SELECT grantee, granted_role, admin_option, default_role FROM dba_role_privs WHERE granted_role = 'DBA' ORDER BY grantee;
admin_option = 'YES' 表示该用户还能把 DBA 角色再授给别人，风险更高；default_role = 'YES' 表示登录即激活该角色，无需额外 SET ROLE。
注意 sys 和 system 的特殊性
SYS 和 SYSTEM 不依赖角色获得权限：SYS 以 SYSDBA 身份连接时，权限来自身份认证机制本身，不会出现在 DBA_ROLE_PRIVS 中；SYSTEM 默认拥有大量系统权限，但也不一定被显式授予 DBA 角色。所以必须单独检查：
- 用
SELECT username, account_status FROM dba_users WHERE username IN ('SYS', 'SYSTEM');确认账户状态是否为OPEN - 用
SELECT privilege FROM dba_sys_privs WHERE grantee IN ('SYS', 'SYSTEM');查看其直授系统权限（SYS通常有UNLIMITED TABLESPACE、SELECT ANY DICTIONARY等）
排除已锁定或过期的账号
即使用户被授予了 DBA 角色，若账户被锁或密码过期，实际无法登录执行高危操作。忽略这点会导致误判“有效管理员数量”。务必关联 DBA_USERS：
SELECT d.grantee, u.account_status, u.expiry_date FROM dba_role_privs d JOIN dba_users u ON d.grantee = u.username WHERE d.granted_role = 'DBA' AND u.account_status = 'OPEN' AND (u.expiry_date IS NULL OR u.expiry_date > SYSDATE);
常见陷阱：SCOTT、HR 等示例用户默认是 EXPIRED & LOCKED，即使曾被授过 DBA（极不推荐），也应从审计清单中剔除。
别漏掉通过角色嵌套继承 DBA 权限的用户
一个用户可能没被直接授 DBA，而是被授予了另一个角色（比如 APP_ADMIN），而该角色又被授了 DBA。这种间接路径容易被忽略。需递归查询：
SELECT DISTINCT grantee FROM dba_role_privs WHERE granted_role IN ( SELECT granted_role FROM dba_role_privs START WITH granted_role = 'DBA' CONNECT BY PRIOR grantee = granted_role );
更稳妥的做法是结合 SESSION_ROLES 或使用 DBMS_METADATA.GET_GRANTED_DDL('ROLE_GRANT', 'username') 检查具体用户的完整权限展开树——但生产环境慎用，避免性能抖动。
真正难的是确认“谁能在当前会话里执行 DROP USER ... CASCADE”这类操作，而不是单纯看角色列表。权限链越长，越要验证终端用户是否具备实际可用的上下文权限。
