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

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

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

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

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

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

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

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

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

использование корпоративных служб с транзакционными компонентами

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

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

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

удачи.

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

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

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

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

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

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

Моим последним средством было использовать старую поговорку "Try and try again". Поэтому я вложил операторы try-catch, чтобы гарантировать, что если соединение TCP/IP потеряно в Нижнем протоколе связи,то он не просто сдается, но пытается снова. Теперь это работает для меня, однако это не очень элегантное решение.

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

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

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

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

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

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

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

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

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