必须启用audit_sys_operations参数才能审计sysdba/sysoper操作，且日志强制写入audit_file_dest指定的os文件（如ora_12345.aud），与audit_trail设置无关；该参数默认为false，启用后需重启数据库生效。
必须启用 audit_sys_operations，且审计记录只会落在操作系统文件中，和 audit_trail 设置无关。
audit_sys_operations 是唯一控制 sysdba 操作审计的开关
Oracle 对 SYS、SYSTEM 或任何以 SYSDBA/SYSOPER 权限连接的用户，不走标准审计路径。无论你是否设置了 audit_trail=db 或 db_extended，这些用户的操作都不会写入 SYS.AUD$ 表。
真正起作用的只有 audit_sys_operations 参数：
- 默认值为
FALSE，即完全不记录 - 设为
TRUE后，所有SYSDBA级别操作（包括conn / as sysdba）都会被强制记录 - 该参数修改后需重启数据库才生效：
alter system set audit_sys_operations=true scope=spfile;
审计日志实际存放在 audit_file_dest 指定的 OS 目录下
即使你启用了 audit_trail=db，audit_sys_operations=true 产生的日志也不会进数据库表，而是固定写入操作系统文件。
路径由 audit_file_dest 参数决定，典型位置如：
/oracle/app/oracle/admin/<sid>/adump/</sid>
在该目录下，你会看到形如 ora_12345.aud 的纯文本文件，内容类似：
ACTION : 'CREATE USER test IDENTIFIED BY VALUES ''...''' DATABASE USER: '/' PRIVILEGE : SYSDBA CLIENT USER: oracle CLIENT TERMINAL: pts/0 STATUS: 0
注意：STATUS: 0 表示成功，STATUS: 1017 这类是常见登录失败码（ORA-01017）。
无法按用户名粒度过滤 sysdba 审计，但可借助 OS 工具筛选
Oracle 不支持类似 audit create table by scott 这种语法来限定某个 SYSDBA 用户——只要是以 SYSDBA 身份连接，全部操作都会被记录。
如果你只关心某位 DBA（比如 dba01）的操作，只能靠事后解析日志：
- 用
grep -i "CLIENT USER: dba01" /path/to/adump/*.aud - 结合
awk提取时间、动作、SQL 片段（注意：原始.aud文件里不包含完整SQLTEXT，只含ACTION字段如'ALTER SYSTEM ...'） - 若需完整 SQL，必须启用细粒度审计（FGA）或升级到统一审计（12c+），但 FGA 不适用于
SYSDBA会话
audit_trail=db_extended 对 sysdba 审计完全无效
这是最容易踩的坑：很多人以为设了 audit_trail=db_extended 就能拿到 SYSDBA 的 SQLTEXT 和 SQLBIND，其实不行。
db_extended 只增强普通用户（非 SYSDBA）的审计记录字段；而 audit_sys_operations 输出的日志格式是固定的、不可配置的纯文本，不支持扩展字段。
所以如果你真需要带绑定变量和完整语句的 SYSDBA 操作记录，唯一可行路径是：
- 使用 Oracle 12c 及以上版本
- 启用统一审计（
unified auditing） - 创建
unified audit policy并enable给sysdba相关权限 - 注意：统一审计启用后，传统
audit语句将失效，且无法回退到标准审计
老版本 Oracle（11g 及之前）对 SYSDBA 的审计能力就是有明确边界的：能记谁干了什么，但记不了他具体执行的那条带变量的 SQL 是什么样子。
