Массовая вставка в SQL Server из гостевой системы VMWare с использованием распределенного коммутатора

Скорее всего, это, скорее всего, не проблема SQL-сервера, но настройка, похоже, влияет только на BULK INSERTS для SQL-серверов.

Недавно мы переместили VM Hardware, и всем гостям, которые были перемещены, были изменены виртуальные коммутаторы со стандартных на распределенные.

Затем я начал получать

Произошла фатальная ошибка при чтении входного потока из сети. Сеанс будет прерван (ошибка ввода: 64, ошибка вывода: 0)

на двух серверах SQL во время операций BULK INSERT. Один из серверов SQL был виртуальной машиной с новой конфигурацией, а другой - физическим сервером. Обе операции BULK INSERT были созданы на виртуальной машине с новой конфигурацией. БОЛЬШАЯ ВСТАВКА не будет выходить из строя каждый раз, это было очень случайно, когда это произойдет.

Когда мы изменили виртуальный коммутатор на стандартный коммутатор вместо распределенного, проблема исчезла.

Я ищу больше объяснения, почему он не работает с распределенным коммутатором вместо разрешения. Я предполагаю, что операция BULK INSERT является последовательной, и с распределенным коммутатором пакеты маршрутизируются через разные хосты, некоторые из которых могут быть более загруженными, чем другие, и поступают на сервер назначения за пределами некоторого порога задержки. (примечание: в журнале событий Windows нет ничего во время ошибок на исходном или конечном сервере)

ОБНОВЛЕНИЕ: оказывается, проблема была из-за NIC. Все наши виртуальные машины были настроены с сетевым адаптером E1000, который функционировал достаточно хорошо на стандартных коммутаторах. Как только мы перешли на распределенные коммутаторы, мы начали видеть проблемы с большими объемами передачи данных, а не только с SQL-запросами. Изменение сетевой карты на VMXNET3, похоже, решило проблему.

Чистая проблема vmware / сети, кажется.

Я предлагаю попытаться найти проблему с подключением клиентов к серверу, который не является SQL (ping или что-то еще). Это поможет вам найти более четкий путь устранения неполадок.

Я бы предложил использовать Wireshark или Microsoft NetMon и анализировать трафик, чтобы увидеть, что здесь происходит. Также может быть связано с функцией разгрузки TCP Chimney, предполагая, что что-то изменилось на уровне NIC:

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

мы столкнулись с этой ошибкой неделю назад. наша сетевая команда, команда безопасности и команда базы данных ищут каждую вещь. В конце исследования мы обнаружили ресурс ошибки. Это устройство IPS. Спросите свою команду безопасности, есть ли какая-либо подпись на устройстве IPS.