是的伙计们,这又是一次.
"已成功与服务器建立连接,但在登录过程中发生错误(提供程序:TCP提供程序,错误:0 - 远程主机强制关闭现有连接.)"
对不起......我有谷歌这个,我已经阅读了关于这个问题的其他StackOverflow文章,我已经尝试了各种建议,但没有任何作用.
这里有一些关于我们所看到的内容的注释.
此问题偶尔发生在SQL Server Management Studio本身(执行任何类型的数据库活动...获取数据库中的表列表,查看存储过程等)
它也发生在Visual Studio 2010本身,当它试图从服务器获取数据时(例如,在创建.dbml文件时等)
它有时也会发生在我们的.Net(ASP,WPF,Silverlight)应用程序中.
我们的SQL Server 2005和2008服务器都基于全球数据中心的虚拟机,我们有时会看到每个服务器出现此错误.但大多数时候,他们都工作得非常好.
当错误发生时,我们可以"重试"导致错误的原因,然后它将正常工作.
我们认为..如果我们在特定城市的数据中心有一个IIS Web服务器,并且它访问同一数据中心的SQL Server,那么我们就看不到问题了.
我们认为..如果我们连接到服务器,并指定要使用的UserID和密码,它会比我们只使用Active Directory身份验证更频繁地导致此错误.
把所有这些放在一起,听起来像是某种网络问题.
但任何人都可以建议寻找什么？
这不是我们的.Net应用程序中的错误,因为即使SQL Server Management Studio因此错误"绊倒".
这让我们感到困惑.
为了防止其他人遇到这个问题,我们终于找到了解决方案.
我们公司使用Riverbed软件压缩数据,当它在位置之间传递时,这会以某种方式导致某些连接被丢弃.
我们的IT专家发现了一个配置设置,最终解决了这个问题.
我相信有一个设置来关闭来自SQL Server(或类似的东西)的压缩结果.这为我们解决了.
这可能是任意数量的网络问题。任何阻止代码到达服务器的东西，即使是在进行一次查询所需的几毫秒内。
它也可能是故障转移的结果。当我们从单个 SQL Server 转到集群环境时，我们会在故障转移期间看到这种情况发生。在这种情况下，结果就是我们的连接池。本质上，SQL集群有一个控制器和其背后的两个服务器。A和B。
假设我们的 Web 应用程序使用服务器 A 就好，连接池会在两侧创建连接。服务器知道这一点，网络应用程序也知道这一点。一旦集群故障转移到第二台服务器，Web 应用程序就会知道该连接，但服务器 B 不会，因此我们会收到错误。
关键是，任何可以想象到的网络问题的可能原因都可能是原因。服务器上的 DOS 攻击、中间人攻击拦截和改变流量。有人被以太网电缆绊倒，并且电缆在插孔中松动。只要你能想到的，如果它能导致连接问题，它就可能是原因。
您的问题听起来也像我们最近遇到的问题 - 我们还有一个虚拟环境，其中的软件可以根据负载平衡的需要将虚拟机从一台主机移动到另一台主机。我们经常会遇到同样的错误。事实证明，这是其中一台主机上的 NIC 驱动程序的问题，因此每当虚拟机移动到该特定主机时，就会出现错误。
这确实不是一个编程问题。这是一个环境问题，您需要训练有素的专业人员可以直接进入您的环境来研究和解决这个问题。
| 归档时间： |
|
| 查看次数： |
57448 次 |
| 最近记录： |