查DBA角色授予情况必须用DBA_ROLE_PRIVS视图，WHERE GRANTED_ROLE = 'DBA'；ADMIN_OPTION='YES'可再授权，DEFAULT_ROLE='YES'登录即激活；多租户需查CDB_ROLE_PRIVS且CON_ID=0；V$PWFILE_USERS须同步检查SYSDBA用户；审计DBA变更必须启用AUDIT_SYS_OPERATIONS并查OS审计文件。
查 DBA 角色授予情况必须用 DBA_ROLE_PRIVS
直接查 dba_role_privs 是唯一可靠方式，其他视图（如 user_role_privs 或 all_role_privs）只返回当前会话可见的角色，无法覆盖全局。必须以有 select 权限的账号（如 sys、system 或已授权访问数据字典的用户）执行。
常见错误是误用 user_role_privs 查自己账号——结果永远为空或仅显示当前用户；或者漏加 WHERE GRANTED_ROLE = 'DBA'，导致返回全部角色授权记录，难以定位。
SELECT GRANTEE, ADMIN_OPTION, DEFAULT_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'DBA';-
ADMIN_OPTION = 'YES'表示该用户可再授予 DBA 角色（高危行为，需重点审计） -
DEFAULT_ROLE = 'YES'表示登录时自动激活 DBA 角色（即使未显式SET ROLE） - 多租户环境（CDB/PDB）下，需确认是否在根容器（CDB$ROOT）中查询，否则可能漏掉 CDB 级 DBA 用户
V$PWFILE_USERS 不等于 DBA 权限，但必须同步检查
V$PWFILE_USERS 显示的是拥有 SYSDBA / SYSOPER 系统权限的用户，这类权限独立于 DBA 角色，且能绕过常规审计和密码验证直接登录。它不反映 DBA 角色授予状态，但安全影响同等严重——两者都意味着近乎完全控制能力。
容易忽略的是：一个用户可能没有 DBA 角色，却通过 SYSDBA 登录后手动 GRANT DBA TO ...，此时 DBA_ROLE_PRIVS 里还没记录，但风险已存在。
SELECT USERNAME, SYSDBA, SYSOPER, SYSASM FROM V$PWFILE_USERS;-
SYSDBA = 'TRUE'的用户必须出现在你的高权限用户清单中，不能只盯 DBA 角色 - 该视图需
SELECT ANY DICTIONARY或SELECT_CATALOG_ROLE权限，普通 DBA 用户默认无权查 - 注意：
V$PWFILE_USERS只反映口令文件中的条目，不包含通过外部认证（如 OS auth）获得SYSDBA的情况
审计 DBA 权限变更必须开启 AUDIT_SYS_OPERATIONS
仅查快照没用——关键是要捕获“谁在什么时候把 DBA 授给了谁”。默认情况下，GRANT DBA TO ... 这类操作不会被标准审计捕获，除非显式启用 AUDIT_SYS_OPERATIONS 并重启实例。
典型误区是以为开了 AUDIT_TRAIL = DB 就够了，其实它只记录普通用户的 DDL/DML，对 SYS 或 SYSDBA 的权限操作无效。
- 启用命令：
ALTER SYSTEM SET AUDIT_SYS_OPERATIONS = TRUE SCOPE=SPFILE; - 重启数据库后，所有
SYS用户及SYSDBA登录者的操作（含GRANT、REVOKE）将写入操作系统审计文件，路径由AUDIT_FILE_DEST参数指定 - 不可依赖
DBA_AUDIT_TRAIL查这类操作——它只存AUDIT_TRAIL = DB下的记录，而AUDIT_SYS_OPERATIONS强制走 OS 文件 - 审计文件是纯文本，需用系统命令（如
grep "GRANT.*DBA" *.aud）提取，无法用 SQL 直接查询
生产环境应定期导出并比对 DBA 清单
单纯“查一次”解决不了问题。DBA 权限常因临时排障被授予，事后遗忘回收。真正有效的做法是建立基线 + 差异检测机制。
最易被忽略的点是：COMMON 列在多租户中决定权限是否跨 PDB 继承。设为 'YES' 意味着该 DBA 授权在所有 PDB 中自动生效，但 DBA_ROLE_PRIVS 查询默认只返回当前容器结果，不带 CDB$ROOT 上下文会误判范围。
- 建议脚本每天凌晨执行：
SELECT GRANTEE, ADMIN_OPTION, COMMON FROM CDB_ROLE_PRIVS WHERE CON_ID = 0 AND GRANTED_ROLE = 'DBA'; - 输出保存为带时间戳的 CSV，与前一日比对新增/删除项
- 对
ADMIN_OPTION = 'YES'的用户，额外检查其是否曾执行过GRANT DBA（需查AUDIT_SYS_OPERATIONS日志） - 禁止在应用账号上设置
DEFAULT_ROLE = 'YES'for DBA——这会让连接即获得最高权限，失去最小权限控制
