必须启用audit_sys_operations=true并重启实例才能审计grant dba操作，日志写入os文件而非dba_audit_trail；未开启时需结合数据字典、会话和awr反推，并检查v$pwfile_users防止权限绕过。
查不到 GRANT DBA 操作？默认审计根本不管它
Oracle 默认不记录 GRANT DBA TO 这类语句，哪怕你开了 AUDIT_TRAIL = DB。它只捕获普通用户的 DDL/DML，对 SYS、SYSDBA 执行的权限变更完全静默。想追溯“谁在什么时候授了 DBA”，必须提前启用 AUDIT_SYS_OPERATIONS = TRUE 并重启实例——这是唯一有效路径。
常见错误是以为审计已开就万事大吉，结果翻遍 DBA_AUDIT_TRAIL 也找不到记录。别查了，先确认参数：
SELECT value FROM V$PARAMETER WHERE name = 'audit_sys_operations';
返回 TRUE 才算生效；否则所有后续审计都白搭。
审计日志不在数据库里，得去操作系统文件找
启用 AUDIT_SYS_OPERATIONS 后，GRANT DBA TO 日志不会进 DBA_AUDIT_TRAIL，而是写入操作系统的审计文件（通常在 $ORACLE_BASE/admin/$ORACLE_SID/adump/ 下，文件名类似 orcl_ora_12345_20260827.aud）。
关键点：
- 日志条目中会包含完整 SQL 文本，例如 grant dba to scott;
- 时间戳、OS 用户名、Oracle 用户名（如 SYS 或 SYSTEM）、客户端 IP 都会一并记录
- 文件是纯文本，可用 grep -i "grant.*dba" *.aud 快速定位
- 注意：如果用了 OS 认证（如 OS_AUTHENT_PREFIX），OS 用户名可能和 Oracle 用户名不一致，需交叉比对
没开审计？只能靠时间窗口+数据字典快照反推
如果审计从未开启，无法直接还原“谁授的”，但可以缩小嫌疑人范围：
- 查
DBA_ROLE_PRIVS中该用户的CREATED时间（部分 Oracle 版本在数据字典中保留时间戳字段；19c 中需依赖DBA_AUDIT_OBJECT的间接线索或自建快照表） - 结合业务系统变更记录：DBA 权限授予往往伴随运维工单、脚本执行时间、备份时间点
- 检查最近登录的高权限账号：
SELECT USERNAME, LOGON_TIME FROM V$SESSION WHERE USERNAME IN ('SYS', 'SYSTEM', 'DBA_ADMIN');—— 时间靠近授予权限时刻的会话更可疑 - 若用户刚被授 DBA 就立刻执行了敏感操作（如
ALTER SYSTEM），从V$SQL或 AWR 报告中可反向锁定源头会话
回收权限时别漏掉口令文件里的 SYSDBA 用户
单纯 REVOKE DBA FROM scott; 不够。如果 scott 同时在 V$PWFILE_USERS 中 SYSDBA = 'TRUE'，他仍能绕过角色控制直接以最高权限登录并再次授出 DBA。
务必同步检查：
SELECT USERNAME, SYSDBA FROM V$PWFILE_USERS WHERE USERNAME = 'SCOTT';
如果存在，必须用 orapwd 工具重建口令文件并剔除该用户，或联系 DBA 清理 OS 层认证配置。
真正的风险点从来不在 SQL 语句本身，而在于你是否把 V$PWFILE_USERS 和 CDB_ROLE_PRIVS（多租户下）一起纳入追踪范围——漏掉任何一个，审计链就断了。
