Oracle用户密码修改后连接池报错主因是应用未同步新凭据，而非数据库端问题；典型表现包括部分服务失败、重启后恢复又复现、日志密集出现同一用户登录失败；根本原因多为配置分散导致漏改，如Spring Boot配置未更新、WebLogic需手动刷新数据源、Vault未触发推送等。
连接池报错不是密码改了，是应用没同步新凭据
Oracle用户密码修改后，连接池大面积报错（如 ORA-01017、Got minus one from a read call、或连接超时）几乎从不源于数据库端本身，而是应用层连接池仍持旧密码重试——尤其在多实例、微服务或中间件场景下，配置分散导致漏改。
典型现象包括：部分服务能连、部分持续失败；重启单个应用后恢复，但过几小时又报错；日志里反复出现同一用户登录失败记录，且时间戳密集。
- Java 应用常见于
DataSource配置未更新（如 Spring Boot 的application.yml中spring.datasource.password仍为旧值） - WebLogic / WebSphere 等容器中，JDBC 数据源配置独立于代码，需在控制台手动刷新或重启数据源
- EPM、OBIEE、OBI 等 Oracle 套件会把密码存于注册表（Shared Services Registry）或加密配置文件中，必须走专用工具（如
configtool.sh）更新，直接改 DB 不生效 - 若使用 Vault 或配置中心（如 Nacos、Apollo），密码变更需触发配置推送，否则客户端长期缓存旧密文
ORA-01017 报错背后大概率是账户状态异常，不是密码错
改完密码立刻连不上，第一反应不该是“密码输错了”，而应查账户真实状态：LOCKED、EXPIRED(GRACE)、EXPIRED & LOCKED 这三种状态都会统一返回 ORA-01017，掩盖根本原因。
- 用
sqlplus / as sysdba登录后执行：SELECT username, account_status FROM dba_users WHERE username = 'YOUR_USER'; - 看到
LOCKED就执行：ALTER USER your_user ACCOUNT UNLOCK; - 看到
EXPIRED且 profile 启用了口令重用限制，仅IDENTIFIED BY newpass可能不够，需先解除限制：ALTER PROFILE default LIMIT PASSWORD_REUSE_TIME UNLIMITED;，再重设密码 - 注意：账户被锁常因后台任务（ETL 脚本、DBLink、定时 job）仍在用旧密码重试，解锁后若不更新这些地方，几分钟内会再次锁死
含特殊字符的密码必须加双引号，否则连接池解析直接失败
如果新密码含 @、$、#、/ 等字符，且创建时没用双引号包裹，SQL*Plus 和多数 JDBC 驱动会将密码截断或误解析，引发 ORA-00922（建库/改密阶段）或静默认证失败（连接阶段）。
- 正确改密写法：
ALTER USER scott IDENTIFIED BY "P@ssw0rd#2024"; - 连接字符串中也必须用英文双引号包住密码：
Password="P@ssw0rd#2024"; - .NET 环境下更要注意：C# 字符串若用普通字符串字面量，需转义反斜杠；推荐用逐字字符串：
@'User Id=scott; Password="P@ssw0rd#2024"; Data Source=orcl;' - Shell 脚本中执行 SQL 时，外层单引号 + 内层双引号易被 shell 吃掉，建议改用 here-document 或预编译变量传入
连接池未释放旧连接，导致新密码生效延迟
很多连接池（如 HikariCP、DBCP）默认启用连接验证和空闲连接保活。密码改了，但池中已有活跃连接仍用旧凭据维持着会话，新请求可能随机分配到这些“僵尸连接”，造成间歇性失败。
- HikariCP 需检查
connection-test-query是否有效（如SELECT 1 FROM DUAL），并确认validation-timeout设置合理（避免验证卡住） - DBCP2 推荐设置：
testOnBorrow=true+validationQuery=SELECT 1 FROM DUAL，确保每次借连接前校验 - 最彻底办法：滚动重启所有应用实例，强制清空连接池；若不可行，可临时调低
maxIdle/minIdle，加速旧连接自然淘汰 - Oracle 端可通过
V$SESSION查看当前连接的OSUSER和MACHINE，定位哪些 IP 还在用旧密码发起连接
真正棘手的从来不是改密码这一步，而是密码变更在分布式系统中的传播路径是否完整覆盖——配置中心、中间件控制台、加密存储、脚本硬编码、甚至监控探针里的健康检查 URL，都可能藏着一份被遗忘的旧凭据。
