在高容量.NET应用程序中，当您尝试执行查询时，您可能会看到此异常：
System.Data.SqlClient.SqlException：传输级错误有 将请求发送到服务器时发生。
根据我的研究，这是“刚刚发生”的事情，并没有太多可以防止它。它不会因错误查询而发生，通常无法复制。当由于某种原因与数据库的TCP连接变坏时，它可能在繁忙的OLTP系统中每隔几天就会出现一次。
我不得不通过解析异常消息来检测此错误，然后从头开始重试整个操作，以包含使用新连接。这些都不是很好。
有人有任何其他解决方案吗？
答案 0 :(得分：9)
我在另一个可能有用的主题上发布了an answer on another question。答案涉及SMB连接，而不是SQL。但它的相同之处在于它涉及低级别的传输错误。
我们发现，在负载很重的情况下，远程服务器很容易在TCP层上超时连接，因为服务器很忙。部分原因是TCP在Windows上重新传输数据的次数的默认值不适合我们的情况。
查看Windows上的registry settings for tuning TCP/IP。特别要考虑 TcpMaxDataRetransmissions 和 TcpMaxConnectRetransmissions 。这些默认分别为5和2，尝试在客户端系统上稍微增加它们并复制负载情况。
别发疯了！ TCP会在每次连续重传时使超时时间加倍，因此如果增加太多，则不良连接的超时行为可能会呈指数级增长。我记得在绝大多数情况下，将 TcpMaxDataRetransmissions 升级为6或7解决了我们的问题。
答案 1 :(得分：3)
此blog post Michael Aspengren解释了错误消息“将请求发送到服务器时发生了传输级错误。”
答案 2 :(得分：2)
回答你原来的问题：
在不解析错误消息的情况下检测此特定错误的更优雅方法是检查Number的{{1}}属性。
（这实际上会返回SqlException集合中第一个SqlError的错误编号，但在您的情况下，传输错误应该是集合中唯一的错误。）
答案 3 :(得分：1)
我已经多次在自己的环境中看到过这种情况。在这种情况下，客户端应用程序安装在许多机器上。其中一些机器碰巧是笔记本电脑，人们离开应用程序打开它，然后将其重新插入并尝试使用它。这将导致您提到的错误。
我的第一点是查看网络并确保服务器不在DHCP上并更新IP地址导致此错误。如果情况并非如此，那么您必须开始搜索事件日志，寻找其他与网络相关的内容。
不幸的是，如上所述，网络错误。你可以做的主要是使用像netmon这样的工具来监控连接，并从那里开始工作。
祝你好运。
答案 4 :(得分：1)
答案 5 :(得分：0)
您还应检查与数据库的硬件连接。
也许这个帖子会有所帮助： http://channel9.msdn.com/forums/TechOff/234271-Conenction-forcibly-closed-SQL-2005/
答案 6 :(得分：0)
我在我的数据库命令周围使用可靠性层（在存储库interfaece中抽象出来）。基本上这只是拦截任何预期异常的代码（DbException以及InvalidOperationException，恰好在连接问题上引发），记录它，捕获统计信息并再次重试所有内容。
在存在可靠性层的情况下，该服务能够在压力测试中得到优雅（恒定的死锁，网络故障等）。生产远没有那么恶劣。
PS：There is more on that here（以及通过拦截DSL定义可靠性的简单方法）
答案 7 :(得分：0)
我遇到了同样的问题。我问我的网络极客朋友，并且所有人都说过人们在这里回复了什么：它是计算机和数据库服务器之间的连接。在我的情况下，它是我的互联网服务提供商，或路由器是问题。路由器更新后，问题就消失了。但你有没有从你的计算机或服务器的互联网连接退出？我有......
答案 8 :(得分：0)
答案 9 :(得分：0)
我在SSMS连接到SQL 2008 R2 Express时遇到了今天早上的传输错误。
我试图用\ r \ n导入CSV。我将行终止符编码为0x0d0x0a。当我将其更改为0x0a时，错误停止。我可以来回改变它，看它发生/不发生。
BULK INSERT #t1 FROM 'C:\123\Import123.csv' WITH
( FIRSTROW = 1, FIELDTERMINATOR = ',', ROWTERMINATOR = '0x0d0x0a' )
我怀疑我没有正确编写行终止符，因为在我尝试传递两个字符时，SQL一次解析一个字符。
无论如何，这个错误现在已经有4年了，但它可能会为下一个用户提供一些信息。
答案 10 :(得分：0)
我只是想在这里发布一个针对我们公司安装的新软件的修复程序。我们从客户端日志文件的第1天开始收到以下错误：服务器无法处理请求。 ---＆GT;从服务器接收结果时发生传输级错误。 （提供者：TCP提供者，错误：0 - 信号量超时期限已过期。）---＆gt;信号量超时期限已过期。
完全解决问题的方法是在我们的交换机上设置链路聚合（LAG）。我们的Dell FX1服务器背面有冗余光纤线路。我们没有意识到他们插入的交换机需要在这两个端口上配置LAG。详情请见https://docs.meraki.com/display/MS/Switch+Ports#SwitchPorts-LinkAggregation