This is mostly likely not a SQL server issue but the setup seems to only be affecting BULK INSERTS to SQL Servers.

We have recently moved VM Hardware and all the guests that were moved had their virtual switches changed from standard to distributed.

I then started receiving

A fatal error occurred while reading the input stream from the network. The session will be terminated (input error: 64, output error: 0)

on a two SQL servers during BULK INSERT operations. One of the SQL servers was a VM with the new configuration and the other was a physical server. Both BULK INSERT operation originated from a VM with the new configuration. The BULK INSERTs would not fail every time, it was very random when it would.

When we changed the virtual switch to be a standard switch instead of a distributed switch the issue goes away.

I am looking for more of an explanation to why it doesn't work with a distributed switch instead of a resolution. My guess would be that the BULK INSERT operation is serial and with a distributed switch the packets are being routed through different hosts, some of which may be busier than others, and are arriving at the destination server beyond some latency threshold. (note: there is nothing in the windows event log at the times of the errors on either the source or destination server)

UPDATE: turns out the issue was due to the NIC. All of our VMs were configured with an E1000 NIC which functioned well enough on standard switches. Once we moved to distributed switches, we started seeing issues with large data transfers, not just sql queries. Changing the NIC to VMXNET3 seems to have resolved the issue.

  • Is VM showing any errors? Jan 18 '13 at 16:55
  • No error on VM guest or host.
    – Bob Klimes
    Jan 29 '13 at 14:38

Pure vmware/networking issue, it appears.

I suggest trying to find a connectivity problem from the clients to the server that is not SQL (ping, or anything). That will help you surface a clearer troubleshooting path.

  • It does appear to be a vmware issue as I can recreate behavior with a large file copy
    – Bob Klimes
    Jan 28 '15 at 20:29

I would suggest using Wireshark or Microsoft NetMon and sniffing the traffic to see what is happening here. Could also be related to the TCP Chimney Offload feature, assuming something has changed at the NIC level:



we have experienced this error a week ago. our network team, security team and database team search every thing. At the end of the researching we have detected the error resource. It is the IPS device. Ask your security team is there any signature on IPS device.

  • Which IPS device? How does your environment compare to that of the asker and how will it solve his problem? Nov 5 '14 at 9:43

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.