7

I am seeing the following error in SSMS (server has Windows Server 2008 and Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 installed) when running some queries against the linked server, in particular long running queries.

Simple selects from tables across the linked server work fine. This is a new issue that was noticed when SPs that have worked for years started failing.

I have run a Wireshark capture on the server, capturing for packets to port 1433 on the linked server host. At the tail of the capture, I see many (10) TCP Keep-Alives being issued (after a message regarding bad checksum) and then an RST packet. The RST packet is correlated with the error below being returned to the client.

There are other database servers on our network, where the linked server is configured identically, that don't exhibit this issue.

I have found some articles such as this and this. We are using the implicated Broadcom NICs. The Chimney Offload State setting is enabled on the server.

We will try disabling. Other thoughts on troubleshooting would be much appreciated.

OLE DB provider "SQLNCLI10" for linked server "myServer" returned message "Protocol error in TDS stream".
OLE DB provider "SQLNCLI10" for linked server "myServer" returned message "Communication link failure".
Msg 65535, Level 16, State 1, Line 0
Session Provider: Physical connection is not usable [xFFFFFFFF]. 
OLE DB provider "SQLNCLI10" for linked server "myServer" returned message "Communication link failure".
Msg 65535, Level 16, State 1, Line 0
Session Provider: Physical connection is not usable [xFFFFFFFF]. 
OLE DB provider "SQLNCLI10" for linked server "myServer" returned message "Communication link failure".
Msg 64, Level 16, State 1, Line 0
TCP Provider: The specified network name is no longer available.
Improve this question
5
  • 4
    Broadcom? KILL, KILL, KILL!
    – Mark Storey-Smith
    Mar 21, 2013 at 0:07
  • 1
    Yes, I agree. At my previous job we had all kinds of problems with Broadcom NICs. Funny thing, without any other configuration changes, when we swapped them out (for Intel cards I'm fairly certain), all of these problems vanished immediately. Linked servers still suck in general, but getting rid of Broadcom will ease some of that pain. Oh and also why are you still on RTM? Please apply SP2.
    – Aaron Bertrand
    Mar 21, 2013 at 0:29
  • 1
    Also take a look at network packet size and try to track the bad checksum - checksum of WHAT exactly?
    – Aaron Bertrand
    Mar 21, 2013 at 0:31
  • 1
    "Do your servers have Broadcom NICs?" should be on the standard list of questions a DBA candidate asks a potential employer. You need to factor in danger money to the package offered.
    – Mark Storey-Smith
    Mar 21, 2013 at 0:47
  • Thanks both, this does seem pervasive. I will add any additional findings/resolutions to this question. We will apply SP2 ASAP, I am starting to be embarrassed posting the @@version ;)
    – slachterman
    Mar 21, 2013 at 1:58

1 Answer 1

Reset to default
2

We disabled TCP Chimney Offload per the Symantec article and rebooted the servers and the issue appears to be resolved.

The problematic SPs are no longer throwing the communication link failure exception.

More info from Microsoft on TCP Offloading

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.