我们刚刚完成了从SQL 2000到SQL 2008 R2的迁移，并且已经开始间歇性地接收到SqlExceptions以下两条错误消息：
我们有3台Web服务器连接到运行大约100个应用程序的SQL Server（全部访问SQL Server上的相同8个数据库）。
因为2000服务器上没有发生这些exception情况，所以我们认为这不太可能是一个应用程序问题（但是我们并不排除）。 网站上的stream量是典型的，排除了高stream量问题。 旧的SQL 2000盒子有4个CPU和8 GB的RAM，而新的有24 GB的RAM和16个CPU（目前和这个问题未充分利用）。
这些错误几个小时前发生了大约5分钟的时间，并且还没有重新发生。
sys.dm_os_ring_buffers系统视图不显示这些断开连接的条目，并且在服务器或客户机上都没有对应的事件日志条目。
一些谷歌search发现了一些类似的报告，但没有什么似乎明确（见下面的链接）。 有没有人从SQL 2000迁移到SQL 2008 R2后看到类似这样的错误？
链接：
我们已经在我们的环境中跟踪并解决了这个问题。 我理解下面的描述（请原谅以下可能的错误;这是我（作为一个软件开发人员）理解我们的networkingpipe理员（谁也与我们的托pipe公司）给我的描述的方式。
原因最终被追查为涉及负载均衡器的networkingconfiguration问题。 我们曾经期望Load Balancer坐在互联网和我们的networking服务器之间，而且我们所有的服务器都可以自由地进行通信。 不幸的是，networking的设置方式是所有networkingstream量（包括SQL Server和Web服务器之间的stream量）都通过负载均衡器。 负载平衡器被configuration为限制通过它的带宽，当超过限制时，它会丢弃数据包。 当服务器之间发生大文件传输时（例如，从数据库服务器拷贝数据库备份等时），经常会超出限制。 这很难让我们看到，因为我们没有访问负载均衡器（只有我们的托pipe服务提供商可以访问它），并且据我们所知，我们远远没有饱和我们的networking接口。 另外，这些问题是非常零星的（每3-5个月几分钟）。
解决方法是重新安排环境，以免内部networkingstream量通过LB; 我相信这个networking被重新安排，以适应一个单臂负载平衡架构。 自从做这个改变，我们没有经历间歇性连接问题。
如果我正确理解，你不仅改变了你的软件，而且改变了你的硬件 – 所以有很多改变可能导致这个连接错误。 我已经看到了很多build议，以检查您的网卡驱动程序和主板固件（!!）来解决这个问题。 哎呀！
无论如何 – 你应该能够在你的服务器应用程序日志中看到这个错误。 从这里你可能会发现发生exception的date/时间，所以你可以将它与个别的客户/应用程序事件进行比较，以缩小当这个exceptionpopup时发生的情况。
您也可以使用Netmon来跟踪从客户端到服务器的连接。 你会想要给它几天重现错误。 这应该缩小一点，至less让你知道什么是失败的。
上次我看到“信号量超时期已过”是当我试图将文件从一个硬盘驱动器复制到Windows Server 2008上的另一个。似乎是因为硬盘驱动器与严重分散的坏集群。 西部数据2TB鱼子酱绿色，顺便说一下，不在RAID中。
这一段时间已经过去了一段时间，但是我也想增加我的两分钱。 在我们的例子中，所涉及的SQL服务器位于不同的networking上，两者之间有防火墙，所以IPS起作用。 它已经工作了很多年，但是显然就在本周，IPS收到了一个旧的检测签名的新版本，它被称为“攻击MSSQL：Microsoft SQL缓冲区溢出漏洞高出站”。 因此它开始阻止通过端口1433的连接尝试。