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

Jon*_*ssi 25 networking ssis virtual-machine sql-server-2008 windows-server-2008

这是我最近修改这个问题的努力.但是这一次,我试图遵循Oded在他的文章中获得的好建议在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)Windows NT 6.1上的Microsoft Corporation Enterprise Edition(64位)(Build 7601) :Service Pack 1)(管理程序)

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

应用程序服务器信息:
操作系统名称:Microsoft Windows Server 2008 R2标准版:6.1.7601 Service Pack 1 Build 7601

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

任何帮助表示赞赏.

谢谢

更新:

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

这是我们的第一次尝试.现在,在应用程序服务器和数据库服务器上禁用了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安装.这是一种打击和希望,但在这一点上,这似乎是最好的选择.我脑子里的东西告诉我,这可以通过修复硬件问题来解决(我的意思是修复或替换),并且硬件和软件配置可能没有任何关于它的事情.

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

小智 0

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