宽限期（password_grace_time）必须配合password_life_time才能生效，单独设置无效；若password_life_time为unlimited，则密码永不过期，宽限期不触发；合理组合为90天有效期加7天宽限期。
宽限期（password_grace_time）本身不防锁定，它只缓解密码过期后的登录阻断；真正减少“频繁被锁”投诉的，是把 password_life_time 和 password_grace_time 配合用对，而不是单设宽限期。
为什么只设 PASSWORD_GRACE_TIME 没用？
PASSWORD_GRACE_TIME 必须依赖 PASSWORD_LIFE_TIME 才会触发——如果密码永不过期（UNLIMITED），宽限期压根不会启动。很多 DBA 看到用户抱怨“一过期就登不上”，就只加 PASSWORD_GRACE_TIME，结果改完发现照样报 ORA-28001，因为根本没到宽限期阶段。
-
PASSWORD_LIFE_TIME为UNLIMITED→ 密码永不过期 →PASSWORD_GRACE_TIME不生效 -
PASSWORD_LIFE_TIME设为 90 → 密码第 91 天开始进入宽限期 → 此时PASSWORD_GRACE_TIME才起作用 - 宽限期内登录，会收到
ORA-28002: Your password will expire in X days提示，但允许继续操作
PASSWORD_GRACE_TIME 值设多少才合理？
设太短（比如 1 天），用户来不及响应提醒；设太长（比如 30 天），等于变相延长弱密码暴露窗口。生产环境常见组合是：PASSWORD_LIFE_TIME 90 + PASSWORD_GRACE_TIME 7，即：90 天后进入 7 天宽限期。
- 宽限期单位是“天”，不能写成小时或分钟（不像
PASSWORD_LOCK_TIME） - 设为
0表示禁用宽限期：密码一过期立即锁死，不给任何缓冲 - 设为
UNLIMITED虽语法合法，但失去“推动用户改密”的意义，不推荐 - 应用连接池若长期复用连接，可能在宽限期最后一天突然失效，建议搭配应用层健康检查
修改后用户仍报 ORA-28001 怎么办？
改完 profile 不等于自动重置用户状态。已过期的账户必须显式改密，哪怕新密码和旧的一样：
- 先查状态：
SELECT username, account_status, expiry_date FROM dba_users WHERE username = 'APP_USER'; - 如果
account_status是EXPIRED(GRACE)或EXPIRED，说明宽限期已过或未启用 - 执行
ALTER USER app_user IDENTIFIED BY app_user;（可设回原密码） - 注意：该语句会重置
expiry_date，下次过期时间从执行时刻起重新计算
别忘了监听器和应用层才是投诉主因
用户反复被锁，80% 情况不是 profile 配置问题，而是应用配置错误：连接字符串里密码写错、连接池未刷新凭证、监控脚本硬编码旧密码。DBA 改完 PASSWORD_GRACE_TIME 后，一定要同步确认：
- 所有中间件连接池（如 Tomcat、WebLogic）是否已更新密码并重启连接
- Zabbix/Nagios 等监控账号是否单独配了 profile，避免被 DEFAULT 的
FAILED_LOGIN_ATTEMPTS连坐锁定 - 监听器是否开启
SECURE_REGISTER_LISTENER=OFF—— 若未关，公网扫描会绕过 profile 直接打爆监听器日志，导致账号误锁
宽限期只是补丁，不是解药。真要少投诉，得从应用凭证生命周期管理下手，profile 只是最后一道兜底。
