ORA-28000表示用户状态确为LOCKED或LOCKED(TIMED)，需用DBA权限执行ALTER USER ... ACCOUNT UNLOCK；确认方法是查dba_users中account_status及非空lock_date，expiry_date过期则需同步重置密码。
ORA-28000 不是连接失败或密码错误，而是 Oracle 明确将该用户状态设为 LOCKED 或 LOCKED(TIMED) —— 解锁必须用 DBA 权限执行 ALTER USER ... ACCOUNT UNLOCK，其他任何操作（改密码、重配连接串、重启应用）都无效。
怎么确认用户真被锁了（不是猜）
别凭报错就动手。先连 DBA 账号（如 sys 或 system），查 dba_users 看真实状态：
-
account_status是LOCKED（人工锁）或LOCKED(TIMED)（输错触发）才对应 ORA-28000 -
lock_date非空 = 已锁；为空 = 没锁 -
expiry_date若已过期，解锁后仍会报ORA-28001，得同步重置密码
执行这条 SQL 查清底细：
SELECT username, account_status, lock_date, expiry_date FROM dba_users WHERE username = 'YOUR_USER';
用 ALTER USER ... ACCOUNT UNLOCK 解锁的实操要点
语句极简，但踩坑点集中：
- 必须用有
ALTER ANY USER或DBA角色的账号执行；sqlplus / as sysdba最稳 - 用户名大小写敏感：若建库时用了双引号（如
"MyUser"），这里也得写ALTER USER "MyUser" ACCOUNT UNLOCK - 不需
COMMIT——DDL 立即生效，执行完就解锁了 - 如果同时要改密码，写成一条：
ALTER USER your_user IDENTIFIED BY new_pass ACCOUNT UNLOCK
Navicat / PL/SQL Developer 图形化操作的隐藏陷阱
点几下看似简单，但失效率高：
- 登录工具时，角色必须选
Sysdba或Sysoper；用Normal模式根本看不到Users列表 - 编辑用户后，“账户被锁住”勾选框取消 ≠ 生效 —— 必须点
Apply（不是OK或Close） - 某些 PL/SQL Developer 版本（如 14+）在改密码时，若 profile 启用了密码过期策略，还得额外勾选“强制修改密码”，否则下次登录仍卡在
ORA-28001
为什么刚解锁 5 分钟又锁了？重点查这些地方
真正麻烦的从来不是那条 ALTER USER 命令，而是背后持续刷错密码的源头：
-
DBLINK的密码没更新：CREATE DATABASE LINK ... CONNECT TO user IDENTIFIED BY "old_pass" - Java 应用、ETL 脚本、连接池配置里硬编码了旧密码，重启前没改
- 监控脚本或定时任务在后台静默重连，错误日志藏在
$ORACLE_HOME/diag/tnslsnr/*/listener/trace/listener.log里 - 临时放宽
FAILED_LOGIN_ATTEMPTS可辅助排查（ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 30），但生产环境绝不设UNLIMITED
账户状态不是非黑即白的“锁/不锁”，LOCKED(TIMED) 和 EXPIRED(LOCKED) 这类复合状态最容易被忽略，查 ACCOUNT_STATUS 字段比看报错更可靠。
