遇到 ORA-28001 错误时先别慌张——这个提示通常意味着“密码已过期”。但棘手的是，用户已经无法连接数据库，没法用普通账号直接排查。此时必须借助 DBA 权限提前诊断。最直接的方法是查询 dba_users 视图：执行 select username, account_status, expiry_date, profile from dba_users where username = 'your_user';，然后重点关注以下三个关键点：
account_status显示为EXPIRED或EXPIRED(GRACE)→ 基本确认密码过期expiry_date是一个过去的时间（例如2026-02-28 00:00:00，而当前日期是 2026-06-24）→ 过期状态确凿无疑profile字段指向的是实际生效的密码策略配置文件，不要只盯着用户本身的属性看
修改了 PASSWORD_LIFE_TIME 但仍旧无法登录，原因何在？
这是一个极易踩坑的环节。许多人以为将 PASSWORD_LIFE_TIME 改为 UNLIMITED 后，用户就能自动恢复登录。但 Oracle 的规则是：该参数仅影响未来新建的密码，无法回滚已经发生的过期状态。
常见的翻车场景包括：
- 修改了
DEFAULTprofile 的PASSWORD_LIFE_TIME，但目标用户实际绑定的是APP_PROFILE→ 白费功夫 - 查询
dba_profiles看到 limit = 90 就以为生效了，根本没有确认该用户实际关联的是哪个 profile - 忽略了检查
PASSWORD_GRACE_TIME是否设置为 0 — 如果 grace 期不为 0，过期后用户还有几天缓冲时间修改密码；但若设为 0，连改密的机会都没有
验证绑定关系的正确做法：先执行 SELECT profile FROM dba_users WHERE username = 'YOUR_USER'; 确认用户关联的 profile 名称；再查询对应 profile 下的具体限制：SELECT resource_name, limit FROM dba_profiles WHERE profile = 'YOUR_PROFILE' AND resource_name IN ('PASSWORD_LIFE_TIME', 'PASSWORD_GRADE_TIME');。这一步必不可少，否则改错地方全都徒劳。
DBA 必须执行哪些 SQL 才能让过期用户重新连接？
千万别以为仅靠 ALTER USER ... ACCOUNT UNLOCK 或修改 profile 就能解决问题——这样做完全无效。你必须显式地重置过期状态。
- 最常用的方案：
ALTER USER your_user IDENTIFIED BY new_password;→ 设置新密码后，过期状态自动清除，用户即可登录 - 如果想保留原密码但绕过当前阻塞：
ALTER USER your_user PASSWORD EXPIRE;→ 这将强制用户在下次登录时修改密码，相当于临时允许通行 - 如果
account_status显示EXPIRED(GRACE)且账号已被锁定：需要加上ACCOUNT UNLOCK，例如ALTER USER your_user IDENTIFIED BY new_password ACCOUNT UNLOCK;
有必要提醒一点：如果尝试用 IDENTIFIED BY old_password 复用旧密码，很可能遭遇 ORA-28007——因为启用了密码历史，旧密码已被记录，无法重复使用。
密码修改后，为什么应用程序仍然无法连接？
这个问题最容易被忽视。Oracle 只负责认证是否通过，不会主动通知下游系统“密码已经更新”。你必须手动更新所有依赖该密码的位置：
- 应用配置中心中的数据库连接字符串
- Kubernetes Secret 或 Docker
env变量 - ETL 工具、连接池（如 HikariCP）的
password属性 - 定时任务脚本里硬编码的密码
尤其需要留意管理控制台类的系统（例如数据中心注册页面），它们往往会缓存连接参数。修改密码后，需要先反注册再重新注册，否则系统仍会用旧凭据尝试连接。换句话说，密码确实改了，但应用的“记忆”还在——这才是连接失败的真正原因。
