PASSWORD_LIFE_TIME设为正整数（如90）才生效，需显式绑定Profile给用户且在新连接时校验；设0表示立即过期，UNLIMITED才真正不限制。

Oracle Profile 中 PASSWORD_LIFE_TIME 设多少才算生效

设了 password_life_time 却发现用户没被强制改密，大概率是 profile 没真正绑定到用户，或者被其他机制覆盖。这个参数只对启用该 profile 的用户起作用，且不自动触发“立即过期”，而是从密码上次修改时间开始倒计时。

• 必须显式把 Profile 赋给用户：ALTER USER username PROFILE profile_name;
• 新建用户默认用 DEFAULT Profile，改它会影响所有没显式指定 Profile 的用户——但生产环境慎动
• 如果用户密码是用 ALTER USER ... IDENTIFIED BY 重置的，倒计时会重置为 0，不是延续旧周期
• PASSWORD_LIFE_TIME 值为 UNLIMITED 或 0 效果不同：0 表示“密码创建后立刻过期”，UNLIMITED 才是真不限制

为什么设成 90 天，用户第 91 天登录却没提示改密

Oracle 不在登录瞬间校验过期，而是在执行需要验证密码的操作时才检查（比如首次连接后执行 DML、或调用某些 PL/SQL 包）。更关键的是：只要用户保持连接活跃（比如长连接没断开），就不会触发强制改密流程。

• 典型现象：ORA-28001: the password has expired 不一定出现在登录时，而可能在第一次执行 SELECT 或 INSERT 时才报
• 如果应用用了连接池且长期复用连接，用户可能根本收不到过期提醒，直到连接被回收重建
• DBA 可查 DBA_USERS.EXPIRY_DATE 看当前计算出的过期时间，比依赖日志更可靠

和 PASSWORD_GRACE_TIME 配合使用的实际效果

PASSWORD_GRACE_TIME 不是“宽限期天数”，而是指过期后允许用户以只读方式登录并改密的窗口期；超过这个时间，连登录都会被拒绝（ORA-28002 → ORA-28001）。

• 若设 PASSWORD_LIFE_TIME = 90，PASSWORD_GRACE_TIME = 7，用户第 91 天首次操作会进 grace 状态，还能改密；第 98 天起直接拒绝登录
• grace 期内用户执行任何写操作都会报 ORA-28002: the password will expire within 7 days（注意错误码是 28002，不是 28001）
• 这两个参数必须在同一个 Profile 里设置，分开改不同 Profile 不叠加

ALTER PROFILE 后老用户为啥还不受控

Profile 修改后不会实时刷新已存在的用户会话，也不会自动重算已有用户的 EXPIRY_DATE。Oracle 是在用户下次认证（比如新连接）时，才按当前 Profile 规则重新计算过期时间。

• 已登录用户不受影响，哪怕 Profile 已改，他们的 EXPIRY_DATE 仍按旧规则锁定
• 想让变更快速生效，得让目标用户断开重连，或 DBA 主动执行 ALTER USER username PASSWORD EXPIRE; 强制其下一次登录必须改密
• 查询 DBA_PROFILES 确认参数值已更新，避免编辑 Profile 后忘了 COMMIT（虽然 Profile DDL 不需要 commit，但容易误以为要）

密码过期逻辑藏在认证链深处，靠看文档参数说明远不如查 DBA_USERS.EXPIRY_DATE 和实测登录行为来得准。尤其要注意连接复用场景下，“过期”可能长期静默。