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

101

Приложение 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?

Эрик Дж.
источник
1
возможно, вы столкнулись с
pardeepk

Ответы:

93

Оказалось, что 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 установлено значение Да.
Эрик Дж.
источник
Спасибо, это устранило ошибку для меня. Интересно, что все IP-адреса были отключены (раньше их не было). Было бы хорошо знать, что может привести к их отключению, поскольку я не думаю, что в моем случае конфигурация будет изменена вручную ...
Мэтт
Я никогда не отключал вручную свои IPv6-адреса. Мне тоже интересно, как они оказались инвалидами.
Эрик Дж.
По какой-то причине я не могу включить IPv6. В нем говорится, что службу необходимо перезапустить, чтобы изменения вступили в силу, но он никогда не сохраняет значение «Да». Любые подсказки о том, как это сделать
Салман,
5
Я не уверен, что отключение отдельных записей является проблемой, поскольку на вкладке «Протокол» есть переопределение «слушать все», которое сообщает SQL, что нужно прослушивать все IP-адреса. См. Следующую ссылку для документации. msdn.microsoft.com/en-us/library/dd981060.aspx
ShaneH,
2
я вижу такие вещи в Azure, я думаю
tofutim
31

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

Шон Кеон
источник
У меня была такая же проблема, спасибо за разрешение. Я подключался с использованием встроенной безопасности через VPN, и увеличение тайм-аута подключения по умолчанию с 15 до 30 секунд решило проблему для меня.
Mark G
1
У меня возникла эта проблема с SQL 2014 LocalDB после того, как setup.exe установил новое приложение, и процесс запуска пытался создать новую базу данных. Это исправление спасло меня от плевания на манекен - спасибо, Шон!
Скотт
1
Это тоже решило проблему для меня. В моем случае я подключался через VPN и добавлял запись в файл hosts. Проблема возникала только при использовании имени хоста в приложениях SSMS и .NET. При использовании IP-адреса проблемы не возникло.
Дэн
СПАСИБО ЗА ДАННЫЙ ОТВЕТ!
Конрад
17

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

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

И

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

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

maozx
источник
3
Значение параметра TransparentNetworkIPResolution = False. Это новая функция .NET 4.6.1, которая включена по умолчанию. Установка этого значения в false удалит тайм-аут 500 мс, создаваемый этой функцией. Для получения дополнительной информации: blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/…
Jorriss,
Спасибо. Часы исследования этой проблемы. Мне нужно добавить этот ответ в избранное. Комментарий @Jorriss очень помог понять, почему. Однако вы можете обновить свой ответ, указав правильное ключевое слово. У Йоррисса правильная ссылка.
TravisWhidden
5

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

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

введите описание изображения здесь

Помстер
источник
3

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

user270576
источник
2

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

smwikipedia
источник
1
Думаю, это не может быть правильный ответ, потому что вопрос содержит «только иногда». Заблокированный порт не отвечает на этот вопрос.
Magier
2

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

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

Уриил
источник
1

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

введите описание изображения здесь

Мык Агустин
источник
1

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

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

Jignesh
источник
1

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

цепная лестница
источник
0

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

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

Чак Херрингтон
источник
0

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

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

Джон Ливермор
источник
0

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

user3424480
источник
0

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

Хосуэ Затараин Эспиноса
источник
0

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

Рикардо Фонтана
источник
0

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

Роберт Беньи
источник
0

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

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

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

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

Мухаммад Тайяб
источник
0

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

Сайед Ваххаб
источник
0

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

саран
источник
0

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

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

Мохамед
источник
Какие из этих случаев связаны с периодическими ошибками?
RonJohn
Пожалуйста, отредактируйте, чтобы раскрыть принадлежность, это необходимо . Спасибо.
Максимиллиан Лаумейстер
0

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

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

Барри
источник