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

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

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

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

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

Отвечать на Ваш исходный вопрос:

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

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

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

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

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

Удачи.

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

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

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

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

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

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

Это Post Blog Michael Aspengren Объясняет сообщение об ошибке «Ошибка на уровне транспортировки произошла при отправке запроса на сервер».

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

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