AUDIT DROP ANY TABLE 审计拥有该系统权限的用户删除非自身schema表的操作，不审计普通删表、SYS用户及未启用audit_trail参数的情况。
audit drop any table 是什么，它审计谁的操作
audit drop any table 审计的是拥有 drop any table 系统权限的用户执行的删表动作，不是普通用户删自己表的行为。比如 scott 用户被授予了该权限，他删 hr.employees 或 oe.inventories 这类非自己拥有的表，才会触发这条审计规则。
它不审计 DROP TABLE t1 这种删自己 schema 下表的操作——那种属于对象级审计，得用 AUDIT DROP ON scott.t1。
- 只对有
DROP ANY TABLE权限的用户生效（如 DBA、SYSTEM、自定义高权限账号） - 不审计
SYS用户，无论是否带AS SYSDBA——Oracle 明确禁止对SYS执行AUDIT/NOAUDIT - 即使用户没显式执行
DROP ANY TABLE，只要其会话中某条DROP TABLE xxx.yyy依赖该权限，就会被记录
BY SESSION 和 BY ACCESS 的区别直接影响日志密度
默认不加修饰时，AUDIT DROP ANY TABLE 等价于 BY SESSION：同一会话里不管删多少张表，只记一条审计记录。这是生产环境推荐的方式，避免 dba_audit_trail 表爆炸。
如果加 BY ACCESS，每次删表都生成一条独立记录，适合排查单次误操作，但高并发下可能迅速填满 AUD$ 表。
-
AUDIT DROP ANY TABLE BY SESSION;→ 同一会话删 5 张表，dba_audit_trail中只有 1 行 -
AUDIT DROP ANY TABLE BY ACCESS;→ 同一会话删 5 张表，dba_audit_trail中出现 5 行，obj_name字段各不同 -
WHENEVER SUCCESSFUL或WHENEVER NOT SUCCESSFUL可叠加使用，例如：AUDIT DROP ANY TABLE BY SESSION WHENEVER NOT SUCCESSFUL;
必须重启才能生效的两个关键参数
AUDIT DROP ANY TABLE 命令本身执行后立即生效，但前提是底层审计机制已启用。而 Oracle 要求两个静态参数必须设为有效值并重启实例：
-
audit_trail必须设为DB或DB,EXTENDED（推荐后者，能捕获sql_text） -
audit_sys_operations若想审计AS SYSDBA用户的删表行为，必须设为TRUE；但注意：这类记录不进dba_audit_trail，而是写入操作系统文件（路径由audit_file_dest指定）
这两个参数改完后必须执行 shutdown immediate + startup，否则 AUDIT 命令看似成功，实际无任何审计记录产生。
查不到记录？先确认这三件事
执行完 AUDIT DROP ANY TABLE 并重启后仍查不到审计记录，大概率卡在这三个环节：
- 目标用户确实有
DROP ANY TABLE权限吗？运行SELECT * FROM dba_sys_privs WHERE privilege = 'DROP ANY TABLE'; - 删表操作是否真的触发了该权限？比如
SCOTT删SCOTT.T1不走DROP ANY TABLE，而是走对象权限逻辑，不会被这条规则捕获 - 查询视图用的是
dba_audit_trail，但该视图默认只显示非SYS用户的记录；若怀疑是AS SYSDBA操作，得去audit_file_dest目录下翻.aud文件（Linux）或 Windows 事件查看器
真正容易被忽略的是权限上下文判断——不是“谁执行了 DROP”，而是“这条 DROP 语句依赖哪个权限才得以执行”。这个逻辑决定审计是否命中，而不是表面语法。
