ORA-28000 错误应优先查 DBA_AUDIT_TRAIL 或 UNIFIED_AUDIT_TRAIL 中 RETURNCODE=28000 的记录，若审计未启用则查 DBA_FAILED_LOGIN_ATTEMPTS，并核对 PROFILE 中 FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 设置。
ORA-28000 错误出现时，先查 DBA_AUDIT_TRAIL 里失败登录记录
账户被锁，最直接的线索就在审计日志里。默认开启的数据库审计（尤其是 audit create session whenever not successful）会把所有失败登录写进 dba_audit_trail。别急着翻 windows 事件日志或应用日志——oracle 自己记的更准。
常见错误现象：SELECT * FROM DBA_AUDIT_TRAIL WHERE RETURNCODE = 1017 查不到记录？那说明审计根本没开，或者只开了标准审计（STANDARD），而没开细粒度或统一审计（UNIFIED AUDITING）。
- 确认审计是否启用：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'audit_trail'，返回DB或XML才有效 - 如果值是
NONE或OS，DBA_AUDIT_TRAIL就是空的，得换路径查 - 注意
RETURNCODE = 1017对应 ORA-01017（用户名 / 密码错误），1005是空密码，28000是账户已锁定——后者是结果，不是原因
用 DBA_FAILED_LOGIN_ATTEMPTS 看账户级累计失败次数
Oracle 12c 及以后版本引入了这个视图，它不依赖审计开关，而是从内存和控制文件中实时聚合失败登录尝试，对排查“为什么刚输错一次就锁了”特别有用。
使用场景：用户说“我就试了一次密码，账号就锁了”，但 FAILED_LOGIN_ATTEMPTS 参数设的是 10。这时候很可能是其他进程在后台静默重试。
SELECT USERNAME, FAILED_LOGIN_ATTEMPTS, FIRST_FAILURE_TIME, LAST_FAILURE_TIME FROM DBA_FAILED_LOGIN_ATTEMPTS WHERE FAILED_LOGIN_ATTEMPTS > 0- 该视图不会显示具体 IP 或客户端，但能快速定位是哪个账户正在被高频试探
- 如果
FAILED_LOGIN_ATTEMPTS值远高于预期，大概率是应用连接池配置了错误密码、或定时任务脚本硬编码了过期凭据
检查 PROFILE 中的 FAILED_LOGIN_ATTEMPTS 和锁定持续时间
账户被锁，不一定是输错密码导致的；更可能是 PROFILE 里配了 FAILED_LOGIN_ATTEMPTS 且设为非无限值，而 DBA 忘了它还生效着。
参数差异：Oracle 默认 PROFILE（DEFAULT）在 11g 是 UNLIMITED，但在 12c+ 安装时可能被脚本改成 10。新创建的 PROFILE 若没显式指定，会继承这个行为。
- 查当前生效值：
SELECT LIMIT FROM DBA_PROFILES WHERE PROFILE = (SELECT PROFILE FROM DBA_USERS WHERE USERNAME = 'XXX') AND RESOURCE_NAME = 'FAILED_LOGIN_ATTEMPTS' - 锁定后自动解锁时间由
PASSWORD_LOCK_TIME控制，单位是天；值为UNLIMITED就永远锁着，必须手动ALTER USER …… ACCOUNT UNLOCK - 注意：即使改了 PROFILE，已有用户的限制不会自动更新，得
ALTER USER …… PROFILE new_profile才生效
统一审计（UNIFIED AUDITING）开启后，DBA_AUDIT_TRAIL 不再更新
这是最容易踩的坑：你照着老文档查 DBA_AUDIT_TRAIL，结果空空如也，其实是因为数据库启用了统一审计，所有记录都进了 UNIFIED_AUDIT_TRAIL。
性能影响：统一审计默认写入 SYSAUX 表空间，高并发登录失败时可能撑大表空间，且查询比传统审计慢一点——但数据更全，含 client_program_name、client_hostname 等字段。
- 确认是否启用：
SELECT PARAMETER_VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing'，返回TRUE就得切视图 - 查失败登录：
SELECT DBUSERNAME, CLIENT_PROGRAM_NAME, CLIENT_HOST_NAME, SQL_TEXT FROM UNIFIED_AUDIT_TRAIL WHERE ACTION_NAME = 'LOGON' AND RETURN_CODE = 1017 ORDER BY EVENT_TIMESTAMP DESC - 别漏掉
UNIFIED_AUDIT_TRAIL的分区裁剪问题：默认按天分区，查太久以前的日志要加EVENT_TIMESTAMP条件，否则全扫
真正麻烦的不是查不到日志，而是日志里显示同一 IP 在 200ms 内发了 17 次登录请求——这种节奏基本可以确定是某个服务端 SDK 的重试逻辑失控，而不是人为输错密码。盯住客户端标识比盯住用户名更重要。
