ORA-28000 错误本质是账户被锁而非密码错误，由连续失败登录触发（默认10次），锁定后无论密码对错均拒绝连接；需DBA查dba_users确认account_status，用ALTER USER ... ACCOUNT UNLOCK临时解锁，并调整FAILED_LOGIN_ATTEMPTS等profile参数治本。
ORA-28000 错误本质是账户被锁，不是密码错
遇到 ORA-28000: the account is locked 时，90% 的人第一反应是“输错了新密码”，但实际是 Oracle 已主动将该用户账户状态设为 LOCKED（或 LOCKED(TIMED)），此时无论密码是否正确，连接都会被拒绝。锁定由失败登录次数触发，和密码修改操作本身无直接因果关系——但改密码后立刻报这个错，往往说明改完没重连、或改的过程中已触发了锁定阈值。
检查账户状态必须用 DBA 权限查 dba_users
普通用户无法查看自身是否被锁；只有具备 SELECT_CATALOG_ROLE 或 DBA 角色的账号才能确认真实状态：
SELECT username, account_status, lock_date, expiry_date FROM dba_users WHERE username = 'YOUR_USER';
重点关注三列：
-
account_status值为LOCKED、EXPIRED & LOCKED或LOCKED(TIMED)都表示不可登录 -
lock_date非空说明已被人工或策略锁定过 -
expiry_date过期也会导致部分客户端行为异常，尤其搭配密码策略时
默认密码策略常被忽略：FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME
Oracle 默认 profile（通常是 DEFAULT）限制极严：
-
FAILED_LOGIN_ATTEMPTS默认值是10：连续 10 次输错密码即锁号 -
PASSWORD_LOCK_TIME默认值是1（单位：天）：锁 24 小时，期间任何密码都无效 - 改密码不重置失败计数器——如果改之前已试错 9 次，改完第一次输错就锁
- 即使改对了密码，若连接池/应用未及时刷新凭证，仍会持续用旧凭据重试，快速刷满阈值
临时解法（需 DBA 执行）：
ALTER USER your_user ACCOUNT UNLOCK;
长期建议调整 profile（谨慎）：
ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 30; ALTER PROFILE DEFAULT LIMIT PASSWORD_LOCK_TIME 1/24; -- 锁 1 小时
应用层重试逻辑是隐藏推手
很多 Java/.NET 应用在连接失败时自带指数退避重试，且不区分错误类型。一旦首次连接因网络抖动或短暂服务不可用返回失败，后续几次重试若恰好撞上密码变更窗口，就可能在几秒内完成“输错 → 锁定”全过程。
- Spring Boot 的
HikariCP默认connection-test-query失败会标记连接为坏，并尝试新建连接——若配置了多连接，可能并发触发多次失败登录 - Oracle 客户端如
sqlplus在脚本中未加错误判断，循环执行也会快速锁号 - 解决方向：在应用日志里搜
ORA-28000出现前几分钟的ORA-01017（用户名/密码无效）记录，定位源头
真正麻烦的不是锁本身，而是锁定机制与应用重试、连接池、密码轮换节奏三者叠加时，问题会表现为“刚改完密码就锁”，让人误以为改密码功能有 Bug。
