BizTalk and SQL 2008 DBNETLIB General Network Error

Proposed BizTalk and SQL 2008 DBNETLIB General Network Error

  • Monday, November 07, 2011 8:47 PM
     
     

    Hi All,

    We have BizTalk 2009 looking to a SQL 2008 Database hosted on clustered Server 2008 R2 Servers.  We frequently have issues with the BizTalk services not being able to communicate with SQL, they then crash and restart and work again.  This happens 2-3 times a day, little annoying to say the least.  I've come across the following posts that seem like they could be related but I'm not seeing much of a solution.

    http://support.microsoft.com/kb/899599

    http://blogs.technet.com/b/nettracer/archive/2010/06/01/syn-attack-protection-on-windows-vista-windows-2008-windows-7-and-windows-2008-r2.aspx

    We don't see any errors logged on the SQL server (at least any place I've thought to check).  Our software developers have also opened a case with Microsoft support who have been blaming Antivirus, Nic teaming, etc, but we have now eliminated all of those and still have the issues.  The servers have lots of resources (78GB of RAM and 4 way quad core Xeon processors in the SQL boxes).

    I'd appreciate any thoughts or suggestions,

     

    Dave

All Replies

  • Wednesday, November 09, 2011 2:50 AM
    Moderator
     
     

    Hi DL-Xylotek,

    As you mentioned there is no error log in SQL Server, seems to be not SQL Server issue.

    Based on your description, it might be related to the BizTalk 2009 problem.  So please link to BizTalk forum,  then you can get much help there.

    Meanwhile please refer these articles, which might be helpful:
    1. BizTalk Server 2009 Installation and Upgrade Guides

    2. Considerations for Installing BizTalk Server on a Windows Server Cluster

    3. How to Configure a BizTalk Host as a Cluster Resource


    Regards, Amber zhang
  • Wednesday, November 16, 2011 6:46 PM
     
     

    Microsoft support would disagree with you as would some packet captures we have done.  We can see the traffic coming into the SQL server at the TCP layer it is then promptly ignored by SQL.  Still working with Microsoft support to figure out why.  Very good of the moderator to make this as answered without giving me a chance to reply.

     

  • Thursday, November 17, 2011 7:05 AM
    Moderator
     
     Proposed
    Hi DL-Xylotek,

    I do apologize for that.

    Based on my research, when rebooting the computer the BizTalk Server just hangs and there are no error logged as you mentioned. This might be because of TCP/IP changes in Windows Server 2003 and later. More information, please refer to this KB with the samilar scenario as yours.

    Please following the steps in the RESOLUTION section in this KB, and then restart your computer after implementing the changes above.

    Any problem, please don’t hesitate to let me know. 

    Regards, Amber zhang
  • Friday, December 02, 2011 9:36 AM
     
     

    I am seeing exactly the same issue on a SQL Server 2008 R2 running on Windows Server 2008 R2.

    There are five (5) TCP retransmits and a reset.  Prior to that, there were some keep-alives too.  None of them are ACK'd after the last TDS response packet was ACK'd.  There's around 5 seconds between the last command and the new command being sent.

    The network traffic gets from the BizTalk server to the SQL server, but it's ignord.  Turned off TCP checksum offloading, chimney and RSS.  Has not helped.

    Have you had any luck/updates from MS?

  • Tuesday, March 13, 2012 11:01 AM
     
     

    I am having the same issue

    SQL Server 2008 clustered

    Does anyone know the reasons for this and resolutions

    regards

    Arun

  • Thursday, June 07, 2012 3:11 PM
     
     

    We are still researching this with Microsoft after upgrading (and upgrading again) NIC drivers, dissolving teaming, etc. 

    There was a suggestion to change the SQL client in BizTalk but it's "baked in" and cannot be changed.

    We're all at a loss and the case remains open (and active) with them...

    • Proposed As Answer by Richard Carde Friday, September 14, 2012 6:40 PM
    • Unproposed As Answer by Richard Carde Friday, September 14, 2012 6:40 PM
    • Proposed As Answer by Richard Carde Friday, September 14, 2012 6:42 PM
    • Unproposed As Answer by Richard Carde Friday, September 14, 2012 6:42 PM
    •  
  • Friday, September 14, 2012 6:42 PM
     
     Proposed
    For anyone researching this issue, we finally resolved it by ensuring only IPv4 was active on the cluster resource and heartbeat NICs.

    -- Richard Carde

    • Proposed As Answer by Richard Carde Friday, September 14, 2012 6:42 PM
    •