查哪些用户拥有dba权限必须用dba_role_privs视图并过滤granted_role='dba'，因dba是角色而非系统权限，不会出现在dba_sys_privs中；同时需同步检查v$pwfile_users中sysdba用户及多租户下cdb_role_privs。
查哪些用户拥有 dba 权限，不能只看 dba_sys_privs 里有没有 dba 这条记录——dba 是角色，不是系统权限，它不会出现在 dba_sys_privs 中。真正可靠的方式是查 dba_role_privs 视图，过滤 granted_role = 'dba'。
必须用 DBA_ROLE_PRIVS 查 DBA 角色授予情况
这是唯一能准确反映“谁被授予了 DBA 角色”的视图。其他视图如 USER_ROLE_PRIVS 或 ALL_ROLE_PRIVS 只返回当前会话可见的角色，无法覆盖全局；DBA_SYS_PRIVS 则根本不会存角色授权记录。
SELECT GRANTEE, ADMIN_OPTION, DEFAULT_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'DBA'-
ADMIN_OPTION = 'YES'表示该用户还能把DBA角色再授给别人，属于高危配置，需重点审计 -
DEFAULT_ROLE = 'YES'表示登录时自动激活DBA角色，无需手动SET ROLE - 执行前确认你有
SELECT ANY DICTIONARY或DBA权限，否则会报ORA-00942
别漏掉 V$PWFILE_USERS 里的 SYSDBA 用户
V$PWFILE_USERS 显示的是口令文件中被允许以 SYSDBA 或 SYSOPER 身份直接登录的用户，这类权限独立于 DBA 角色，但控制力等同甚至更强——它能绕过常规密码验证和审计机制。
SELECT USERNAME, SYSDBA, SYSOPER FROM V$PWFILE_USERS- 只要
SYSDBA = 'TRUE'，该用户就必须纳入高权限清单，不能只盯DBA_ROLE_PRIVS - 这个视图需要
SELECT ANY DICTIONARY或SELECT_CATALOG_ROLE才能访问 - 注意：
V$PWFILE_USERS不包含通过 OS 认证（如OS_AUTHENT_PREFIX）获得SYSDBA的用户
多租户环境（CDB/PDB）下必须查 CDB_ROLE_PRIVS
在 CDB 架构中，DBA_ROLE_PRIVS 默认只返回当前容器（PDB）的数据。如果 DBA 角色是在根容器（CDB$ROOT）中授予的，你在 PDB 里查不到。
- 先确认是否在
CDB$ROOT中执行：SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL - 若需查整个 CDB 的 DBA 授予情况，改用：
SELECT GRANTEE, CON_ID FROM CDB_ROLE_PRIVS WHERE GRANTED_ROLE = 'DBA' AND CON_ID = 0 -
CON_ID = 0表示 CDB 级别；非零值为具体 PDB，需逐个检查或加IN条件
审计 DBA 权限变更必须启用 AUDIT_SYS_OPERATIONS
仅查快照没用。默认情况下，GRANT DBA TO user 这类操作不会被标准审计捕获，除非显式启用 AUDIT_SYS_OPERATIONS 并重启实例。
- 启用命令：
ALTER SYSTEM SET AUDIT_SYS_OPERATIONS = TRUE SCOPE=SPFILE - 重启后，相关操作会写入操作系统审计文件（路径由
AUDIT_FILE_DEST决定），而非数据库表 - 误以为
AUDIT_TRAIL = DB就够了——它只记录普通用户的 DDL/DML，对SYS或SYSDBA的权限操作无效
真正难的不是查到结果，而是确认“DBA 权限是否实际生效”：一个用户可能刚被授了 DBA 角色，但 DEFAULT_ROLE = 'NO'，又没手动 SET ROLE，那他登录后其实没有 DBA 能力；反过来，V$PWFILE_USERS 里的 SYSDBA 用户哪怕没被授任何角色，也能直接执行任意操作。这两条路径必须分开验、一起管。
