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

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

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

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

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

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

19.08.2008 17:36:05
Есть ли у вас статистика нагрузки на сервер базы данных, когда эти ошибки генерируются? У вас могут быть проблемы с базой данных, которые вызывают сбой соединения.
John Christensen 19.08.2008 17:41:57
Это не должно происходить даже при большом объеме транзакций. Мы выполняем в среднем 25 000 транзакций в секунду в SQL Server 2005 Standard, и мы не получаем эту ошибку. (Если не происходит сбой кластера, что происходит каждые 12+ месяцев, а не раз в несколько дней.) Без дополнительной информации кажется, что существует проблема с сетью между вашим сервером базы данных и вашими серверами приложений. Можете ли вы опубликовать больше информации?
Portman 22.08.2008 12:27:20
@ Portman, я подозреваю, что это из-за дрянной встроенной сетевой платы Dell, которую я вынужден использовать, поскольку оба моих слота PCIe заняты картами HBA, подключенными к моему DAS. Я перехожу на более крупную машину, чтобы я мог установить (намного) лучше Intel NIC. Как у вас кластеризация со стандартной версией? Это особенность Enterprise Edition.
Eric Z Beard 24.08.2008 01:25:11
кластеризация, доставка журналов и зеркалирование доступны в стандарте. http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
Portman 26.08.2008 20:15:37
Насколько я могу судить, 20 класс - транспортный уровень.
Joshua 19.08.2010 17:20:16
11 ОТВЕТОВ

Вам также следует проверить аппаратное подключение к базе данных.

Возможно, эта ветка будет полезна: http://channel9.msdn.com/forums/TechOff/234271-Conenction-forcbly-closed-SQL-2005/

0
19.08.2008 18:02:42

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

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

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

0
1.10.2008 04:53:59

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

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

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

2
1.10.2008 05:57:49

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

0
1.10.2008 06:05:53

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

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

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

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

9
23.05.2017 12:25:03

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

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

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

Удачи.

1
17.05.2011 13:07:07

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

3
29.01.2010 07:20:21

У меня была такая же проблема, хотя она была с запросами на обслуживание к базе данных 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 в низком протоколе связи он не просто сдается, а пытается снова. Теперь это работает для меня, но это не очень элегантное решение.

0
23.07.2010 15:19:55
Спасибо за ответ. Если вы используете пул соединений, попробуйте вызывать SqlConnection.Recycle () каждые, скажем, 10 минут, чтобы убедиться, что если SQLServer уничтожил соединение, то ваш пул все еще не пытается его использовать. Если это работает, сообщите!
TheLegendaryCopyCoder 26.11.2015 10:57:31

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

1
23.07.2010 15:24:49

Я столкнулся с транспортной ошибкой сегодня утром в 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 года, но она может предоставить немного информации для следующего пользователя.

0
13.03.2014 20:02:34
Я думаю, что проблема здесь заключалась в том, что определитель строки должен быть одним двоичным значением, которое для SQL-сервера было бы записано как 0x0d0a (без второго 0x).
Zastai 5.04.2016 07:13:13
Привет! Это хорошо! Я попробую это позже сегодня вечером!
Phillip Deneka 6.06.2016 21:37:00

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

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

0
24.03.2016 06:28:46