如何确定通信链路故障的根本原因TCP提供商：指定的网络名称不再可用？

Question

这是我最近修改这个问题的努力。但是这次，我试图遵循Oded在他的文章Getting good answers on StackOverflow中给出的好忠告。

我需要找出如何确定以下错误的根本原因：

通信链路故障

TCP提供程序：指定的网络名称不再可用

有时，我在运行一组SSIS包时看到此错误。运行一到多个包时可能会发生此错误：

1. SQL Server代理作业
2. 批处理文件
3. 在BIDS的调试模式下

我看到的完整错误消息如下：

SSIS错误代码DTS_E_OLEDBERROR。发生OLE DB错误。错误代码：0x80004005。 OLE DB记录可用。来源：“Microsoft SQL Server Native Client 10.0”Hresult：0x80004005描述：“通信链接失败”。 OLE DB记录可用。来源：“Microsoft SQL Server Native Client 10.0”Hresult：0x80004005说明：“TCP提供程序：指定的网络名称不再可用。”。

SSIS错误代码DTS_E_OLEDBERROR。发生OLE DB错误。错误代码：0x80004005。 OLE DB记录可用。来源：“Microsoft SQL Server Native Client 10.0”Hresult：0x80004005描述：“TDS流中的协议错误”。 OLE DB记录可用。来源：“Microsoft SQL Server Native Client 10.0”Hresult：0x80004005描述：“通信链接失败”。 OLE DB记录可用。来源：“Microsoft SQL Server Native Client 10.0”Hresult：0x80004005说明：“TCP提供程序：远程主机强行关闭现有连接。”

这是我如何设计ETL过程的概述：

• 两台服务器
• 两者都是虚拟机
• SSIS包在应用程序服务器上运行
• SQL Server数据库位于数据库服务器上

我使用OLE DB连接管理器从应用程序服务器上的SSIS包连接到数据库服务器上的SQL Server数据库。

这些包在应用程序服务器上作为文件系统部署运行，而不是在数据库服务器上作为数据库部署运行。

这样做的主要原因是ETL与一组找不到的工具集成，并且驱动器无法访问数据库服务器。这些工具包括适用于Salesforce的Apex Data Loader和pgAdmin III。

到目前为止，我无法一致地重现此错误。但是，这是我观察到的：

• 在正常工作时间内更频繁地发生故障
• 在非工作时间发生故障的次数较少

在星期五早上大约两个小时的时间里，我能够成功地重现特定包装上的错误。

如果启用了大数据流之前的子包调用，则在大数据流期间发生错误。

如果禁用了大数据流之前的子包调用，则在同一大数据流期间不会发生错误。

有问题的子包回调数据库以检索少量信息以便在电子邮件正文中使用，然后发送电子邮件。

感觉可能超出了资源限制？

也许连接限制？

我想知道我应该使用什么工具来尝试确定错误的根本原因。

有关这两个服务器的技术细节如下：

SQL Server和数据库服务器信息： Microsoft SQL Server 2008 R2（SP1） - 10.50.2500.0（X64）2011年6月17日00:54:03版权所有（c）Microsoft Corporation企业版（64位）在Windows NT 6.1（Build 7601：Service Pack 1）上（管理程序） ）

SSIS信息： Microsoft Visual Studio 2008版本9.0.30729.1 SP Microsoft .NET Framework版本3.5 SP1

Application Server信息： 操作系统名称：Microsoft Windows Server 2008 R2标准版：6.1.7601 Service Pack 1 Build 7601

我已经在线研究了错误信息并找到了这些信息，但是在继续之前我真的希望获得专家的见解：

• How to Disable TCP Chimney, TCPIP Offload Engine (TOE) or TCP Segmentation Offload (TSO).
• Using Netsh Commands to Enable or Disable TCP Chimney Offload

任何帮助表示赞赏。

谢谢

更新：

进一步的测试表明，这不是“SSIS的事情”，因为在使用SQL Server Management Studio时，同样的错误也是如此。查询的复杂性不会使错误或多或少发生错误。为了解决这个问题，我们尝试了一个修复程序（如下）：

• #1 How to Disable TCP Chimney, TCPIP Offload Engine (TOE) or TCP Segmentation Offload (TSO).

这是我们的第一次尝试。现在，在应用程序服务器和数据库服务器上禁用了TCP烟囱。测试显示相同的错误以相同的速率发生。

那么从哪里开始呢？老实说，我不确定。一个看似不错的选择仍然是：

• Application Server和Database Server SQL Server安装不完全匹配
• Application Server = SQL Server 2008（SP1） - 10.0.2531.0（X64）
• 数据库服务器= SQL Server 2008 R2（SP1） - 10.50.2500.0（X64）

计划是升级应用程序服务器上的SQL Server安装。这是一种打击和希望，但在这一点上，这似乎是最好的选择。我脑子里的东西告诉我，这可以通过修复硬件问题来解决（我的意思是修复或替换），并且硬件和软件配置可能没有任何关于它的事情。

但是，我仍然不确定如何确定根本原因。我仍然想知道我应该用什么工具来诊断根本原因。

Answer 1

你在Application Server端有AV软件吗？如果是，请尝试禁用AV - 有时AV会阻止TCP / IP流量。通过在此处禁用AV解决了“指定的网络名称不再可用”的问题：https://community.spiceworks.com/topic/239423-the-specified-network-name-is-no-longer-available-while-writing-to-shared-dir

Answer 2

该错误消息表明该连接被强制关闭。您还提到当您运行大量工作时会发生这种情况。机会是，网络防火墙是罪魁祸首。您应该联系防火墙管理员来研究日志，以查看防火墙是否关闭了连接。如果是这种情况，则存在两种可能的解决方案：

1. 为触发的任何防火墙规则添加例外并导致连接关闭。
2. 停止同时运行这么多作业。您应该考虑按顺序运行它们。这也坚持成为一个优秀的网络公民的想法。

Answer 3

1. 首先，您是否尝试删除nic上的大型发送卸载设置？
2. 第二点，如果可以重现错误，你可以运行wireshark来捕获数据包吗？
3. 第三点，您是否尝试过从VM更改vnic？某些模型可能会导致问题。 （如果您使用vmxnet3，请尝试使用e1000等。）
4. 最后一点，它们之间是否有vswitch，它们位于同一主机上，物理交换机之间等等......配置错误的交换机可能会丢弃流量，如果主机内部有相同的主机且同一个vswitch则是最佳测试，如流量永远不会离开服务器。

Answer 4

尝试使用ODBC而不是OLE DB来连接数据库。