Как вы справляетесь с ошибками транспортного уровня в SqlConnection?

Question

Время от времени в крупномасштабном .NET-приложении вы можете увидеть это исключение при попытке выполнить запрос:

System.Data.SqlClient.SqlException: ошибка транспортного уровня имеет произошло при отправке запроса на сервер.

Согласно моим исследованиям, это то, что "просто происходит", и мало что можно сделать, чтобы предотвратить это. Это не происходит в результате неправильного запроса и, как правило, не может быть продублировано. Он может возникать один раз в несколько дней в загруженной системе OLTP, когда по какой-то причине порт TCP с базой данных перестает работать.

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

У кого-нибудь есть альтернативные решения?

Answer 1

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

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

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

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

Answer 2

Это сообщение в блоге от Майкл Аспенгрен объясняет сообщение об ошибке «Ошибка транспортного уровня при отправке запроса на сервер».

Answer 3

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

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

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

Answer 4

использование Enterprise Services с транзакционными компонентами

Answer 5

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

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

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

Удачи.

Answer 6

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

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

Answer 7

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

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

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

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

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

Answer 8

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

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

---

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

---

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

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

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

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

Answer 9

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

Answer 10

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

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

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