ORA-28000报错需先查account_status，区分LOCKED、EXPIRED & LOCKED(TIMED)等状态；仅UNLOCK无效时须重置密码；解锁后速被重锁多因应用层用旧密码重试，应查审计日志并同步更新连接池配置。
ORA-28000报错时，先确认账户真实状态，别急着解锁
ora-28000表面是“账户被锁”，但背后可能是locked、locked(timed)、expired & locked(timed)等不同状态，直接alter user ... account unlock可能无效——比如密码已过期，解锁后仍无法登录。
- 用DBA账号执行：
SELECT username, account_status, lock_date, expiry_date FROM dba_users WHERE username = 'YOUR_USER'; -
account_status为EXPIRED(GRACE)或EXPIRED & LOCKED(TIMED)时，必须重置密码，仅UNLOCK不解决根本问题 - 若
lock_date为空但状态仍是LOCKED，说明是手动锁定（如DBA执行过ALTER USER ... ACCOUNT LOCK），此时解锁即可
用ALTER USER UNLOCK解锁的3种典型场景和写法差异
解锁命令本身很简单，但参数组合决定是否一劳永逸。常见错误是只解了锁，没处理触发锁定的根源（比如错密重试、密码过期）。
- 单纯解锁（适用于手动锁定或临时应急）：
ALTER USER scott ACCOUNT UNLOCK; - 解锁 + 重设密码（推荐用于
EXPIRED & LOCKED(TIMED)）：ALTER USER scott IDENTIFIED BY newpass ACCOUNT UNLOCK; - 解锁 + 永久禁用失败次数限制（慎用，仅限测试环境）：
ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED;
注意：IDENTIFIED BY会强制密码复杂度校验（取决于PASSWORD_VERIFY_FUNCTION），若报错ORA-28003，需先查dba_profiles中该函数配置。
为什么刚解锁，1分钟内又变LOCKED？查应用层重试行为
很多情况下，用户解锁后立刻再次被锁，不是数据库问题，而是应用还在用旧密码持续连接——比如连接池未刷新、定时任务硬编码密码、Spring Boot的application.yml没更新。
- 查失败登录源头：
SELECT username, returncode, os_username, userhost FROM dba_audit_session WHERE returncode = 1017 AND timestamp > SYSDATE - 1/24;（returncode=1017即ORA-01017：用户名/密码错误） - 检查监听日志：
$ORACLE_BASE/diag/rdbms/[db_name]/[instance]/trace/alert_[instance].log里搜LOGON DENIED，常带IP和客户端程序名 - 如果发现同一IP高频重试，优先排查应用配置或中间件连接池（如Druid、HikariCP）是否设置了
connection-test-query但密码未同步
预防再锁：改FAILED_LOGIN_ATTEMPTS不如管好密码生命周期
把FAILED_LOGIN_ATTEMPTS调成UNLIMITED看似一劳永逸，实则掩盖真实风险，且违反多数企业安全基线。更可持续的做法是控制密码有效期+主动轮换+监控异常。
- 查当前策略：
SELECT resource_name, limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name IN ('FAILED_LOGIN_ATTEMPTS', 'PASSWORD_LIFE_TIME'); - 合理调整（示例）：
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME 90; ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 6; - 关键动作：给应用负责人发通知，要求在密码到期前7天通过
ALTER USER ... IDENTIFIED BY主动更新，并验证连接池是否生效
真正卡住人的往往不是SQL语句写不对，而是没人去改那个部署在三台服务器上的jdbc.properties文件。
