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

— Джордан Ригер
источник

Вы пытались запустить 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 блокирует связь, вы все равно сможете подключиться, но как первоначальное рукопожатие, так и последующие запросы будут невероятно медленными. Моя теория (основанная на отсутствии реальных доказательств) заключается в том, что в этих случаях связь происходит по именованным каналам, что намного медленнее между удаленными ПК.

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