ORA-28001报错本质是expiry_date已过期，需DBA执行ALTER USER IDENTIFIED BY重置密码以清除过期状态并恢复OPEN，仅解锁或改profile无效，且必须同步所有下游配置。
ORA-28001报错本质是expiry_date已过期，不是连接参数或驱动问题
ORA-28001根本不是配置写错、JDBC驱动不兼容或者URL漏了什么参数——它只说明一件事：dba_users.expiry_date 字段的值已经早于当前时间。哪怕你刚把 PASSWORD_LIFE_TIME 改成 UNLIMITED，这个字段也不会自动更新，旧的过期状态依然生效。
验证方式极简单：用 DBA 账户执行
SELECT username, expiry_date, account_status FROM dba_users WHERE username = 'YOUR_USER';
如果返回的 expiry_date 是 2026-05-12 这类过去的时间点，而今天是 2026-07-27，那这就是唯一根源。
- 仅执行
ALTER USER ... ACCOUNT UNLOCK无效——account_status可能是EXPIRED(GRACE)或EXPIRED，解锁不等于重置过期状态 -
ALTER USER ... IDENTIFIED BY old_password会触发ORA-28007（如果启用了密码历史策略），Oracle 明确禁止复用旧密码绕过校验 - profile 修改只影响未来新建/未过期用户，对已过期账户完全无感
必须用DBA权限执行ALTER USER IDENTIFIED BY重置密码
普通用户连登录都失败时，只能靠 DBA 登录后直接操作。最稳妥、最通用的做法就是显式重置密码，这会同时清除 expiry_date 并将状态恢复为 OPEN。
操作命令：
ALTER USER your_user IDENTIFIED BY new_password;
注意几个关键点：
- 不需要先
UNLOCK——IDENTIFIED BY自动解除锁定状态 - 如果想保留原密码逻辑但跳过当前阻塞，可用
ALTER USER your_user PASSWORD EXPIRE;，这样下次登录强制改密，但本次连接仍失败，适合灰度过渡 - 服务账户（如应用连接池用的账号）建议设新密码后立即同步到所有配置项，否则重启应用仍连不上
修改PASSWORD_LIFE_TIME只对未过期用户生效
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED 确实能防止未来再发生同类问题，但它不会回溯修复已存在的过期记录。
查当前策略用：
SELECT resource_name, limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name = 'PASSWORD_LIFE_TIME';
生产环境慎用 UNLIMITED，更推荐：
- 服务账户：设为
90或180，配合巡检脚本提前预警 - 个人账户：保持默认策略，符合等保或内部安全规范
- 真正需要“永不过期”的场景，应单独建 profile 并 assign 给指定用户，避免污染 DEFAULT
密码改完后必须同步所有依赖配置
密码重置只是第一步，漏掉下游配置会导致“以为修好了，其实还连不上”。常见遗漏点包括：
- Kubernetes
Secret中的db.password字段 - HikariCP 或 Druid 连接池配置里的
password属性 - Spring Boot 的
application.yml或 Nacos 配置中心中数据库连接串 - 定时任务脚本（如备份
.sh或.bat）里硬编码的密码 - BI 工具（如 Tableau、FineReport）数据源设置
特别注意：sys 用户密码改完后，所有依赖 sys@xxx as sysdba 的运维脚本（如 RMAN 备份、AWR 报告生成）也得一并更新，否则凌晨任务静默失败。
真正容易被忽略的是——过期状态是用户级持久化字段，不是会话级临时标记；修一次密码，要扫一遍全链路配置，不然修了也白修。
