必须带WHENEVER NOT SUCCESSFUL才能捕获越权行为，因其专门记录返回非零错误码（如ORA-01031）的失败操作；仅AUDIT语句本身默认只审计成功动作，无法捕获权限不足类越权尝试。
audit 语句必须带 WHENEVER NOT SUCCESSFUL 才能捕获越权行为
越权操作（比如普通用户尝试 drop table、执行 dbms_lob 等需高权限的包）通常以 ora-01031: insufficient privileges 错误结束。oracle 审计默认只记录成功操作，不记录失败动作，所以光写 audit drop any table 是无效的——它只会审计“删除成功”的场景，而越权根本到不了执行阶段。
真正起作用的是 WHENEVER NOT SUCCESSFUL 子句，它明确告诉 Oracle：只要这条权限操作返回非零 returncode（即报错），就记一条审计日志。
AUDIT DROP ANY TABLE WHENEVER NOT SUCCESSFUL;AUDIT EXECUTE ANY PROCEDURE WHENEVER NOT SUCCESSFUL;AUDIT SELECT ANY TABLE WHENEVER NOT SUCCESSFUL;
注意：这些语句无需指定 BY user，因为越权行为往往发生在未知用户身上；若只想盯特定账号，可加 BY scott，但会漏掉其他人的试探性操作。
查越权记录得用 dba_audit_trail + returncode 过滤
审计开启后，失败操作不会出现在 dba_audit_object 或 dba_audit_statement 里，必须查最底层的 dba_audit_trail，并过滤 returncode != 0。
典型查询：
SELECT os_username, username, userhost, terminal, timestamp, action_name, returncode, sql_text FROM dba_audit_trail WHERE returncode != 0 AND timestamp > SYSDATE - 1 ORDER BY timestamp DESC;
关键点：
-
returncode是 Oracle 错误码，ORA-01031 对应值为 1031，但直接用!= 0更稳妥（涵盖所有权限类错误） -
sql_text在audit_trail = db_extended时才有内容；若只是db，该列为 NULL - 时间范围务必限制，否则全表扫描极慢，尤其
sys.aud$表没分区时
audit_sys_operations = TRUE 是查 DBA 越权的前提
如果攻击者用 conn / as sysdba 尝试越权（比如删核心表、改参数），默认情况下这些操作根本不会进 sys.aud$ —— 因为数据库可能还没起来，aud$ 不可用。
必须设置：
ALTER SYSTEM SET audit_sys_operations = TRUE SCOPE=SPFILE;
重启后，这类操作才会写入操作系统文件，路径由 audit_file_dest 决定（如 /u01/app/oracle/admin/ORCL/adump/），文件名含 PID，格式为 ora_12345.aud。
容易忽略的坑：
- 这个参数和
audit_trail无关，即使audit_trail = none，它也生效 - Linux 下得配合
audit_syslog_level才能进 syslog，否则只落本地 .aud 文件 - Windows 平台会进事件查看器，不是文本文件，得用 Event Viewer 查
权限审计和对象审计不能混用，越权场景优先选权限级
想抓“谁试图删表”，不要写 AUDIT DROP ON hr.employees（这是对象级，只对 hr.employees 生效）；而要写 AUDIT DROP ANY TABLE WHENEVER NOT SUCCESSFUL（权限级，覆盖所有表）。
两者的本质区别：
-
SYSTEM权限审计（如DROP ANY TABLE）：捕获用户是否被授予权限、以及是否尝试使用它 -
OBJECT审计（如AUDIT DELETE ON scott.emp）：只管具体对象上的 DML，不管权限来源
越权本质是“无权却试权”，所以必须用权限审计。对象审计对越权几乎无效——用户连表都看不见，根本触发不了对象级审计。
真正难处理的不是开不开审计，而是 sys.aud$ 表撑爆 SYSTEM 表空间导致普通用户无法登录。一旦开了 WHENEVER NOT SUCCESSFUL，失败登录、越权尝试都会高频写入，得定期清理或转储，否则第二天业务就挂了。
