DBA_PRIV_AUDIT_OPTS只存权限审计配置，不记录操作日志；真正记录非法尝试的是DBA_AUDIT_TRAIL（传统审计）或UNIFIED_AUDIT_TRAIL（统一审计），需结合RETURNCODE筛选失败行为并验证审计参数是否启用。
直接查 dba_audit_trail 或 unified_audit_trail，别碰 dba_priv_audit_opts——它只存“开了哪些权限审计”，不记“谁在什么时候试了什么”。
为什么 DBA_PRIV_AUDIT_OPTS 查不到非法尝试记录
DBA_PRIV_AUDIT_OPTS 是个配置快照视图，只显示当前启用的权限级审计策略（比如 SELECT ANY TABLE BY ACCESS），字段里全是权限名和审计方式，没有时间、用户、IP、SQL、返回码。你翻它一百遍，也看不到一次失败的 GRANT DBA TO hacker。
真正记录行为的是审计日志表：
- 传统审计：查
DBA_AUDIT_TRAIL，前提是AUDIT_TRAIL = DB或DB,EXTENDED - 统一审计（12c+ 默认）：查
UNIFIED_AUDIT_TRAIL，需确认UNIFIED_AUDIT_TRAIL已启用且策略已启用
关键点：没开审计，这两个表就是空的；开了但没设 EXTENDED，SQL_TEXT 字段为空，你连试的是哪条语句都看不到。
怎么快速定位高频非法权限尝试
非法尝试往往伴随失败返回码，重点筛这些值：
-
RETURNCODE = 942：对象不存在（常用于试探表/视图是否存在） -
RETURNCODE = 1031：权限不足（最典型，比如用普通用户执行ALTER SYSTEM） -
RETURNCODE = 1017：用户名密码错误（虽不是权限本身，但常是爆破起点） -
RETURNCODE = 1034：数据库未启动（试探性连接）
实操建议：
对传统审计：SELECT USERNAME, OS_USERNAME, USERHOST, TIMESTAMP, ACTION_NAME, SQL_TEXT, RETURNCODE FROM DBA_AUDIT_TRAIL WHERE RETURNCODE IN (942, 1031, 1017) AND TIMESTAMP > SYSDATE - 1/24 ORDER BY TIMESTAMP DESC;
对统一审计：SELECT DBUSERNAME, CLIENT_PROGRAM_NAME, OBJECT_SCHEMA, OBJECT_NAME, SQL_TEXT, RETURN_CODE FROM UNIFIED_AUDIT_TRAIL WHERE RETURN_CODE IN (942, 1031, 1017) AND EVENT_TIMESTAMP > SYSTIMESTAMP - INTERVAL '1' HOUR;
注意加时间范围，否则全表扫可能卡住；CLIENT_PROGRAM_NAME 能帮你识别是 JDBC、sqlplus 还是某个定时任务在发起试探。
容易被忽略的隐蔽来源
很多非法尝试不是人肉敲的，而是来自：
- 应用连接池重试机制：配错密码后，每秒重连 5 次，
USERNAME看起来一样，但SESSIONID和ENTRYID不同，得聚合统计 - PL/SQL 包内嵌的动态 SQL：语句审计（
AUDIT ALTER SYSTEM）捕不到，但统一审计的EXECUTE动作能抓到调用栈 - 代理连接（如中间件或连接池）：真实操作者藏在
PROXY_SESSIONID或OS_USER后面，单看DBUSERNAME会误判 - JDBC 驱动自动发起的元数据查询：比如
DatabaseMetaData.getTables()可能触发SELECT ANY DICTIONARY尝试
如果发现某用户高频失败但没对应业务逻辑，优先查它的应用配置和连接池日志，而不是直接锁账号。
审计参数必须检查的三项
没开对，再好的查询也白搭：
-
AUDIT_TRAIL：必须是DB、DB,EXTENDED或XML，NONE或OS下DBA_AUDIT_TRAIL为空 -
AUDIT_SYS_OPERATIONS：设为TRUE才能捕获SYS用户的操作（包括ALTER SYSTEM） - 统一审计策略：确认
ENABLED状态为YES，命令是AUDIT POLICY ora_secureconfig;或自定义策略
查法：SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME IN ('audit_trail', 'audit_sys_operations');SELECT POLICY_NAME, ENABLED FROM AUDIT_UNIFIED_ENABLED_POLICIES;
最后提醒一句：DBA_PRIV_AUDIT_OPTS 的作用，仅限于确认“ALTER SYSTEM 这个权限是否已被打开审计开关”，它不是日志表，也不是告警源——把它当监控入口，是绝大多数人踩的第一个坑。
