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.
  • 4
    Broadcom? KILL, KILL, KILL! – Mark Storey-Smith Mar 21 '13 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 '13 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 '13 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 '13 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 '13 at 1:58
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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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