SQL Server Management Studio повільне підключення або час очікування під час використання автентифікації Windows

У мене вкрай великі затримки (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.

Те, що я намагався успішно:

• Вимкнено антивірус та брандмауер
• Перейменовано папку "12.0" у розділі "% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio" на "_12.0", щоб змусити SSMS відтворити мої налаштування користувача.
• Примушуйте мережевий протокол до TCP, а не <default>. Я також спробував названі труби, але мій сервер не налаштований на це.
• Встановив SSMS 2012 і спробував це замість 2014 року.
• Інвалід IPv6
• Blackholed crl.microsoft.com до 127.0.0.1 у моєму файлі etc \ hosts
• Вимкнено програму вдосконалення клієнтського досвіду в SSMS, Visual Studio та Windows.
• Видалено всі програми, пов’язані з SQL Server, з мого ПК та перевстановлено лише у 2012 році.

TCPView підказки:

• Використовуючи TCPView, я помітив, що коли я встановлюю нове з'єднання, його стан відразу встановлюється ВСТАНОВЛЕНО, але потім одне або два більше з'єднання з SQL сервером постійно намагаються і закриваються TIME_WAIT . На комп’ютері мого колеги ці зв’язки встановлені та міцні. Тож я впевнений, що це джерело таймаутів, але для чого потрібні з'єднання, і чому вони виходять з ладу? (У мене в SSMS немає додаткових добавок.)

Якісь ідеї?

Оновлення: Intellisense / Autocomplete ключ (?):

Я помітив, що як тільки я нарешті підключуюся, Intellisense / Autocomplete не працює. Чи потрібні окремі з'єднання від SSMS? Я спробував їх відключити, але, здається, це не вирішило тривалу затримку з'єднання.

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

Або, оскільки ви підключаєтесь по IP, це може робити зворотний пошук DNS. Якщо так, додайте запис у файл хостів.

Слід спочатку перевірити налаштування DNS вашого сервера чи клієнта

Не рідкість у вашого SQL-сервера проблеми з підключенням до Active Directory. Якщо ви спробуєте скористатися локальним обліковим записом Windows, я впевнений, що у вас не виникне проблем. Незвичайно, що сервер налаштований на загальнодоступний DNS в Інтернеті, і коли SQL Server підключиться до DC, щоб перевірити облікові дані та перевірити їх, він спробує звернутися до загальнодоступного DNS замість DNS-сервера AD. Оскільки ця інформація не зберігається на загальнодоступному DNS, її не вдасться перевірити, і це спричинить затримку, поки їй не вдасться зв’язатися з належним сервером DNS або постійним струмом через NTLM

Оскільки у вас не виникає проблем з іншими серверами SQL, майже напевно проблема не пов’язана з конфігураціями AD або DC

Запустіть команду IPConfig.exe / all з cmd, щоб перевірити налаштовані сервери DNS. У вас повинен бути налаштований лише DNS-сервери AD. Видаліть усі загальнодоступні сервери DNS та залиште лише DNS-сервери AD.

Я розширив C:\Windows\System32\drivers\etc\hostsфайл, додавши такий рядок:

201.202.203.204     mysqlserver

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

mysqlserver - будь-яке ім’я, яке вам подобається (не потрібно його використовувати ніде).

Це зробило мій сервер швидшим.

Дякуємо: d -_- b, Jordan, Rieger, felickz, RobbZ

Вимкніть брандмауер Windows на своєму SQL-сервері для профілю мережі Домен.

• Почніть Powershell
• Запустіть, Get-NetFirewallProfile -Profile Domainщоб перевірити його поточний стан
• Якщо це ввімкнено, запустіть: Set-NetFirewallProfile -Profile Domain -Enabled Falseщоб вимкнути його.

Якщо це було все, ви можете ввімкнути його пізніше і точно налаштувати налаштування. Або якщо ви перебуваєте в безпечному середовищі, можете залишити його.

Дивна річ у тому, що навіть якщо брандмауер Windows блокує зв’язок, ви все одно зможете підключитися, але і початкове рукостискання, і наступні запити будуть надзвичайно повільними. Моя теорія (заснована на відсутніх реальних доказів) полягає в тому, що в цих випадках зв’язок відновлюється на Named Pipes, що набагато повільніше між віддаленими ПК.