Oracle账户真实锁定状态需查DBA_USERS中account_status字段，LOCKED、EXPIRED & LOCKED(TIMED)等非OPEN值均属锁定，须结合lock_date、expiry_date及密码策略综合判断并针对性解锁。
确认账户真实状态，别只看错误字面意思
ora-28000 报错不是“连不上”或“密码错”，而是 oracle 明确把 account_status 设成了 locked 或 expired & locked(timed)。直接改密码或重配 url 没用。
必须用 DBA 权限查真实状态：
SELECT username, account_status, lock_date, expiry_date FROM dba_users WHERE username = 'YOUR_USERNAME';-
account_status是LOCKED：大概率是 DBA 手动锁的，或 profile 里FAILED_LOGIN_ATTEMPTS被触发 -
account_status是EXPIRED & LOCKED(TIMED)：密码已过期 + 错密次数超限，只ACCOUNT UNLOCK不行，必须重设密码 -
lock_date非空 → 真锁了；expiry_date已过 → 密码失效，解锁后仍登不进
用 ALTER USER 解锁，但得看组合写法
解锁命令本身只有一条，但是否生效，取决于你有没有顺便处理掉“卡住登录”的另一个条件（比如密码过期）。
- 单纯手动锁定（如 DBA 执行过
ALTER USER ... ACCOUNT LOCK）：ALTER USER scott ACCOUNT UNLOCK; - 密码过期 + 被锁（最常见）：
ALTER USER scott IDENTIFIED BY newpass ACCOUNT UNLOCK;—— 必须带IDENTIFIED BY，否则解锁后立刻报 ORA-28001 - 用户名含大小写或特殊字符（建时用了双引号）：
ALTER USER "MyUser" ACCOUNT UNLOCK;，引号不能丢 - 执行后无需
COMMIT，DDL 立即生效；但 Navicat/PL/SQL Dev 图形界面里，“取消勾选锁定”后必须点Apply，点OK不提交
刚解锁就再锁？重点查应用层重试行为
数据库没毛病，问题几乎全出在外部：ETL 脚本、DBLINK、Spring Boot 的 application.yml、Druid/HikariCP 连接池配置里，还存着旧密码，一重启就高频刷错密。
- 查失败源头：
SELECT username, returncode, userhost, os_username FROM dba_audit_session WHERE returncode = 1017 AND timestamp > SYSDATE - 1/24;（returncode = 1017就是错密） - 搜监听日志：
grep -i "YOUR_USERNAME" $ORACLE_HOME/diag/tnslsnr/*/listener/trace/listener.log | tail -20，看 IP 和程序名 - 检查 DBLINK：
SELECT db_link, username FROM dba_db_links WHERE username = 'YOUR_USERNAME';，密码是否同步更新 - 临时放宽限制（仅排查用）：
ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 30;，但生产环境别设UNLIMITED
真正容易被忽略的点：密码策略和配置漂移
很多人修完数据库就以为完事了，结果两小时后又锁。根源不在 ALTER USER 写得对不对，而在于没人去核对所有下游连接点是否都更新了密码。DBLINK、Kettle 配置、Prometheus 监控脚本、甚至 Jenkins 的构建参数里，都可能硬编码着旧凭据。
另外，PASSWORD_LIFE_TIME 设为 UNLIMITED 并不推荐——它绕过了安全轮转机制，真要长期免维护，不如用 Oracle Wallet 或外部凭证管理器，而不是关掉策略。
