动手之前，先得摸清情况。盲目修改可能白费功夫，因为用户可能并未使用默认的DEFAULT profile，而是绑定了某个自定义的profile（例如APP_PROFILE）。

• 确认用户关联的Profile：执行SELECT username, profile FROM dba_users WHERE username = 'YOUR_USER';。
• 查看密码有效期策略：运行SELECT limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name = 'PASSWORD_LIFE_TIME';。返回180即是Oracle的默认设置。
• 顺便检查宽限期：SELECT limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name = 'PASSWORD_GRACE_TIME';。如果结果是0，意味着密码一旦过期账户立即被锁；如果是UNLIMITED，则宽限期无限，但到期前7天的预警提示依然会照常出现。

第二步：选择解决方案——治标还是治本？

拥有DBA权限后，你可以选择两种路径，但通常两者需要结合使用。只改策略不处理已预警用户，提示不会消失；只改单个用户密码，无法防止新用户未来遇到同样问题。

• 快速治标（适用于紧急处理）：执行ALTER USER your_user IDENTIFIED BY your_password;。注意，新密码可以与原密码相同。执行后，该用户下次登录时就不会再看到ORA-28002了。
• 治本调整（推荐用于长期运维）：运行ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;。此修改立即生效，无需重启数据库。但务必记住，它只对尚未触发预警的新用户或未来密码周期生效。
• 如果出于安全合规要求必须定期更换密码，可以设定一个具体天数，例如：ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME 90;。
• 特别注意数据库链接（DBLINK）场景：如果报错信息涉及DBLINK，务必检查链接所使用的远程数据库用户密码是否也即将过期，需要对那个远程用户单独进行密码重置。

第三步：避开常见陷阱——策略改了，为什么警告还在？

这是最容易被忽略的关键一步，也是许多DBA踩坑的地方。你以为执行了ALTER PROFILE修改策略就一劳永逸了？结果用户登录时ORA-28002依然弹了出来。

原因在于，Oracle会将“用户是否已进入密码过期预警周期”这个状态记录在用户自身的元数据中。修改Profile策略并不会自动刷新这个状态标记。因此，对于每一个已经收到预警提示的用户，都必须额外执行一次密码重置操作。

• 必须补上的操作：对每个受影响的用户执行ALTER USER username IDENTIFIED BY current_password;。
• 目前没有一键批量操作的命令，需要逐个处理。可以通过查询脚本生成批量语句的思路，例如：SELECT 'ALTER USER ' || username || ' IDENTIFIED BY [新密码];' FROM dba_users WHERE account_status LIKE '%EXPIRED(GRACE)%' OR expiry_date - SYSDATE < 7;（请注意，自Oracle 11g起，DBA_USERS视图中已不再直接显示密码字段，因此实际执行时需人工确认或统一设置新密码）。
• 最后一道检查：如果用户采用的是外部认证（如操作系统或AD域认证），或者密码被硬编码在应用程序配置文件中，那么在数据库端重置密码后，必须同步更新相应的外部系统或应用配置文件，否则会导致连接失败。