ORA-01017表示TCP连接成功但服务端认证失败，需排查SEC_CASE_SENSITIVE_LOGON是否为TRUE、密码大小写/BOM/空格、连接字符串引号与转义、账户状态（OPEN）、CREATE SESSION权限、PDB服务名及SQLNET.ALLOWED_LOGON_VERSION_SERVER兼容性。
ora-01017 不是连接失败，而是 oracle 服务端明确拒绝了认证——tcp 已通，问题一定出在用户名、密码、账户状态或协议兼容性上。直接改防火墙或重装客户端没用。
确认 SEC_CASE_SENSITIVE_LOGON 是否为 TRUE
Oracle 11g 起默认开启密码大小写敏感，SEC_CASE_SENSITIVE_LOGON = TRUE 意味着：
- 用户名不加双引号时自动转大写（
User Id=abc实际查的是ABC） - 密码必须字节级完全一致：大小写、空格、BOM、末尾换行符全算
- Windows 记事本复制的密码常带 UTF-8 BOM，
sqlplus看不出，但Oracle.ManagedDataAccess会严格传入并比对失败
验证命令：SHOW PARAMETER sec_case_sensitive_logon;。若返回 TRUE，临时关闭排查：ALTER SYSTEM SET sec_case_sensitive_logon = FALSE SCOPE=BOTH;，再重设一次密码（哪怕内容不变）：ALTER USER scott IDENTIFIED BY "TiGeR@123";。
检查 .NET 连接字符串中的引号与转义
Oracle.ManagedDataAccess 对引号极其敏感，错一处就导致凭据被截断或标准化：
- 用户名含小写字母或下划线？必须加英文双引号：
User Id="my_user"，否则当作MY_USER - 密码含
@、/、:、$等字符？必须包裹：Password="Pass@123" - C# 普通字符串里反斜杠要双写：
Password="pass\word"；更稳妥用逐字字符串：@'User Id=scott; Password="TiGeR@123"; Data Source=orcl;' - 从
appsettings.json或环境变量读取？务必调用.Trim()，尤其 Windows 配置文件易带 BOM 或尾部空格
排查账户状态与权限缺失伪装成 ORA-01017
Oracle 在认证流程中统一返回 ORA-01017，即使真实原因是账户锁死、过期或缺少 CREATE SESSION 权限：
- 用
sqlplus / as sysdba登录后查：SELECT username, account_status, expiry_date FROM dba_users WHERE username = 'SCOTT'; - 解锁：
ALTER USER scott ACCOUNT UNLOCK;；重设密码同时解锁：ALTER USER scott IDENTIFIED BY "newpass" ACCOUNT UNLOCK; - 确认权限：
SELECT * FROM dba_sys_privs WHERE grantee = 'SCOTT' AND privilege = 'CREATE SESSION';，缺失则补：GRANT CREATE SESSION TO scott; - 注意：Oracle 12c+ 引入 PDB，确保
tnsnames.ora中连接串指向正确的 PDB（如orclpdb），而非 CDB root
验证客户端与服务器版本兼容性
Oracle 12.2+ 默认要求客户端使用较新认证协议，旧版客户端（如 12.1c）直连可能触发 ORA-01017：
- 在数据库服务器端修改
$ORACLE_HOME/network/admin/sqlnet.ora，添加：SQLNET.ALLOWED_LOGON_VERSION_SERVER=11（或8兼容老客户端） - 重启监听：
lsnrctl stop && lsnrctl start - 修改后仍需重设用户密码：
ALTER USER myuser IDENTIFIED BY "mypass";，否则哈希不匹配 - 若用 Oracle Instant Client，确保版本不低于服务端主版本（如服务端 19c，客户端至少 19.x）
最常被忽略的是：错误堆栈里 ex.Number == 1017 才是可靠判断依据，不能只靠 ex.Message.Contains("ORA-01017") —— 因为某些网络层异常也会混入相似文本。
