Ошибка на транспортном уровне при отправке запроса серверу sql

Я отправил ответ на другой вопрос по другой теме, которая может быть использована здесь. Этот ответ включал соединения SMB, а не SQL. Однако он был идентичен, поскольку он касался транспортной ошибки низкого уровня.

Мы обнаружили, что в ситуации с тяжелой нагрузкой удаленному серверу довольно легко отключать соединения на уровне TCP просто потому, что сервер занят. Одной из причин было то, что по умолчанию количество попыток повторной передачи данных в Windows не подходит для нашей ситуации.

Посмотрите параметры реестра для настройки TCP/IP в Windows. В частности, вы хотите посмотреть TcpMaxDataRetransmissions и, возможно, TcpMaxConnectRetransmissions. По умолчанию они равны 5 и 2, попробуйте немного увеличить их в клиентской системе и дублируйте ситуацию загрузки.

Не сойди с ума! TCP удваивает тайм-аут при каждой последующей повторной передаче, поэтому поведение таймаута для плохих соединений может оказаться экспоненциальным, если вы увеличите их слишком много. Когда я вспоминаю, что TcpMaxDataRetransmissions до 6 или 7 решал нашу проблему в подавляющем большинстве случаев.

Tim Farley
16 окт. 2008, в 08:30

Поделиться

Magnus Lindhe
29 янв. 2010, в 09:02

Поделиться

Чтобы ответить на ваш оригинальный вопрос:

Более элегантный способ обнаружить эту конкретную ошибку без разбора сообщения об ошибке — проверить свойство Number SqlException.

(Это фактически возвращает номер ошибки из первого SqlError в коллекции Errors, но в вашем случае транспортная ошибка должна быть единственной в коллекции.)

Daniel Fortunov
01 окт. 2008, в 06:20

Поделиться

Jon Black
23 июль 2010, в 16:03

Поделиться

Я видел это в моей собственной среде несколько раз. Клиентское приложение в этом случае устанавливается на многих машинах. Некоторые из этих машин, как оказалось, являются ноутбуками, которые люди оставляют приложение открытым, отключая его, а затем снова подключая его и пытаясь использовать. Это приведет к ошибке, о которой вы упомянули.

Моей первой точкой было бы посмотреть на сеть и убедиться, что серверы не подключены к DHCP и не обновляют IP-адреса, вызывающие эту ошибку. Если это не так, вам нужно начать трафик через журналы событий, которые ищут другие связанные с сетью.

К сожалению, как указано выше, сетевая ошибка. Главное, что вы можете сделать, это просто следить за соединениями с помощью инструмента, такого как netmon, и работать оттуда.

Удачи.

Dale Wright
31 окт. 2008, в 07:31

Поделиться

Я просто хотел опубликовать исправление, которое работало для нашей компании на новом программном обеспечении, которое мы установили. Мы получили следующую ошибку с первого дня в файле журнала клиента: серверу не удалось обработать запрос. — > При получении результатов с сервера произошла ошибка транспортного уровня. (поставщик: поставщик TCP, ошибка: 0 — период таймаута семафора истек.) — > Срок таймаута семафора истек.

Что было полностью исправлено, проблема заключалась в создании агрегата ссылок (LAG) на нашем коммутаторе. Наш сервер Dell FX1 имеет избыточные линии волокон, выходящие из его задней части. Мы не понимали, что переключатель, к которому они подключены, необходим для настройки LAG на этих двух портах. Подробнее здесь: https://docs.meraki.com/display/MS/Switch+Ports#SwitchPorts-LinkAggregation

J. J.
03 дек. 2015, в 18:01

Поделиться

Сегодня утром в SSMS я столкнулся с транспортной ошибкой при подключении к SQL 2008 R2 Express.

Я пытался импортировать CSV с rn. Я закодировал свой ограничитель строки для 0x0d0x0a. Когда я изменил его на 0x0a, ошибка остановилась. Я могу изменить его взад и вперед и наблюдать, как это происходит/не происходит.

 BULK INSERT #t1 FROM 'C:123Import123.csv' WITH 
      ( FIRSTROW = 1, FIELDTERMINATOR = ',', ROWTERMINATOR = '0x0d0x0a' )

Я подозреваю, что я не пишу свой ограничитель строк правильно, потому что SQL анализирует один символ за раз, пока я пытаюсь передать два символа.

Во всяком случае, этой ошибке сейчас 4 года, но она может предоставить немного информации для следующего пользователя.

Phillip Deneka
13 март 2014, в 20:37

Поделиться

Joshua
19 авг. 2010, в 18:11

Поделиться

У меня была такая же проблема, хотя это было с запросами на обслуживание SQL DB.

Это то, что у меня было в журнале ошибок службы:

System.Data.SqlClient.SqlException: при отправке запроса на сервер произошла ошибка транспортного уровня. (поставщик: поставщик TCP, ошибка: 0 — существующее соединение было принудительно закрыто удаленным хостом.)

У меня есть набор тестов С#, который проверяет службу. Служба и БД были на внешних серверах, поэтому я думал, что это может быть проблемой. Поэтому я развернул службу и базу данных локально безрезультатно. Вопрос продолжился. Набор тестов не является даже серьезным испытанием на производительность, поэтому я понятия не имел, что происходит. Один и тот же тест терпел неудачу каждый раз, но когда я отключил этот тест, другой будет терпеть неудачу непрерывно.

Я пробовал другие методы, предлагаемые в Интернете, которые тоже не работали:

• Увеличьте значения реестра TcpMaxDataRetransmissions и TcpMaxConnectRetransmissions.
• Отключите параметр «Общая память» в диспетчере конфигурации SQL Server в разделе «Клиентские протоколы» и выполните сортировку TCP/IP до 1-го списка.
• Это может произойти, если вы проверяете масштабируемость с большим количеством попыток подключения к клиенту. Чтобы устранить эту проблему, используйте утилиту regedit.exe, чтобы добавить новое значение DWORD с именем SynAttackProtect в раздел реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersсо значениями данных 00000000.

Моим последним прибежищем было использовать старость, говорящую «Попробуй и попробуй еще раз». Поэтому у меня есть вложенные утверждения try-catch, чтобы убедиться, что если TCP/IP-соединение потеряно в нижнем протоколе связи, он просто не сдаётся, а пытается снова. Теперь это работает для меня, однако это не очень изящное решение.

Martin
23 июль 2010, в 17:00

Поделиться

Jesper Blad Jensen
01 окт. 2008, в 07:51

Поделиться

Я использую уровень надежности вокруг своих команд БД (абстрагировался в interforme репозитория). В основном это просто код, который перехватывает любое ожидаемое исключение (исключение DbException, а также InvalidOperationException, которое, как правило, возникает из-за проблем с подключением), регистрирует его, фиксирует статистику и снова пытается повторить все.

С учетом этого уровня надежности службе удалось изящно выдержать стресс-тестирование (постоянные блокировки, сетевые сбои и т.д.). Производство гораздо менее враждебно, чем это.

PS: Здесь больше об этом (наряду с простым способом определения надежности с помощью DSL перехвата)

Rinat Abdullin
01 окт. 2008, в 05:18

Поделиться