SQL Server Management studio медленное соединение или время ожидания при использовании проверки подлинности Windows

23

Я получаю очень большие задержки (10 ~ 30 секунд) в SQL Server Management Studio 2014 при попытке подключиться к экземпляру SQL Server 2012 через TCP с использованием проверки подлинности Windows . Это происходит при подключении обозревателя объектов или нового пустого окна запроса. После подключения выполнение запросов выполняется быстро. Проблема не возникает при подключении с использованием проверки подлинности SQL Server.

Среда:

  • Windows 7, вошел как пользователь домена
  • TCP-соединение через IP-адрес (не имя хоста)
  • Сервер находится в удаленном месте, подключенном через VPN
  • Без шифрования

Когда я вошел в систему на компьютере Windows 7 с моей учетной записью домена и подключился к тому же SQL Server через тот же VPN, задержки не было. Когда тот же сотрудник вошел в мой компьютер со своей учетной записью домена, он испытал задержку. Эти тесты показывают, что проблема уникальна для моего компьютера. Кроме того, проблема появляется только при подключении к этому конкретному SQL Server и VPN; Я могу подключиться к другим серверам SQL в локальной сети через Windows Authentication без каких-либо задержек.

Вещи, которые я пытался безуспешно:

  • Отключены антивирус и брандмауэр
  • Переименовал папку «12.0» в «% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio» в «_12.0», чтобы заставить SSMS воссоздать мои пользовательские настройки.
  • Принудительно использовать сетевой протокол TCP, а не <default>. Я также попробовал Named Pipes, но мой сервер не настроен для этого.
  • Установил SSMS 2012 и попробовал это вместо 2014.
  • Отключенный IPv6
  • Blackholed crl.microsoft.com до 127.0.0.1 в моем файле etc \ hosts.
  • Отключил программу улучшения качества программного обеспечения в SSMS, Visual Studio и Windows.
  • Удалите все приложения, связанные с SQL Server, с моего компьютера и переустановите только в 2012 году.

TCPView подсказки:

  • Используя TCPView, я заметил, что когда я создаю новое соединение, его состояние сразу устанавливается ESTABLISHED, но затем одно или два дополнительных соединения с SQL Server постоянно пытаются и закрываются с помощью TIME_WAIT . На компьютере моего сотрудника эти соединения установлены и надежны. Так что я почти уверен, что это источник тайм-аутов, но для чего нужны соединения и почему они терпят неудачу? (У меня нет никаких дополнений в моей SSMS.)

Любые идеи?

Обновление: подсказка Intellisense / автозаполнения (?):

Я заметил, что, как только я наконец-то подключился, Intellisense / Autocomplete не работает. Требуются ли для этого отдельные соединения от SSMS? Я попытался отключить их, но это, похоже, не помогло решить проблему длительной задержки соединения.

sql-server sql-server-2012 ssms connectivity Джордан Ригер
источник
Вы пытались запустить SSMS с ключом / log?
Мистер Магу
@MisterMagoo пытается это сейчас. На самом деле он ничего не регистрирует о своих попытках подключения (файл не увеличивается при создании нового подключения). Это в основном материал для загрузки определенных пакетов в пользовательском интерфейсе, например, «Успешно загруженная сборка компонента из кэша». Я не мог найти никаких ошибок или исключений.
Джордан Ригер
Хорошо, я не был уверен, что это так, но решил, что стоит попробовать. Если вы действительно заинтересованы в том, что происходит, вам, возможно, придется отключить Sysinternals Process Monitor и посмотреть, сможете ли вы определить, что происходит. technet.microsoft.com/en-us/library/bb896645.aspx
Мистер Магу
Я просматривал дампы ProcMon около часа, но событий так много (даже отфильтровано до Ssms.exe), что я не могу ничего из этого сделать.
Джордан Ригер
@MisterMagoo Все, что я вижу, это то, что попытки подключения, которые я видел с TcpView, действительно занимают много времени (более 5 секунд каждая). Я основываюсь на том, что при появлении события «TCP Connect» на определенном локальном порту, а затем в следующий раз, когда я вижу что-либо отправленное или полученное на этом локальном порту, всегда происходит по крайней мере через 5 секунд.
Джордан Ригер

Ответы:

19

Попробуйте выполнить трассировку с помощью SQL Profiler, пока вы и ваш коллега подключаетесь к серверу.
Выберите RPC, оператор SQL и PreConnect - запуск / завершение.
Выберите опцию Сохранить результаты в таблицу, затем сравните две таблицы, чтобы найти узкое место.

Или, поскольку вы подключаетесь по IP, это может быть обратный поиск DNS. Если это так, добавьте запись в ваш файл hosts.

d -_- б
источник
2
Я добавил локальную запись в etc / hosts для IP-адреса моего сервера, затем снова попробовал SSMS. Бинго! Сверх быстрый. Спасибо! (Я оставил SSMS-соединение, как раньше, по IP-адресу, а не по имени хоста.) Мне просто интересно, зачем мне этот обходной путь, а моим коллегам - нет. Кажется, это связано с DNS. В любом случае, это довольно хорошее решение для меня, поэтому я назначу вам награду, как только вы обновите свой ответ.
Джордан Ригер
Я думаю, что это был обратный поиск, потому что когда я удалял запись хостов, ping - a ###. ###. ###. ### был очень медленным перед первым пингом (для обратного поиска остановился на 5 секунд.) Когда добавили обратно запись хостов, ping -a был быстрым. Там не было никакой разницы в tracert или nslookup, хотя. Я думаю, что что-то должно быть по-другому на моем ПК, что заставляет меня делать обратный поиск, когда мои коллеги не (или это просто намного быстрее их). Кстати, мой Intellisense снова работает теперь, когда скорость соединения высока.
Джордан Ригер
Даже поддельная запись DNS для IP в файле hosts делает эту работу намного быстрее! Спасибо!
felickz
Я получал тайм-ауты, пытаясь подключить SSMS через VPN, пока не прочитал ваш ответ, да, это имеет смысл, потому что я подключался к серверу по IP, а разрешение имен не работало. Добавление записи в файл хоста, наконец, заставило его работать после многих часов попыток заставить это работать. Благодарность! В качестве сноски я хочу сказать, что я использую аутентификацию Windows из разных доменов с помощью runas / netonly, и это решение отлично работает с этим решением.
RobbZ
5

Сначала проверьте настройки DNS вашего сервера или клиента.

Нередко у вашего SQL Server возникает проблема с подключением к Active Directory. Если вы попытаетесь использовать локальную учетную запись Windows, я уверен, что у вас не возникнет проблем. Нередко сервер настроен на использование общедоступной DNS в Интернете, и когда SQL Server подключается к DC, чтобы проверить учетные данные и подтвердить его, он попытается связаться с общедоступным DNS вместо DNS-сервера AD. Поскольку эта информация не хранится в общедоступном DNS, она не будет проверена, и это приведет к задержке, пока ей не удастся связаться с соответствующим DNS-сервером или DC через NTLM.

Поскольку вы не испытываете проблемы с другими серверами SQL, почти наверняка проблема не связана с конфигурациями AD или DC

Запустите команду IPConfig.exe / all из cmd, чтобы проверить настроенные DNS-серверы. У вас должны быть настроены только DNS-серверы AD. Удалите все общедоступные DNS-серверы и оставьте только DNS-серверы AD.

NikolaD
источник
Вы предполагаете, что SQL Server связывается с общедоступным DNS для поиска IP-адреса контроллера домена, и это вызывает задержку, когда он пытается проверить мою аутентификацию Windows? Если это так, почему он будет работать нормально с компьютера моего коллеги в той же локальной сети, через ту же VPN? Я проверил настройки DNS на моем компьютере, и там был дополнительный третий DNS-сервер, который мой отдел IP попросил добавить, который отсутствовал на компьютере моего коллеги. Но когда я удалил этот сервер, сделал ipconfig / flushdns и попытался снова, он все еще работал медленно.
Джордан Ригер
Использование IP-адреса или полного доменного имени сервера (а не только имени хоста) сильно изменило меня. Было определенно медленной проблемой DNS в моем случае.
userSteve
0

Я расширил C:\Windows\System32\drivers\etc\hostsфайл, добавив следующую строку:

201.202.203.204     mysqlserver

201.202.203.204 IP-адрес вашего сервера SQL

mysqlserver - любое имя, которое вам нравится (вам не нужно нигде его использовать).

Это сделало мой сервер быстрее.

Спасибо: d -_- b, Джордан, Ригер, Фелицз, РоббЗ

Денис Горелик
источник
0

Отключите брандмауэр Windows на сервере SQL для сетевого профиля домена.

  • Запустить Powershell
  • Запустите, Get-NetFirewallProfile -Profile Domainчтобы проверить его текущее состояние
  • Если он включен, запустите: Set-NetFirewallProfile -Profile Domain -Enabled Falseчтобы выключить его.

Если это так, вы можете включить его позже и настроить параметры. Или, если вы находитесь в безопасной среде, вы можете оставить это.

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

Ласло Мако
источник