問題詳細信息
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