ora-01017认证失败首要排查密码大小写敏感问题：oracle 11g起默认启用sec_case_sensitive_logon=true，且双引号创建的用户密码永久区分大小写；需检查profile绑定的password_verify_function、避免重设密码时使用双引号，并清理共享池及客户端大小写转换干扰。
ORA-01017 登录失败，先确认是不是大小写敏感惹的祸
看到 ORA-01017: invalid username/password; logon denied，别急着重装客户端或怀疑网络——这个错误说明连接已通，问题出在认证环节。Oracle 11g 默认开启密码大小写敏感（sec_case_sensitive_logon=TRUE），意味着：Password=Abc123! 和 password=abc123! 是两个完全不同的凭据。用 SQL*Plus 直连验证最可靠：sqlplus "scott/Abc123!@orcl"，注意英文双引号包裹含特殊字符的密码。
别白改 sec_case_sensitive_logon 参数
在 11gR2 及以后版本，sec_case_sensitive_logon 已基本失效。即使你执行 ALTER SYSTEM SET sec_case_sensitive_logon = FALSE，也可能立刻报 ORA-02095（该参数不可在线修改），或者改完重启后仍登录失败——因为真正起作用的是 profile 绑定的密码验证函数，不是这个参数。
-
SELECT name, value FROM v$parameter WHERE name = 'sec_case_sensitive_logon'返回FALSE？不等于问题解决 - 查用户 profile：
SELECT profile FROM dba_users WHERE username = 'SCOTT' - 清空验证函数才关键：
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL
重设密码必须避开双引号陷阱
一旦用户是用双引号创建的（如 CREATE USER scott IDENTIFIED BY "Tiger"），该用户的密码就永久锁定为大小写敏感，后续任何 profile 修改或参数调整都无效。重设时务必不用双引号，且推荐全小写：
- ✅ 正确：
ALTER USER scott IDENTIFIED BY tiger - ❌ 错误：
ALTER USER scott IDENTIFIED BY "Tiger"→ 登录时必须严格输入"Tiger"，且无法回退 - 检查是否已中招：
SELECT username, password_versions FROM dba_users WHERE username = 'SCOTT'；若含11G且你没主动改过，大概率是双引号创建的
别漏掉共享池刷新和客户端干扰
改完 profile、重设密码后，PL/SQL 认证缓存可能还拿着旧哈希，导致首次登录仍失败。执行 ALTER SYSTEM FLUSH SHARED_POOL 清理它。另外，客户端本身可能偷偷改了密码大小写：
- .NET 连接字符串里如果含
uppercasePassword=true（某些老 ojdbc 驱动默认开启），客户端会把密码转大写再发，服务端收不到原样 - JDBC URL 或应用代码里做了
password.toLowerCase()，等于白设数据库端所有配置 - 从配置文件读取密码时，务必
.Trim()—— Windows 的 UTF-8 BOM 或末尾空格会让实际传入的密码多一个不可见字符
真正卡住人的从来不是单点配置，而是 profile、密码创建方式、客户端行为三者叠加。双引号建的用户、绑着 ora12c_strong_verify_function 的 profile、以及驱动层的大小写转换，任何一个没清理干净，ORA-01017 就照常报。
