before logon触发器仅能拦截登录环节，可基于ip、时间、用户角色拒绝连接，但无法干预会话建立后的ddl/dml操作，也不能捕获本地直连或查v$session等动态视图。
before logon触发器能拦什么、不能拦什么
before logon是唯一能真正中断操作的系统事件，但仅限登录环节。它可基于ip、时间、用户角色拒绝连接，比如阻止sys从非运维网段登录；但它对已建立会话后的drop user、alter system kill session等操作完全无效。
常见误判是以为装了触发器就能“拦截所有高危SQL”——实际上，触发器本身无法在DDL或DML执行时介入，更不能捕获sqlplus / as sysdba这类本地直连（此时ORA_CLIENT_IP_ADDRESS为NULL，需配合ORA_SYS_CONTEXT('USERENV', 'HOST')补判）。
- 能做的：在认证后、会话初始化前抛出
RAISE_APPLICATION_ERROR(-20001, ...) - 不能做的：查
v$session或v$sql（会引发ORA-04092死锁） - 注意点：触发器内禁止调用自治事务以外的复杂逻辑，否则可能拖慢整个登录流程
DBA_PRIV_AUDIT_OPTS不是日志表，别在这儿找操作记录
DBA_PRIV_AUDIT_OPTS只存审计开关状态，比如ALTER SYSTEM是否被设为BY ACCESS，不记录谁、何时、在哪条语句执行了它。翻这个视图却看不到实际行为，是典型定位错误。
真要回溯高危操作，必须查DBA_AUDIT_TRAIL（传统审计）或UNIFIED_AUDIT_TRAIL（统一审计，默认启用）。尤其要注意：
- 确保
AUDIT_TRAIL = DB,EXTENDED，否则SQL_TEXT字段为空 - 过滤时加时间范围：
WHERE ACTION_NAME = 'ALTER SYSTEM' AND TIMESTAMP > SYSDATE - 1/24 - 关注
RETURNCODE：非0值（如942）代表失败但仍被审计，往往是试探性越权行为
语句级审计（AUDIT ALTER SYSTEM）有盲区
显式执行ALTER SYSTEM会被记录，但通过PL/SQL包、DBMS_SCHEDULER JOB、甚至JDBC驱动自动发起的隐式调用，大概率绕过语句审计。JOB日志里显示的是job owner，不是实际调度者，责任主体容易误判。
更麻烦的是，如果启用了OS_ROLES=TRUE或外部身份验证，权限来源可能根本不在数据库内部审计范围内。
解决方案不是堆审计策略，而是分层控制：
- 优先用
Database Vault定义命令规则，直接禁止DROP、TRUNCATE等动作在敏感Schema上执行 - 对关键对象建
REALM（域），隔离HR、FINANCE等模块数据访问 - 用
Oracle Database Firewall做网络层拦截，白名单+SQL规范化，防注入也防绕行
中间件代理和连接池让源头追踪变难
当应用通过Tomcat或WebLogic连接数据库，OS_USERNAME和PROGRAM字段常显示为java或oracle@host，真实调用者信息丢失。这时候单靠v$session查不到源头。
必须结合上下文字段：
- 统一审计中看
CLIENT_PROGRAM_NAME和PROXY_SESSIONID（识别连接池代理身份） - 传统审计中依赖
SESSIONID和ENTRYID关联多次操作 - 若开启
AUDIT_TRAIL=DB,EXTENDED，SQL_TEXT字段才可用，否则全是占位符
最易被忽略的是：所有这些监控手段都依赖权限配置和归档策略——没开审计、没设保留周期、没配防火墙策略，再全的视图也只是空壳。
