audit_trail=DB仅将审计日志存入SYS.AUD$表，需手动配置AUDIT语句或策略才能生效；该参数为静态，必须重启数据库才生效，且SYS登录默认不被审计，清理须用DBMS_AUDIT_MGMT包而非DELETE。
audit_trail=db 不能直接“自动审计”，它只是把日志存到 sys.aud$ 表里，真正要审计什么，还得手动配 audit 语句或策略。 启用 db 模式后不配具体规则，数据库照样安静如鸡——连谁连上来、执行了啥 ddl 都不会记。
audit_trail=DB 必须重启才生效
这个参数是静态的，改完不重启等于没改。常见错误是 ALTER SYSTEM SET audit_trail=DB SCOPE=SPFILE; 之后只 reload 或不重启，结果查 v$parameter 还是 NONE。
- 必须先 SHUTDOWN IMMEDIATE，再 STARTUP —— 中间不能跳步
- 重启后立刻验证：
SELECT name, value FROM v$parameter WHERE name = 'audit_trail';，输出值必须是DB（不是db或空格） - 如果实例启在只读模式下，Oracle 会悄悄把
audit_trail=DB覆盖成OS，并在 alert.log 里写警告，得检查日志确认
audit_trail=DB 下 SYS 登录默认不被审计
哪怕你设了 audit_sys_operations=TRUE，在 audit_trail=DB 模式下该参数也完全被忽略——这是 Oracle 的硬限制，不是配置漏了。
- 想审计 SYS / AS SYSDBA 登录，唯一有效路径是：先设
audit_trail=OS，再设audit_sys_operations=TRUE，然后重启 -
audit_sys_operations只能写进 spfile/pfile，不能 ALTER SYSTEM 动态改；改完不重启，值在 v$parameter 里显示 TRUE，但实际不生效 - DB 模式下，
CONNECT AS SYSDBA这类操作仍可能落进 OS 文件（比如audit_file_dest下的 .aud 文件），但这不是可控审计，而是内核兜底行为
audit_trail=DB 容易撑爆 SYSTEM 表空间
sys.aud$ 是堆表，无分区、无索引（默认），高频 DML 或开启 DB,EXTENDED 后，SQL 文本和绑定变量一塞，几分钟就能涨几百 MB。
- 别用
DELETE FROM sys.aud$清理——锁表 + 爆 undo/redo，生产库可能卡死 - 必须用
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL，且启用前先跑DBMS_AUDIT_MGMT.INIT_CLEANUP - 如果同时开了统一审计（12c+），
audit_trail=DB和UNIFIED_AUDIT_TRAIL会共存，但清理逻辑不互通，得两边都管
audit_trail=DB 不等于能查到所有操作
很多操作天然绕过标准审计路径，比如数据库启动/关闭、RMAN 备份、Data Pump 导入导出——这些即使 audit_trail=DB，也只可能出现在 OS 文件或专用视图里。
-
AUDIT SESSION只捕获成功登录；要抓失败尝试，得额外加AUDIT CONNECT WHENEVER NOT SUCCESSFUL - 对象审计（如
AUDIT SELECT ON hr.employees）只对显式 SQL 生效，不覆盖视图内嵌查询或函数调用里的访问 - 如果你用的是 19c 且没做二进制重链接（
make -f ins_rdbms.mk uniaud_on ioracle），那audit_trail=DB其实跑在混合模式下，UNIFIED_AUDIT_TRAIL视图查不到记录，但传统DBA_AUDIT_TRAIL还能查——这种状态最易误判为“审计失效”
真正麻烦的从来不是改参数，而是搞不清哪些操作能被 DB 模式捕获、哪些必须靠 OS 或统一审计补位，以及清理机制和空间增长之间的节奏是否匹配。
