ORA-28001报错根本原因是用户expiry_date已过期，需DBA执行ALTER USER IDENTIFIED BY重置密码清除过期状态；仅改PROFILE或解锁无效，因过期状态已持久化且不自动回滚。
密码过期后用户无法登录，必须由 dba 手动干预；改 password_life_time 只影响未来行为，不修复已过期状态。
怎么确认用户真过期了
别等报错再查——ORA-28001 出现时已经连不上了。直接查 DBA_USERS 视图最准：
-
account_status字段是关键：显示EXPIRED或EXPIRED(GRACE)就说明已过期；OPEN才是正常 -
expiry_date为 NULL 表示没启用过期策略；若为过去时间（比如2026-02-28），而今天是2026-05-14，那肯定过期了 - 别漏查
profile字段——策略不在用户身上，在 profile 上，用户只是引用它
执行这句就能一次看清：
SELECT username, account_status, expiry_date, profile FROM dba_users WHERE username = 'YOUR_USER';
为什么改了 PASSWORD_LIFE_TIME 还是登不进去
因为修改 profile 不会“倒推”历史状态。策略放宽了，但已发生的过期事实不会自动撤销。常见误解：
- 把
DEFAULT的PASSWORD_LIFE_TIME改成UNLIMITED，以为用户马上能登——错，过期用户仍卡在 ORA-28001 - 只查
dba_profiles看到limit = 90就以为生效了——得确认该用户实际绑定的 profile 是不是DEFAULT，有些用户绑的是APP_PROFILE，改DEFAULT完全无效 - 忘记宽限期（
PASSWORD_GRACE_TIME）设为 0 或未设，导致用户过期后连一次改密机会都没有
查 profile 绑定关系：
SELECT profile FROM dba_users WHERE username = 'YOUR_USER';<br>SELECT resource_name, limit FROM dba_profiles WHERE profile = 'YOUR_PROFILE' AND resource_name IN ('PASSWORD_LIFE_TIME', 'PASSWORD_GRACE_TIME');
已过期用户怎么救回来
必须用 DBA 账户登录后手动操作，三步缺一不可：
- 先解锁（如果状态是
EXPIRED & LOCKED）：ALTER USER your_user ACCOUNT UNLOCK; - 再重置密码——哪怕想保留原密码，也得显式执行：
ALTER USER your_user IDENTIFIED BY your_old_password; - 如果要兼容旧密码过渡（比如应用还没同步新凭据），可用
IDENTIFIED BY VALUES方式复用加密值，但需从sys.user$查spare4，操作更重，一般直接重设更稳
批量查过期用户：
SELECT username, account_status, expiry_date FROM dba_users WHERE account_status LIKE '%EXPIRED%';
改 PASSWORD_LIFE_TIME 的实操要点
命令本身简单，但权限、对象、语法三处最容易翻车：
- 必须用
SYSDBA或有ALTER PROFILE权限的用户执行，普通 DBA 角色可能不够 - 语法里
LIMIT关键字不能省：ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME 90;，漏掉LIMIT会报错 - 目标 profile 名必须写对：如果是自定义 profile（如
APP_USER_PROFILE），就不能只改DEFAULT；查清楚再动手 - 改完立刻验证：
SELECT limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name = 'PASSWORD_LIFE_TIME';—— 输出应为90或UNLIMITED，不是180或空
宽限期建议加上：ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME 90 PASSWORD_GRACE_TIME 7;，否则过期即锁死，运维响应压力大。
真正麻烦的从来不是改参数，而是过期用户的状态不会随参数变更自动回滚——那个 EXPIRED 状态得一个个手动清除，而且得赶在业务连不上之前做。
