不行，ORA-28007报错时直接用ALTER USER IDENTIFIED BY "old_password"会失败；Oracle校验的是历史哈希记录是否在PASSWORD_REUSE_TIME和PASSWORD_REUSE_MAX约束范围内，而非明文比对。
ORA-28007报错时直接改回原密码行不行？
不行，alter user user identified by "old_password" 会触发校验，哪怕密码完全一致也会失败。oracle不是比对明文，而是检查历史哈希记录是否在 password_reuse_time 和 password_reuse_max 约束范围内。只要策略启用，就拦住。
绕过重用限制的三种实操路径
核心思路是避开明文校验逻辑，分场景选择：
- 知道原密码且只想“重置为相同值”：用
IDENTIFIED BY VALUES直接写入哈希值。先查SELECT spare4 FROM user$ WHERE name = 'USER_NAME'，拿到类似S:ABC...或T:DEF...的哈希串，再执行ALTER USER user IDENTIFIED BY VALUES 'S:ABC...' - 想彻底禁用重用限制：修改 profile，把两个关键参数设为
UNLIMITED：ALTER PROFILE default LIMIT password_reuse_time UNLIMITED和ALTER PROFILE default LIMIT password_reuse_max UNLIMITED。注意：二者必须同时设为UNLIMITED，只设一个反而会让密码永远无法重置 - 临时绕过（仅限DBA操作）：用
CREATE USER temp_user IDENTIFIED BY "desired_password"创建临时用户，查其spare4哈希，再用该哈希更新目标用户。此法不依赖 profile 修改，但需有SELECT ANY TABLE权限访问user$
profile修改后为什么还要执行一次ALTER USER？
很多人以为改完 profile 就万事大吉，结果 JDBC 连接仍报错。这是因为 Oracle 的密码有效期和重用策略是“惰性生效”的——只有在真正执行 ALTER USER ... IDENTIFIED BY 时才会刷新内部状态。即使新旧密码相同，也必须触发一次显式修改，否则连接层仍按旧策略校验。
容易被忽略的兼容性坑
哈希值格式必须匹配客户端版本。12c+ 默认用 T: 开头的新哈希，但老应用可能只认 S:。如果用 spare4 查到的是 T: 哈希，而客户端是 11g，IDENTIFIED BY VALUES 可能静默失败或登录报 ORA-01017。此时得确认 SQLNET.ALLOWED_LOGON_VERSION_SERVER 设置，并考虑降级哈希生成方式（如用 11g 实例导出再导入）。
