积累了几次Oracle客户端连接故障，做下总结。

1、案例

案例1：客户端连接报错ORA-12514

项目场景
业务工程人员使用PLSQL工具，连接部署在Windows系统上的Oracle 11gR2单机数据库，报错ORA-12514。
分析排查
（1）错误代码含义
ORA-12514 是指监听程序无法识别连接描述符中请求的服务。
（2）错误可能性
监听程序可能挂了，也可能是listener.ora文件中的配置有问题。
（3）错误排查

登录数据库服务器，cmd窗口执行 “lsnrctl status” 命令，发现监听没有启动。于是执行 “lsnrctl start”命令启动监听，启动后注意到 “UNKNOWN” 标识——静态监听，说明其依赖listener.ora文件配置。

继续尝试连接，依然报错ORA-12514。

考虑到是静态监听模式，此时高度怀疑listener.ora文件配置有误；检查发现listener.ora文件中并没有关于目标实例的配置信息，于是将目标实例信息补充到文件中。

调整完listener.ora文件，重启监听；再次尝试连接，连接成功。
错误复盘
这个错误是比较基础的：listener.ora文件配置缺少目标实例信息、监听未启动。和现场沟通后得知是业务工程人员自己部署用来测试的，所以并未注意这两个细节。

案例2：客户端连接报错ORA-28547

项目场景
业务工程人员使用PLSQL工具，连接部署在Windows系统上的Oracle 11gR2单机数据库，报错ORA-28547。

分析排查
（1）错误代码含义
ORA-28547 是指客户端与服务器通信失败。
（2）错误可能性
由于是第一次看到这个错误代码，也已经排查过监听配置文件、监听程序无异常。所以网上查阅多篇资料，梳理总结如下：

1、配置文件中存在问题；
2、环境问题：未安装Oracle客户端、防火墙未放行1521端口；
3、数据库连接工具的OCI版本与目标数据库不匹配；

（3）错误排查

1、listener.ora文件、tnsnames.ora文件都已经排查过，未有写错的服务名和路径。
2、防火墙关闭，且在同一网段，不会是网络问题；客户端也已安装，且环境变量正确。
3、OCI版本也无误

似乎无计可施了。终于在对比检查了多次listener.ora文件后，发现某行多了个括号，格式发生错误。于是删除多余括号，再次尝试连接，连接成功。

错误复盘
这次的错误同样基础，但却十分隐蔽：listener.ora文件格式错误，仅仅只是多了个括号。这是我自己在listener.ora文件中 手敲 监听配置信息造成的错误，也再次提醒如果需要手工调整监听配置文件，最好是从其他数据库配置文件或者samples模版文件中拷贝修改，避免失误。

案例3：客户端连接报错：Got minus one from a read call

项目场景
业务工程人员使用DBever工具连接 19C数据库时，报错：Got minus one from a read call，连接失败。

分析排查
（1）错误含义
“Got minus one from a read call” ：读取call的结果是-1。字面上看不出什么，所以查看告警日志和监听日志；其中告警日志无异常，监听日志中发现如下报错：

（2）错误可能性
监听日志中显示TNS-12518, TNS-12547, TNS-12560, TNS-00517的组合报错。尝试将这个错误抛给deepseek，给出了如下原因：

1、内存资源不足
2、权限问题
3、操作系统bug
4、资源限制（/etc/security/limits.conf配置的资源限制参数过低）
5、网络配置问题

不得不说，deepseek挺强大的，将所有的可能性都列举了出来。但是它似乎只是联网汇总分析了网上的文章，给出的每一种可能性权重都是一样的，我抓不住它给出的重点，而且很多地方只是浅尝辄止。
（3）错误排查

系统内存资源、Oracle相关目录权限、资源限制参数都很快检查完了；至于操作系统bug，我没想着排查，因为太高级我不会…。并且尝试使用sqlplus连接，也连接不上，所以也排除客户端驱动问题。

最后我还是将目标瞄向监听配置文件，但是服务名、路径、主机名等每一个参数，都没有问题；格式也没问题。

于是我打开了另外一台数据库的监听配置文件仔细对比，在对比了非常多次之后，发现在listener.ora文件中，ORACLE_HOME的路径，末尾处有个 “/” 。我不知道是不是它的问题，但也将其删除，重启监听，再次尝试连接，连接成功。

错误复盘
数据库使用的是静态监听，完全依赖监听配置文件。部署这台数据库的DBA在手动配置监听文件时，不知道在listener.ora文件中ORACLE_HOME路径末尾不能有 “/”。这是个细节问题，很隐蔽，但却很关键。

案例4：客户端连接报错：ORA-12518

项目场景
业务工程师反馈某备库连接不上，批处理报错。使用PLSQL登录显示ORA-12518。

分析排查
（1）错误含义
ORA-12518：监听收到了客户端的连接请求，但在将这个连接请求移交给数据库服务进程的时候失败了。
（2）错误可能性
这个错误的原因可能是操作系统内存资源告警、资源限制参数过低且已达到上限、数据库的process/session达到上限；严重的话也有可能是实例出现问题，PGA中的会话全局区不能再分配连接。
（3）错误排查
我并没有去检查操作系统内存资源和资源限制参数。直接去检查了process和session资源，发现资源已耗尽；调整完process后，问题解决。
错误复盘
此次连接错误，有两个原因：一是process参数本身设置不合理，才500；二是业务某个批处理未设置连接池，导致连接数很快消耗完。这两个错误都是可以提前预见和规避的。

案例5：客户端连接报错：ORA-28040

项目场景
低版本的JDBC驱动在连接Oracle 19C时，会遇到ORA-28040错误。
解决方案
1、可以选择升级JDBC驱动。
2、临时修改sqlnet.ora文件，向下兼容JDBC
将以下参数加入sqlnet.ora文件，如果没有该文件，需要手动创建。

可以执行lsnrctl status命令查看监听配置目录。

SQLNET.ALLOWED_LOGON_VERSION_SERVER=8  # 允许最低协议版本为 8（兼容 10g/11g）
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8

在调整完sqlnet.ora文件后，需要重启监听，配置才可生效。

2、总结

通过以上案例，可以发现：大部分连接问题都是因为监听配置文件有误，此外常见的还有数据库资源限制问题。当发生连接故障时，我们可能记不住那么多不同的错误代码，但是可以优先从配置文件、数据库资源方面着手排查；这也是提醒我们在手动操作配置文件时务必要细心。