SQL Server: "соединение было успешно установлено с сервером... существующее соединение было принудительно закрыто удаленным хостом".

Ответ 1

На всякий случай, если кто-то еще столкнется с этой проблемой, мы, наконец, нашли решение.

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

Наши ИТ-гуру нашли настройку конфигурации, которая в конечном итоге устранила эту проблему.

Я считаю, что там есть параметр, чтобы отключить сжатие результатов SQL Server (или что-то в этом роде). Это исправило это для нас.

Ответ 2

Это может быть любое количество сетевых проблем. НИЧЕГО, что предотвращает доступ кода к серверу даже для нескольких миллисекунд, которые требуется для выполнения одного запроса.

это также может быть результатом отказа. Когда мы перешли от одного SQL Server к кластерной среде, мы увидели бы это во время перехода на другой ресурс. В этом случае это оказалось нашим пулом соединений. По сути, кластер SQL имеет контроллер и два сервера позади него. A и B.

Скажите, что наше веб-приложение использует сервер. Просто отлично. Пул соединений создает соединение с обеих сторон. Сервер знает об этом, и веб-приложение знает об этом. Как только кластер перейдет на второй сервер, веб-приложение знает о соединении, но сервер B не работает, поэтому мы получаем ошибку.

Суть в том, что причиной может быть любая возможная причина сетевых проблем. Атаки DOS на сервер, межличностные атаки, перехватывающие и изменяющие трафик. Кто-то ездит по сетевому кабелю, и он разъединяется в гнезде. Вы называете это, если это может вызвать проблему подключения, это может быть причиной.

Ваша проблема также звучит так, как у нас недавно - у нас также есть виртуальная среда с программным обеспечением, которое перемещает виртуальные машины с одного хоста на другой, когда это необходимо для балансировки нагрузки. Каждый раз так часто мы подвергались бомбардировке с той же ошибкой. Оказалось, что проблема связана с драйверами NIC на одном из хостов, поэтому всякий раз, когда VM перемещается на этот конкретный хост, будут возникать ошибки.

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

Ответ 3

У меня такая же проблема, и наше приложение взаимодействует с несколькими базами данных Azure SQL. Я верю (так же, как и вы). У меня нет ошибки в коде С#, чтобы вызвать эту проблему. Мы решили это с помощью простого цикла для цикла, содержащего дополнительные попытки попытаться снова подключиться к Azure SQL, если предыдущая попытка не удалась и затем запустил запрос.

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

    A connection was successfully established with the server,
but then an error occurred during the login process. (provider: TCP
Provider, error: 0 - An existing connection was forcibly closed by the
remote host.)

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

Я должен упомянуть, что мы пробовали много стратегий отладки, чтобы понять это. Сейчас все указывает на доступность базы данных, которую мы пытаемся подключить к i.e: Это происходит, если превышено количество допустимых подключений БД. (или так кажется в это время)

Ответ 4

Пожалуйста, проверьте там, это может быть полезно.

Устранение неполадок: подключение принудительно закрыто

Ответ 5

Моя проблема заключалась в том, что я случайно использовал беспроводную сеть для подключения к нашей сети, потому что кабель Ethernet был неисправен. Это после восстановления SQL Server, запустив Winsock reset, как рекомендовано в других местах...

Ответ 6

Это происходило в нашем коде, когда мы открывали dbconnection для oracle и передавали DBtype как SQL в нашем объекте базы данных.

Ответ 7

в моем случае - ошибка была впервые предложена Microsoft: Клиент подключается к неподдерживаемой версии собственного клиента SQL Server.

Ответ 8

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

Мы обновили родной клиент и конфигурации. Мы смогли подключиться.

ссылка для загрузки собственного клиента - https://www.microsoft.com/en-us/download/confirmation.aspx?id=50402

Ссылка для настройки параметров и дальнейшего устранения неполадок - https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms187005(v=sql.105)

Надеюсь, поможет.

Ура!

Ответ 9

Была такая же проблема. В моем случае это было немного сложнее... Я мог подключиться к "ServerA" с "ServerB" через SSMS, но это не получится с sqlcmd. Ошибка была та же:

Sqlcmd: ошибка: собственный клиент Microsoft SQL Server 11.0: поставщик TCP: существующее соединение было принудительно закрыто удаленным хостом.

Я мог также соединиться с "ServerC" и с SSMS и с sqlcmd. Ниже приведены версии на виртуальных машинах:

ServerA: Microsoft Windows Server 2012 R2 Datacenter / Microsoft SQL Server 2012 (SP3-CU10) (KB4025925) - 11.0.6607.3 (X64) 
ServerB: Microsoft Windows Server 2012 R2 Datacenter / Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
ServerC: Microsoft Windows Server 2012 R2 Datacenter / Microsoft SQL Server 2012 (SP3-CU10) (KB4025925) - 11.0.6607.3 (X64)

В итоге была "неподдерживаемая версия". Я заметил несоответствие "sqlncli11.dll" между ServerC и ServerB, поэтому скопировал его в папку System32. После этого sqlcmd работал как шарм. Ниже были версии в моем случае:

Failed:
FileVersion:      2011.0110.5058.00
ProductVersion:   11.0.5058.0

Worked:
FileVersion:      2011.0110.6607.03
ProductVersion:   11.0.6607.3