title: How to determine root cause for Communication link failure TCP Provider: The specified network name is no longer available?
body: <p>Here is my latest effort at revising this question. But this time, I am trying to follow the good counsel given by Oded in his article <a href="http://odedcoster.com/blog/2010/07/28/getting-good-answers-on-stackoverflow-part-1-of-n/" rel="nofollow noreferrer">Getting good answers on StackOverflow</a>.</p>
  
  <p>I need to find out how I can determine the root cause for the following error:</p>
  
  <blockquote>
    <p>Communication link failure </p>
    
    <p>TCP Provider: The specified network name is no longer available</p>
  </blockquote>
  
  <p>From time to time, I am seeing this error when running a set of SSIS packages. This error can occur when one to many packages are run from:</p>
  
  <ol>
  <li>A SQL Server Agent Job</li>
  <li>A batch file</li>
  <li>In debug mode from BIDS</li>
  </ol>
  
  <p>The full error message I see is as follows:</p>
  
  <blockquote>
    <p>SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x80004005.
        An OLE DB record is available.  Source: "Microsoft SQL Server Native Client 10.0"  Hresult: 0x80004005  Description: "Communication link failure".
        An OLE DB record is available.  Source: "Microsoft SQL Server Native Client 10.0"  Hresult: 0x80004005  Description: "TCP Provider: The specified network name is no longer available.
        ".</p>
    
    <p>SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x80004005.
        An OLE DB record is available.  Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005  Description: "Protocol error in TDS stream".
        An OLE DB record is available.  Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005  Description: "Communication link failure".
        An OLE DB record is available.  Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005  Description: "TCP Provider: An existing connection was forcibly closed by the remote host."</p>
  </blockquote>
  
  <p>This is an overview of how I have designed the ETL process:</p>
  
  <ul>
  <li>Two servers </li>
  <li>Both are virtual machines </li>
  <li>The SSIS packages run on an application server </li>
  <li>The SQL Server database lives on a database server</li>
  </ul>
  
  <p>I use an OLE DB connection manager to connect from the SSIS package on the application server to the SQL Server database on the database server. </p>
  
  <p>The packages run as a file system deployment on the application server and not as a database deployment on the database server.</p>
  
  <p>The main reason for this is that the ETL is integrated with a set of tools no found on and drives not accessible to the database server. These tools include Apex Data Loader for Salesforce and pgAdmin III.</p>
  
  <p>So far I cannot consistently reproduce this error. However, this is what I have observed: </p>
  
  <ul>
  <li>Failure occurs more frequently during regular business hours</li>
  <li>Failure occurs less frequently during off hours</li>
  </ul>
  
  <p>For about a two hour period on a Friday morning I was able to successfully reproduce the error on a specific package.</p>
  
  <p>The error occurred during a large data flow if a child package call that precedes the large data flow was enabled.</p>
  
  <p>The error did not occur during the same large data flow if the child package call that precedes the large data flow was disabled.</p>
  
  <p>The child package in question calls back to the database to retrieve a tiny amount of information for use in an email body and then sends the email.</p>
  
  <p>It feels like maybe a resource limit is being exceeded? </p>
  
  <p>Maybe a connection limit? </p>
  
  <p>I am wondering what tools I should be using to try and determine the root cause of the error.</p>
  
  <p>Technical details about the two servers involved are listed below:
  <br />
  <br /></p>
  
  <blockquote>
    <p><strong>SQL Server and Database Server info:</strong><br />
    Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)   Jun 17 2011 00:54:03   Copyright (c) Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 6.1  (Build 7601: Service Pack 1) (Hypervisor) </p>
    
    <p><strong>SSIS info:</strong><br />
    Microsoft Visual Studio 2008 Version 9.0.30729.1 SP
    Microsoft .NET Framework Version 3.5 SP1</p>
    
    <p><strong>Application Server info:</strong><br />
    OS name: Microsoft Windows Server 2008 R2 Standard
    Version: 6.1.7601 Service Pack 1 Build 7601</p>
  </blockquote>
  
  <p>I have researched the error message online and found these, but would really like to get an expert's insight before proceeding:</p>
  
  <ul>
  <li><a href="http://www.symantec.com/business/support/index?page=content&amp;id=TECH197934" rel="nofollow noreferrer">How to Disable TCP Chimney, TCPIP Offload Engine (TOE) or TCP Segmentation Offload (TSO).</a></li>
  <li><a href="http://technet.microsoft.com/en-us/library/gg162682%28v=ws.10%29.aspx" rel="nofollow noreferrer">Using Netsh Commands to Enable or Disable TCP Chimney Offload</a></li>
  </ul>
  
  <p>Any help is appreciated. </p>
  
  <p>Thanks</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>Further testing shows that this is not "an SSIS thing" as the same error is seen at the same rate when using SQL Server Management Studio. The complexity of the query does not make the error more or less likely. In an attempt to resolve, we have tried one fix (below):</p>
  
  <ul>
  <li><strong><a href="http://www.symantec.com/business/support/index?page=content&amp;id=TECH197934" rel="nofollow noreferrer"> #1 How to Disable TCP Chimney, TCPIP Offload Engine (TOE) or TCP Segmentation Offload (TSO).</a></strong></li>
  </ul>
  
  <p>This was our first attempt. TCP Chimney is now disabled on the Application Server and the Database Server. Testing shows that the same error occurs at the same rate.</p>
  
  <p>So where to go from here? Honestly I am not sure. One seemingly good option remains: </p>
  
  <ul>
  <li>Application Server and Database Server SQL Server installations do not exactly match</li>
  <li>Application Server = SQL Server 2008 (SP1) - 10.0.2531.0 (X64)</li>
  <li>Database Server = SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) </li>
  </ul>
  
  <p>The plan is to upgrade the SQL Server installation on the Application server. Its kind of a hit and hope, but at this point this seems like the best option. Something in my brain tells me that this might be solved by fixing a hardware issue (by that I mean a repair or a replace) and that there might not be anything that hardware and software configuration can do about it.</p>
  
  <p>However, I am still not sure how to go about determining a root cause. I am still left wondering what tools I should be using to diagnose the root cause.</p>