必须先查清用户实际绑定的PROFILE才能正确修改，否则ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED无效；需用SELECT确认用户profile及expiry_date状态，再针对性修改对应PROFILE并重置密码或刷新expiry_date。
查清用户实际绑定的 PROFILE 才能改对地方
很多人执行 ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED 后发现用户还是提示 ORA-28002 或登录失败，根本原因是用户没绑 DEFAULT profile。必须先确认目标用户真实使用的 profile 名称：
SELECT username, profile, account_status, expiry_date FROM dba_users WHERE username = 'SCOTT';- 如果返回的
profile是APP_PROFILE或HR_PROFILE，改DEFAULT就完全无效 -
expiry_date为NULL表示从未设过期；若早于SYSDATE，说明已过期（触发ORA-28001）；若距当前约 7 天，则是ORA-28002预警阶段
ALTER PROFILE LIMIT PASSWORD_LIFE_TIME UNLIMITED 立即生效但不重置已有 expiry_date
修改 profile 只影响后续密码设置行为，不会自动把已存在的 expiry_date 拉回未来。也就是说，即使你把 PASSWORD_LIFE_TIME 改成 UNLIMITED，只要用户当前 expiry_date 还在 7 天内或已过期，下次登录仍会报 ORA-28002 或 ORA-28001：
- 查策略：
SELECT resource_name, limit FROM dba_profiles WHERE profile = 'YOUR_PROFILE' AND resource_name = 'PASSWORD_LIFE_TIME'; - 改策略：
ALTER PROFILE YOUR_PROFILE LIMIT PASSWORD_LIFE_TIME UNLIMITED; - 但必须紧接着执行
ALTER USER username IDENTIFIED BY ...或IDENTIFIED BY VALUES才能刷新expiry_date
用 IDENTIFIED BY VALUES 保留原密码哈希（无需明文）
当应用连接串里硬编码的是密文、你不知道原密码明文、又不敢改配置时，IDENTIFIED BY VALUES 是唯一安全方案。它跳过所有复杂度校验，直接写入哈希值：
- Oracle 19c 查哈希：
SELECT name, SPARE4 FROM sys.user$ WHERE name = 'SCOTT';（注意带S:前缀） - Oracle 11g/12c 查哈希：
SELECT name, password FROM sys.user$ WHERE name = 'SCOTT'; - 还原命令：
ALTER USER scott IDENTIFIED BY VALUES 'S:3BF46B2AC692CD7CD80082CB6C7C4B1C323F8A0CE044F1B477ADE2BE807E'; - 如果只拿到旧哈希（如
F894844C34402B67），那是 11g 格式，在 19c 直接用会报ORA-01017
PROFILE 修改后仍需显式解锁和重置密码才能恢复登录
即使 PASSWORD_LIFE_TIME 已设为 UNLIMITED，若用户状态是 EXPIRED(GRACE) 或 LOCKED，光改 profile 不解决问题：
-
account_status为EXPIRED(GRACE)：必须先ALTER USER username ACCOUNT UNLOCK，再IDENTIFIED BY或IDENTIFIED BY VALUES -
account_status为LOCKED：仅ACCOUNT UNLOCK不够，仍需重置密码（否则下次认证仍失败） - 启用
PASSWORD_VERIFY_FUNCTION的 profile 下，IDENTIFIED BY会强制校验复杂度——哪怕你想设回原来那个“弱密码”，也会被拒
expiry_date，或者查错了 profile 名字就去执行 ALTER PROFILE。每个操作前花 30 秒查 dba_users 和 dba_profiles，比反复试错快得多。 
