必须设AUDIT_SYS_OPERATIONS=TRUE并重启数据库，否则查不到SYSDBA的SQL操作记录；启用后日志强制写入audit_file_dest指定的操作系统文件（如ora_12345.aud），而非数据库表，需用tail等命令查看文件内容验证。
必须设 audit_sys_operations=true 并重启数据库，否则查不到任何 sysdba 的 sql 操作记录——audit_trail 设成 db 或 os 都无效。
为什么 DBA_AUDIT_TRAIL 里永远看不到 CONN / AS SYSDBA 后的语句
因为 Oracle 对特权用户的审计路径是硬编码隔离的：AUDIT_SYS_OPERATIONS 是独立开关，控制「是否审计 SYS/SYSDBA/SYSOPER」；而 AUDIT_TRAIL 只管「普通用户审计记录往哪存」。默认 AUDIT_SYS_OPERATIONS=FALSE，此时只记极少量事件（如实例启停），且仅在部分平台有痕迹，SQL 级操作完全不捕获。
常见错误现象：
- 执行了
SELECT SYSDATE FROM DUAL后查SYS.AUD$或DBA_AUDIT_TRAIL，结果为空 -
AUDIT_TRAIL='DB,EXTENDED'已生效，但CONN / AS SYSDBA的登录和后续语句仍无记录
启用 SYSDBA 审计必须做的三件事
缺一不可，顺序也不能错：
- 用
sysdba登录后执行：ALTER SYSTEM SET audit_sys_operations = TRUE SCOPE = SPFILE; - 必须重启数据库：
SHUTDOWN IMMEDIATE→STARTUP（仅ALTER SYSTEM不生效） - 验证是否真正开启：
SHOW PARAMETER audit_sys_operations输出值必须为TRUE
注意：启用后日志不会进数据库表，而是强制写入操作系统文件，路径由 audit_file_dest 决定。
怎么确认审计真的在记录
别查数据库视图，直接看 OS 文件：
- 先查路径：
SHOW PARAMETER audit_file_dest（例如返回/u01/app/oracle/admin/orcl/adump） - 进该目录：
cd /u01/app/oracle/admin/orcl/adump - 找最新 .aud 文件：
ls -t ora_*.aud | head -n 1（每个会话一个文件，文件名含 PID） - 用
tail -n 20 ora_12345.aud查内容，应看到类似字段：ACTION :'SELECT SYSDATE FROM DUAL'DATABASE USER:'/'PRIVILEGE : SYSDBASTATUS: 0
如果文件为空或根本没生成，大概率是 audit_file_dest 目录权限不对（需 oracle 用户属主 + drwxr-x---），或 SELinux 未放行。
容易被忽略的关键细节
很多人以为设完参数就万事大吉，其实最常卡在路径和权限上：
-
audit_file_dest目录必须由oracle用户拥有，且组不能有写权限（Oracle 主动拒绝写入drwxrwx---这类目录） - Linux 下若启用 SELinux，需确认 context 正确，比如：
chcon -t oracle_home_t /u01/app/oracle/admin/orcl/adump - 日志文件按会话生成，不是所有记录堆在一个文件里；一个连接断开后，对应
ora_*.aud就不再追加 - 这些文件不走数据库归档或备份流程，得靠外部脚本定期轮转或清理，否则磁盘迟早爆掉
