问题详细信息
SQL30081N错误消息具有以下格式：
SQL30081N已检测到通信错误。使用的通信协议：protocol。使用的通信API：interface。检测到错误的位置：location。检测错误的通讯功能：功能。协议特定的错误代码：rc1，rc2，rc3
例如：
SQL30081N已检测到通信错误。使用的通信协议
：“ TCP / IP”。使用的通信API：“ SOCKETS”。位置
检测到错误的位置：“”。通讯功能检测到错误：“连接”。
协议特定的错误代码：“ 111”，“ *”，“ *”。
当DB2调用从DB2外部的组件接收到错误消息的操作系统套接字API时，将返回这些错误消息。这些套接字错误将传播回DB2，后者将错误封装在SQL30081N消息中。根本原因不在DB2的控制范围之内，它可能在客户机/服务器网络堆栈或它们之间的网络设备中。网络跟踪应由网络管理员从客户端和服务器端收集并分析，以确定根本原因。DB2是SQL30081N的受害者。
下表列出了可能在不同平台上发生的协议特定错误以及解决这些错误的相应操作计划。如果错误代码未在表中列出，请搜索操作系统文档/usr/include/errno.h（Linux / UNIX）或系统错误代码（Windows）。
对于以下非Java应用程序关键字，请参考：
db2cli.ini关键字：由CLI / ODBC应用程序使用
db2dsdriver.cfg关键字：使用IBM .NET提供程序的Windows应用程序
DB2注册表变量（请参阅通信组）
对于Java应用程序，请参阅FAQ JDBC ERRORCODE = -4499连接
| 视窗 | 艾克斯 | 太阳 | 生命值 | 的Linux | 简称 | 行动计划 |
| 10061 | 79 | 146 | 239 | 111 | 拒绝
拒绝连接 |
客户端尝试使用无效的IP或端口建立与服务器的连接。
检查服务器端： 设置DB2环境变量DB2COMM，例如：DB2COMM = TCPIP DBM CFG的SVCENAME设置为实例的端口号或服务名称。更新此参数的命令是：“使用svcename <端口/服务名称>的db2更新dbm cfg” 如果通过检查“服务”文件来设置服务名称，以查看该名称是否对应于未使用的端口号。 确保DB2服务器实例已正确启动。 在客户端检查： 节点目录的条目： 服务名称应显示与DB2服务器的实例端口相对应的正确端口号或服务名称（svcename设置） 要检查服务器的端口是否打开： telnet <主机名> <端口> 如果命令失败，则服务器上的端口未打开，问题出在DB2区域之外。 有关ECONNREFUSED的其他技术说明： http://www.ibm.com/support/docview.wss?rs=71&uid=swg21328644 |
| 视窗 | 艾克斯 | 太阳 | 生命值 | 的Linux | 简称 | 行动计划 |
| 10053 | 72 | 103 | 协办
软件导致连接中止。 |
软件关闭连接
如果在使用ODBC / CLI连接到DB2 UDB服务器的客户端应用程序上报告了错误： 禁用DB2的CLI超时： 将“ QUERYTIMEOUTINTERVAL = 0”添加到客户端一侧的db2cli.ini文件中。 检查应用程序是否超时。 例如ADO超时，VB超时 如果应用程序连接到OS390服务器，请检查OS390上的idlethreadtimeout参数（IDTHTOIN）。 此参数设置OS390上的活动线程超时限制。 |
||
| 视窗 | 艾克斯 | 太阳 | 生命值 | 的Linux | 简称 | 行动计划 |
| 10054 | 73 | 131 | 232 | 104 | ECONNRESET
合作伙伴已重置连接 |
连接的伙伴已关闭连接。
检查合作伙伴端的任何超时限制。 例如防火墙，应用程序，DB2 CLI层等 如果在使用ODBC / CLI连接到DB2 UDB服务器的客户端应用程序上报告了错误： 禁用DB2的CLI超时： 将“ QUERYTIMEOUTINTERVAL = 0”添加到客户端一侧的db2cli.ini文件中。 检查客户端和服务器之间是否有防火墙。 开放连接是否有时间限制 检查应用程序是否超时。 例如ADO超时，VB超时。 此错误也可能是由technote_1395285中描述的问题引起的。 当使用与数据库名称不同的别名来命名本地数据库连接时，尝试使用TCPIP连接连接到该数据库时可能会出现错误SQL30081。 如果在尝试连接数据库时收到该错误，请确保该数据库所在的计算机上未使用与数据库名称不同的别名对数据库进行分类。 |
| 视窗 | 艾克斯 | 太阳 | 生命值 | 的Linux | 简称 | 行动计划 |
| 10060 | 78 | 145 | 238 | 110 | 超时
连接超时 |
连接已达到网络超时限制，并被网络终止
tcpip层超时 TCPIP具有其自己的超时值，如果打开的连接停留的时间过长，TCPIP将强制关闭连接。 通常这是网络问题 解决方法：
见注1 |
| 视窗 | 艾克斯 | 太阳 | 生命值 | 的Linux | 简称 | 行动计划 |
| 10048 | 67 | 125 | 226 | 98 | EADDRINUSE
指定的地址已被使用 |
答：2个实例正在同一台机器上启动并在同一端口上侦听（通常会在db2start上捕获）
B：客户端应用程序或代理正在尝试进行传出连接，并且正在使用套接字，该套接字已被另一个与数据库的连接使用或处于等待状态（2MSL状态）。 通常只发生在Windows客户端上： 这是Microsoft错误。Winsock提供的端口已被使用（Winsock缺陷）或已关闭，但仍处于等待状态。 Windows的解决方法： 1.调整时间，以使套接字在关闭后进入等待状态（默认为2分钟） TcpTimedWaitDelay 见注3 2.调整可用的端口数（默认为5000） 最大用户端口 见注4 3. 调整连接/断开连接的用法，以免它在程序中循环得太快（最佳解决方案）。10048通常是由应用程序中的快速连接/断开逻辑引起的，该逻辑将太多端口置于time_wait状态（2MSL）。当应用程序发出多个语句时，重新使用连接句柄是处理此问题的最佳方法（不要断开连接，然后在每次语句完成时重新连接） 4. 实现客户端连接池，以便内部的应用程序逻辑不必更改。确保池足够大，可以处理80％的连接。如果空闲时断开连接，请确保池具有某种形式的重新连接逻辑。 |
| 视窗 | 艾克斯 | 太阳 | 生命值 | 的Linux | 简称 | 行动计划 |
| 10055 | 74 | 132 | 233 | 105 | ENOBUFS
没有可用的缓冲区空间 |
系统资源不足，无法完成TCPIP调用
对于Windows： 该问题是由于Windows桌面堆或系统页面表条目用完而引起的。它与DB2不相关。 增加Windows SystemPages注册表项。 |
| 视窗 | 艾克斯 | 太阳 | 生命值 | 的Linux | 简称 | 行动计划 |
| 32 | 32 | EPIPE（断管） | 客户端和服务器之间的网络连接问题，请在客户端和服务器上运行网络嗅探器跟踪。 | |||
| 10004（WSAEINTR） | 客户端关闭了连接。对于DB2 z，请参阅技术说明 | |||||
| 10065 | 81 | 113 | WSAEHOSTUNREACH | 无主机路由 对于Windows客户端，Linux服务器： 取消设置Linux服务器上的防火墙以允许客户端进行连接。 |
|
在某些情况下，没有返回任何返回代码，例如以下示例： 可能的原因1 可能的原因2 禁用在DB2数据库服务器上运行的所有网络安全和服务器安全软件，以确定此问题已解决。来自不同供应商的多个安全产品可能会产生负面影响，并显示为*，*，0。 检查以确定DB2服务器是否启用了Workload Manager，在其中将断开耗时超过xx分钟的SQL查询。在下面的示例中是15分钟。 进一步的故障排除 A）从DB2客户端和DB2服务器端收集DB2跟踪。 注意：这不适用于使用JDBC驱动程序（db2jcc.jar / db2jcc4.jar）的Java应用程序。对于Java应用程序，请参阅收集数据：使用IBM Data Server Driver for JDBC和SQL J 进行跟踪 客户端 注意：较旧的DB2版本不支持“ -wc”选项。在旧版本上删除此参数。 服务器 1）db2trc on -t -f strace.dmp -Madd SQLJC -Madd SQLJS -Madd SQLR -Madd SQLCC B）网络跟踪 如果建议没有帮助，因为DB2诊断无法提供对操作系统和网络层的可见性，则建议对网络和客户端的网络嗅探器跟踪（Linux：tcpdump，Windows：Wireshark）进行收集并由网络管理员进行分析，以确定SQL30081的根本原因。一旦调用了操作系统提供的套接字API。 C）其他测试工具pctt和ping 〜/ sqllib / bin / pctt（Linux / UNIX）或C： Program Files IBM SQLLIB bin pctt.exe（Windows）中包含的独立pct工具可以在客户端和服务器模式下运行。它在DB2之外的客户机和服务器之间建立了单独的网络连接，以测试网络连接。该用法已记录在DB2 v11.1中，并已通过DB2 v11.1进行了测试。请注意，在服务器模式下指定较大的缓冲区大小时（即pctt s / b 32767），侦听器可能会转储。使用较小的缓冲区大小。该程序可能会也可能不会出现任何间歇性的连接问题。《IBM DB2通用数据库故障排除指南》的第132页中记录了pctt的用法。 DB2附带的ping命令还可用于确定是否存在不一致的延迟问题。 $ db2 ping dbName请求32767 5 耗用时间：692983微秒 耗用时间：419739微秒 耗用时间：419867微秒 耗用时间：210229微秒 经过时间：210103微秒 $ db2 ping dbName响应32767 5 经过时间：1241微秒 经过时间：1217微秒 耗用时间：1236微秒 经过时间：2575774微秒<<<<< 2.5秒 经过时间：3526微秒 |
注1：从DB2手册中可以进一步解释KEEPALIVE的功能以及如何使用它。
DB2使用TCP / IP的连接KEEPALIVE选项来检测是否存在连接失败。此选项会定期发送一条消息，以确定伙伴是否还活着。如果伙伴未能响应此消息，则认为连接已断开，并返回错误。
笔记2：
KEEPALIVE设置会影响计算机上运行的所有TCP / IP应用程序。
对于Windows 95，Windows 98和Windows NT：
在注册表中使用KeepAliveTime TCP / IP配置参数。如果KEEPALIVE参数在Parameters注册表子项下不存在，则可以创建它。将此参数添加到以下内容：
HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services Tcpip Parameters
默认值为两个小时。
对于OS / 2：
使用inetcfg命令。（对于OS / 2 TCP / IP版本2.0，必须应用修订CSD UN64092才能使用此命令。）
对于AIX：
使用no命令更改网络选项tcp_keepidle和tcp_keepintvl的值（有关详细信息，请键入man no）。默认值为两个小时。
对于HP-UX系统：
使用nettune命令更改网络选项tcp_keepstart和tcp_keepfreq的值（有关详细信息，请键入man nettune）。
对于Solaris系统：
使用以下命令更改网络选项tcp_keepalive_interval的值：
ndd -set / dev / tcp tcp_keepalive_interval 值
（有关详细信息，请键入man ndd。）
对于其他平台：
有关配置KEEPALIVE设置的详细信息，请参见TCP / IP文档。如果TCP / IP堆栈不支持它，则DB2不使用它。
注3：
此参数确定关闭连接时连接保持在TIME_WAIT状态的时间长度。当连接处于TIME_WAIT状态时，套接字对不能重用。这也称为2MSL状态，因为该值应该是网络上最大段寿命的两倍。有关更多详细信息，请参见RFC 793。
注4：
当应用程序从系统请求任何可用的用户端口时，此参数控制使用的最大端口号。通常，短期端口的分配范围是1024到5000。将此参数设置为有效范围之外的值会导致使用最近的有效值（5000或65534）。
注5：
对于其他TCPIP消息。
V8.2：http：//publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/core/rcommsec.htm
V9.1：http：// publib。 boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.msg.doc/doc/rcommsec.htm
V9.5：http：//publib.boulder.ibm.com/infocenter/db2luw /v9r5/topic/com.ibm.db2.luw.messages.doc/doc/r0052008.html
V9.7：
http：//publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm。 db2.luw.messages.doc / doc / r0052008.html
V9.8：
http : //publib.boulder.ibm.com/infocenter/db2luw/v9r8/topic/com.ibm.db2.luw.messages.sql.doc /doc/msql30081n.html