查account_status和lock_date是确认ora-28000是否真锁定的第一步，需结合listener.log、dba_jobs、dba_db_links及sys.user$的lcount定位持续撞锁的后台程序。
查 account_status 和 lock_date 是第一步
光看报错 ORA-28000 不够，得确认当前状态是不是真锁了、什么时候锁的。用 sys 或 system 登录后执行：
SELECT username, account_status, lock_date FROM dba_users WHERE username = 'SCOTT';
注意几个关键值：LOCKED（手动锁）、EXPIRED & LOCKED（密码过期+锁）、LOCKED(TIMED)（失败登录触发的自动锁）。如果 lock_date 每次解锁后几分钟内又更新，说明有程序在持续撞锁。
定位是谁在反复连失败
不是人输错密码，而是后台程序没同步改密——这是最常见根本原因。分两路查：
- 查监听日志：
$ORACLE_HOME/network/log/listener.log，用tail -n 200 listener.log | grep -i "ORA-28000\|failed"快速翻最近失败连接，重点看PROGRAM和HOST字段，比如TrsAgent.exe、gwserver_x64、DBLINK名字都可能是元凶 - 查后台作业或 DBLINK：如果用户被用于 job、物化视图刷新、远程查询，执行
SELECT * FROM dba_jobs WHERE log_user = 'SCOTT';或SELECT owner, db_link FROM dba_db_links WHERE username = 'SCOTT';，这些地方密码没更新就会静默撞锁
看 FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LIFE_TIME 设置
默认 profile 的两个参数常一起作祟：
SELECT resource_name, limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name IN ('FAILED_LOGIN_ATTEMPTS', 'PASSWORD_LIFE_TIME');
常见组合陷阱：
-
FAILED_LOGIN_ATTEMPTS = 10+ 应用每分钟重试 3 次 → 4 分钟就锁 -
PASSWORD_LIFE_TIME = 180+ 解锁后不重置密码 → 第 181 天一到自动变EXPIRED & LOCKED - 改 profile 是全局生效，不是单个用户操作，别只盯着被锁账号本身
别忽略 user$ 表里的 lcount 计数器
dba_users 只显示最终状态，但真正触发锁定的是底层 sys.user$ 表里的失败计数。查它能确认是否“刚清零又涨”：
SELECT name, lcount, astatus FROM sys.user$ WHERE name = 'SCOTT';
lcount 是累计错误次数（未归零），astatus 是账户状态码（比如 4 表示锁定）。如果每次解锁后 lcount 迅速从 0 增到 10，基本坐实有程序在疯狂试连——这时候修 profile 或改密码只是掩耳盗铃，必须找到并修复那个程序。
