Подключение к SQL Server иногда работает

Приложение ADO.Net только иногда может подключиться к другому серверу в локальной сети. Кажется случайным, успешна данная попытка подключения или нет. Соединение использует строку соединения в форме:

Сервер = THESERVER \ TheInstance; База данных = TheDatabase; Идентификатор пользователя = TheUser; Пароль = Пароль;

возвращается ошибка:

Истекло время ожидания подключения. Время ожидания истекло при попытке использовать подтверждение квитирования перед входом в систему.
Это может быть связано с тем, что квитирование перед входом в систему не удалось или сервер не смог ответить вовремя.
Время, потраченное на попытки подключения к этому серверу, было - инициализация [Pre-Login] = 42030; рукопожатие = 0;

Приложение .NET - это небольшое тестовое приложение, которое выполняет следующий код:

using (SqlConnection conn = new SqlConnection(cs))
using (SqlCommand cmd = new SqlCommand("SELECT COUNT(*) FROM TheTable", conn))
{
    conn.Open();
    int rowCount = (int)cmd.ExecuteScalar();
}

Таблица небольшая, всего 78 строк.

Однако на том же компьютере, где приложение .NET получает эту ошибку, я могу подключиться к THESERVER с помощью SSMS и идентификатора пользователя / пароля, указанного в строке подключения.

Почему может произойти сбой подключения из приложения ADO.Net, но успешный с идентичными учетными данными из SSMS?

Оказалось, что TCP / IP был включен для IPv4-адреса, но не для IPv6-адреса из THESERVER.

Очевидно, некоторые попытки подключения заканчивались использованием IPv4, а другие использовали IPv6.

Включение TCP / IP для обеих версий IP решило проблему.

Тот факт, что SSMS работал, оказался случайным (первые несколько попыток предположительно использовали IPv4). Некоторые последующие попытки подключиться через SSMS привели к тому же сообщению об ошибке.

Чтобы включить TCP / IP для дополнительных IP-адресов:

• Запустите диспетчер конфигурации сервера Sql
• Откройте узел "Сетевая конфигурация SQL Server".
• Щелкните левой кнопкой мыши Протоколы для MYSQLINSTANCE.
• На правой панели щелкните правой кнопкой мыши TCP / IP.
• Щелкните Свойства
• Выберите вкладку IP-адреса.
• Для каждого IP-адреса в списке убедитесь, что для Active и Enabled установлено значение Да.

У меня была такая же ошибка, которая подозрительно совпадала с последним раундом обновлений Microsoft (02.09.2016). Я обнаружил, что SSMS подключается без проблем, в то время как мое приложение ASP.NET возвращало «истекший период тайм-аута при попытке использовать подтверждение квитирования перед входом в систему».

Решение для меня заключалось в том, чтобы добавить тайм-аут соединения 30 секунд в строку подключения, например:

ConnectionString="Data Source=xyz;Initial Catalog=xyz;Integrated Security=True;Connection Timeout=30;"

В моей ситуации единственным затронутым соединением было то, которое использовало интегрированную безопасность, и я выдавал себя за пользователя перед подключением, другие соединения с тем же сервером с использованием аутентификации SQL работали нормально!

2 тестовые системы (отдельные клиенты и серверы Sql) были затронуты одновременно, что заставило меня подозревать обновление Microsoft!

Я решил проблему, как Эрик, но с некоторыми другими изменениями:

• Запустите диспетчер конфигурации сервера Sql
• Откройте узел "Сетевая конфигурация SQL Server".
• Щелкните левой кнопкой мыши Протоколы для MYSQLINSTANCE.
• На правой панели щелкните правой кнопкой мыши TCP / IP.
• Щелкните Свойства
• Выберите вкладку IP-адреса.
• Для каждого IP-адреса в списке убедитесь, что для Active и Enabled установлено значение Да.

И

• Для каждого указанного IP-адреса убедитесь, что TCP Dynamic Ports пуст и TCP Port = 1433 (или какой-либо другой порт).
• Откройте брандмауэр Windows и убедитесь, что порт открыт во входящих подключениях.

У меня была та же проблема, когда я пытался подключиться к серверу в локальной сети (через VPN) из Visual Studio при настройке модели данных сущности.
Удалось решить только установкой TransparentNetworkIPResolution=falseв строке подключения. В VS Add Connection Wizard вы можете найти его на вкладке Advanced.

У меня была такая же проблема с рукопожатием при подключении к размещенному серверу.

Я открыл центр управления сетями и общим доступом и включил IPv6 в своем беспроводном сетевом подключении.

Мой исполняемый файл, созданный с использованием .NET Framework 3.5, начал сообщать об этих проблемах с подключением примерно в половине случаев после того, как недавно были установлены некоторые обновления Windows (7 августа 2017 г.).

Сбои подключения были вызваны установкой .NET Framework 4.7 на целевом компьютере (была включена автоматическая установка обновлений Windows) - https://support.microsoft.com/?kbid=3186539

Удаление .NET Framework 4.7 решило проблемы с подключением.

По-видимому, в .Net Framework 4.6.1 есть критическое изменение - TransparentNetworkIPResolution Обновление строки подключения согласно статье также решило проблему без необходимости отката версии платформы.

Я исправил эту ошибку в Windows Server 2012 и SQL Server 2012, включив IPv6 и разблокировав входящий порт 1433.

В нашем случае проблема возникла из-за конфигурации кластера доступности. Чтобы решить эту проблему, нам пришлось установить MultiSubnetFailoverзначение True в строке подключения.

Подробнее на MSDN

У меня была такая же проблема, удалось решить ее, открыв / включив порт 1433 и tcp / ip в диспетчере конфигурации SQL Server, а затем перезапустив сервер

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

Решил, увеличив время ожидания подключения = 30.

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

У меня возникла эта проблема при миграции с SharePoint 2010 на 2013. Я подозревал, что из-за того, что сервер базы данных находится по ту сторону брандмауэра, который не маршрутизирует IP6, он пытался затем использовать IP6 и не смог подключиться к базе данных.

Думаю, проблема решена. Ошибки вроде прекратились. Я просто отключил IP6 (сняв флажок) для сетевого адаптера на серверах SharePoint.

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

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

Решена эта проблема путем блокировки / внесения в черный список IP-адресов, которые пытались взломать учетные записи пользователей. Проверьте свои журналы доступа SQL на предмет большого количества неудачных попыток входа в систему (обычно для учетной записи 'sa').

На мой взгляд, брандмауэр на сервере Windows блокировал порт 1433, который является портом сервера sql по умолчанию. Так что добавление правила для входящих подключений помогло мне.

В моем случае параметр Persist Security Info=trueс пользователем и паролем в строке подключения вызывает проблему. Удаление параметра или установка для falseрешения проблемы.

Прежде чем делать что-либо радикальное, попробуйте сначала перезапустить SQL Server. Может это исправить. Это сделало для меня

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

Панель управления> Программа и компоненты> Средство запуска установки Visual Studio

и нажмите кнопку Еще и выберите Восстановить

После этого я смог получить доступ к моему локальному серверу SQL и работать с локальными базами данных SQL.

У меня была такая же проблема, которая автоматически разрешается после последнего обновления Microsoft Windows, испытывает ли кто-нибудь то же самое?

У меня была точная проблема, я попробовал несколько вариантов, но не работал, наконец перезапустил систему, все работало нормально.

Чтобы отследить ошибку «Истекло время ожидания соединения» , пожалуйста, убедитесь, что:

• Экземпляр ядра СУБД SQL Server запущен и работает.
• Служба обозревателя SQL Server запущена.
• TCP / IP включен.
• Имя сервера введено правильно.
• Нет сетевых проблем, упомянутых в разделе Как проверить подключение экземпляра SQL Server от сервера приложений к серверу базы данных.
• Порт TCP / IP для экземпляра компонента Database Engine не блокируется брандмауэром.
• Клиент и сервер настроены на использование одного и того же сетевого протокола.

Для получения дополнительных сведений см. « Истекло время ожидания подключения». Время ожидания истекло при попытке использовать подтверждение рукопожатия перед входом в систему

Добавление здесь ответа, несмотря на ранее принятый ответ. По моему сценарию подтвердился DNS. В частности, тайм-аут DNS во время рукопожатия перед входом в систему. Изменяя DNS-имя на IP-адрес (или используя запись в файле Hosts), вы обойдете проблему. Хотя ценой потери автоматического разрешения IP.

Например, даже если для тайм-аута строки подключения установлено значение 60 на полную минуту, это все равно произойдет в течение нескольких секунд после попытки. Это наводит на вопрос, почему тайм-аут до указанного периода тайм-аута? DNS.