一夜不活动后的一般网络错误

Question

一段时间以来，我们的旗舰应用程序一直存在神秘错误。错误消息是通用

  

[DBNETLIB] [ConnectionWrite（send（））。]常规网络错误。检查您的网络文档。

这可以通过让应用程序在晚上开放并在早上恢复工作来可靠地再现。由于它是后端服务器应用程序，这是正常情况。

有趣的是 - 我们已经从SQL Server 7迁移到2000年到2008年，所有这些问题都存在。但似乎重要的是我们运行应用程序的操作系统。在WinXP上运行正常，在Vista / 7上它失败了。所以问题出在客户端。

Google在错误消息上的结果涵盖了非常广泛的不同原因（因为这是一个非常一般的错误），并且没有找到与我们类似的情景。

所以也许周围的人会知道我们的问题是什么？

Answer 1

您应该能够通过以下方式重现此错误情况：
1.打开数据库连接（在客户端应用程序中）
2.拔下网线插头
3.重新插入网络电缆（等待网络连接恢复）
4.使用先前打开的连接查询数据库

据我所知，客户端ADO代码无法一致地确定底层网络连接是否实际有效。检查数据库连接是否已打开（在客户端代码中）返回true。但是，对该连接执行任何操作都会导致General network error。

连接池似乎能够确定连接何时变为“坏”，因此它永远不会返回与应用程序的错误连接。它只是打开一个新的连接。

因此，如果应用程序长时间保持数据库连接（已使用或未使用），则底层TCP / IP连接可能会中断。

底线是应该关闭数据库连接，并在不使用时将其返回到连接池。

修改

此外，根据连接到数据库的客户端数量，不使用连接池可能会导致另一个问题。您可以达到服务器端打开的最大套接字数。这是来自记忆。在客户端关闭连接后，服务器上的连接将进入TIME_WAIT状态。默认情况下，服务器套接字大约需要4分钟才能关闭，因此在此期间其他客户端无法使用它。最重要的是，服务器上的可用套接字数量有限。保持太多连接打开可能会产生问题。

我工作过的一个项目很容易达到这个套接字限制，大约有120个用户。添加了一个新的“功能”，绝对会破坏服务器，在使用该应用程序几个小时后，每个人都会突然停下来。 SQL服务器没有及时关闭足够的套接字以用于新的连接请求。尽管共有65K个套接字，但只有前5000个套接字可供ADO使用（这是默认的注册表设置，因此可以更改）。

TIME_WAIT状态下的套接字数量会慢慢增加，直到操作系统不再分配为止。因此，客户端必须等到服务器端套接字关闭，然后才能创建新连接。

Answer 2

您是否尝试停用SNP/TCP Chimneying？

Answer 3

有类似的错误。对我而言，这是由于对WSACleanup和WSAStartup的调用不匹配造成的。

该程序调用的WSACleanup次数超过WSAStartup次。这将导致引用计数器（套接字库中的某个位置）过早地达到零。

我认为，从那一刻开始，流程所拥有的所有套接字都会被破坏。

这也会杀死SQL客户端，因为它也使用套接字与SQL服务器“对话”。