SQL Server Management studio powolne połączenie lub przekroczenie limitu czasu podczas korzystania z uwierzytelniania systemu Windows

23

Dostaję bardzo długie opóźnienia (10 ~ 30 sekund) w SQL Server Management Studio 2014, gdy próbuję połączyć się z wystąpieniem SQL Server 2012 przez TCP przy użyciu uwierzytelniania systemu Windows . Dzieje się tak po podłączeniu Eksploratora obiektów lub nowego pustego okna zapytania. Po połączeniu uruchamianie zapytań jest szybkie. Problem nie występuje, gdy łączę się przy użyciu uwierzytelniania programu SQL Server.

Środowisko:

Windows 7, zalogowany jako użytkownik domeny
Połączenie TCP przez adres IP (nie nazwa hosta)
Serwer znajduje się w zdalnej lokalizacji połączonej przez VPN
Bez szyfrowania

Kiedy zalogowałem się do komputera z systemem Windows 7 współpracownika za pomocą mojego konta domeny i połączyłem się z tym samym programem SQL Server za pośrednictwem tej samej sieci VPN, nie było opóźnienia. Gdy ten sam współpracownik zalogował się na moim komputerze za pomocą własnego konta domeny, doświadczył opóźnienia. Te testy pokazują, że problem występuje tylko na moim komputerze. Problem pojawia się także tylko podczas łączenia się z tym konkretnym serwerem SQL Server i VPN; Mogę połączyć się z innymi serwerami SQL w sieci lokalnej za pomocą uwierzytelniania systemu Windows bez żadnych opóźnień.

Rzeczy, których próbowałem bezskutecznie:

Wyłączono antywirusa i zaporę ogniową
Zmieniono nazwę folderu „12.0” w „% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio” na „_12.0”, aby wymusić na SSMS odtworzenie moich ustawień użytkownika.
Wymuś protokół sieciowy na TCP zamiast <default>. Próbowałem też potoków nazwanych, ale mój serwer nie jest do tego skonfigurowany.
Zainstalowałem SSMS 2012 i wypróbowałem to zamiast 2014.
Wyłączone IPv6
Blackholed crl.microsoft.com do 127.0.0.1 w moim pliku etc \ hosts.
Wyłączono program poprawy jakości obsługi klienta w SSMS, Visual Studio i Windows.
Odinstalowałem wszystkie aplikacje związane z SQL Server z mojego komputera i ponownie zainstalowałem w 2012 roku.

Wskazówki TCPView:

Za pomocą TCPView zauważyłem, że kiedy nawiązuję nowe połączenie, jego stan natychmiast staje się USTAWIONY, ale następnie jedno lub dwa kolejne połączenia z SQL Server są ciągle próbowane i zamykane za pomocą TIME_WAIT . Na komputerze mojego współpracownika połączenia są USTALONE i solidne. Jestem więc prawie pewien, że to jest przyczyna przekroczenia limitu czasu, ale po co są połączenia i dlaczego zawodzą? (Nie mam żadnych dodatków w moim SSMS.)

Jakieś pomysły?

Aktualizacja: Intellisense / Autouzupełnianie wskazówka (?):

Zauważyłem, że kiedy w końcu się połączę, Intellisense / Autocomplete nie działa. Czy wymagają one oddzielnych połączeń z SSMS? Próbowałem je wyłączyć, ale wydawało się, że nie rozwiązało to dużego opóźnienia połączenia.

— Jordan Rieger
źródło

Czy próbowałeś uruchomić SSMS z przełącznikiem / log?

— Mister Magoo,

@MisterMagoo próbuje tego teraz. W rzeczywistości nie rejestruje niczego na temat prób połączenia (plik nie powiększa się podczas nawiązywania nowego połączenia). Chodzi głównie o ładowanie niektórych pakietów w interfejsie użytkownika, np. „Pomyślnie załadowano zestaw komponentów z pamięci podręcznej”. Nie mogłem znaleźć żadnych błędów ani wyjątków.

— Jordan Rieger,

Ok, nie byłem pewien, czy tak będzie, ale pomyślałem, że warto było spróbować szybko. Jeśli naprawdę interesujesz się tym, co się dzieje, być może będziesz musiał przełamać Sysinternals Process Monitor i sprawdzić, czy możesz zidentyfikować, co się dzieje. technet.microsoft.com/en-us/library/bb896645.aspx

— Mister Magoo

Zajmuję się zrzutami ProcMon od około godziny, ale jest tak wiele zdarzeń (nawet przefiltrowanych do Ssms.exe), że nie mogę z tego wiele zrobić.

— Jordan Rieger,

@MisterMagoo Wszystko, co widzę, to to, że próby połączenia, które widziałem za pomocą TcpView, rzeczywiście zajmują dużo czasu (ponad 5 sekund każdy). Opieram się na tym, że po zobaczeniu zdarzenia „TCP Connect” na określonym porcie lokalnym, a następnie następnym razem widzę, że cokolwiek wysłanego lub odebranego na tym porcie lokalnym jest zawsze po co najmniej 5 sekundach.

— Jordan Rieger,

19

Spróbuj uruchomić śledzenie za pomocą SQL Profiler, a Ty, a następnie współpracownik, połączysz się z serwerem.
Wybierz RPC, Instrukcja SQL i PreConnect - Rozpoczęcie / Zakończone.
Wybierz opcję Zapisz wyniki w tabeli, a następnie porównaj 2 tabele, aby znaleźć wąskie gardło.

Lub, ponieważ łączysz się przez IP, może to być wyszukiwanie wstecznego DNS. Jeśli tak, dodaj wpis w pliku hosts.

— d -_- b
źródło

2

Dodałem lokalny wpis etc / hosts dla adresu IP mojego serwera, a następnie spróbowałem ponownie SSMS. Bingo! Super szybko. Dziękuję Ci! (Opuściłem SSMS łącząc się za pomocą adresu IP jak poprzednio, a nie nazwy hosta.) Zastanawiam się tylko, dlaczego potrzebuję tego obejścia, ale moi współpracownicy nie. To wydaje się być związane z DNS. W każdym razie jest to dla mnie całkiem dobre rozwiązanie, więc przyznam ci nagrodę, gdy tylko zaktualizujesz swoją odpowiedź.

— Jordan Rieger

Myślę, że było to wyszukiwanie wsteczne, ponieważ po usunięciu wpisu hostów polecenie ping - a ###. ###. ###. ### było bardzo wolne przed pierwszym pingiem (wstrzymane 5 sekund na wyszukiwanie wsteczne). Po dodaniu z powrotem wpisu hosta polecenie ping -a było szybkie. Nie było jednak różnicy w tracert ani nslookup. Wydaje mi się, że na moim komputerze musi być coś innego, co zmusza mnie do wyszukiwania wstecznego, gdy moi współpracownicy nie są (lub są po prostu znacznie szybsi). BTW, moja Intellisense znów działa, gdy szybkość połączenia jest duża.

— Jordan Rieger

Nawet fałszywy wpis DNS dla adresu IP w pliku hosts sprawia, że działa to znacznie szybciej! Dziękuję Ci!

— felickz

Miałem limit czasu, próbując połączyć SSMS przez VPN, dopóki nie przeczytałem twojej odpowiedzi, tak, to ma sens, ponieważ łączyłem się z serwerem przez IP i rozpoznawanie nazw nie działało. Dodanie wpisu do pliku hosta w końcu sprawiło, że działał on po wielu godzinach próbując go uruchomić. Dzięki! W przypisie chcę powiedzieć, że używam uwierzytelniania systemu Windows z różnych domen za pomocą run / netonly i działa dobrze z tym rozwiązaniem.

— RobbZ

5

To, co powinieneś najpierw sprawdzić, to ustawienia DNS serwera lub klienta

Często zdarza się, że Twój SQL Server ma problem z połączeniem się z Active Directory. Jeśli spróbujesz użyć lokalnego konta Windows, jestem pewien, że problem nie wystąpi. Nie jest niczym niezwykłym, że serwer jest skonfigurowany z publicznym internetowym DNS, a gdy SQL Server łączy się z DC w celu sprawdzenia poświadczeń i weryfikacji, spróbuje skontaktować się z publicznym DNS zamiast z serwerem DNS AD. Ponieważ te informacje nie są przechowywane w publicznym DNS, nie uda się to zweryfikować, co spowoduje opóźnienie, dopóki nie uda się skontaktować z właściwym serwerem DNS lub DC za pośrednictwem NTLM

Ponieważ nie występuje problem z innymi serwerami SQL, prawie na pewno problem nie jest związany z konfiguracjami AD lub DC

Ogień Ipconfig.exe / all polecenie cmd, aby sprawdzić skonfigurowane serwery DNS. Powinieneś mieć skonfigurowane tylko serwery DNS AD. Usuń wszystkie publiczne serwery DNS i pozostaw tylko serwery DNS AD.

— NikolaD
źródło

Czy sugerujesz, że SQL Server kontaktuje się z publicznym DNS w celu wyszukania adresu IP kontrolera domeny, a to powoduje opóźnienie, gdy próbuje zweryfikować moje uwierzytelnienie systemu Windows? Jeśli tak jest, dlaczego miałoby to działać dobrze z komputera mojego współpracownika w tej samej sieci lokalnej, przez tę samą sieć VPN? Sprawdziłem ustawienia DNS na moim komputerze i był jeszcze trzeci serwer DNS, o który poprosił mnie mój dział IP, który nie był obecny na komputerze mojego współpracownika. Ale kiedy usunąłem ten serwer, wykonałem ipconfig / flushdns i spróbowałem ponownie, nadal było to wolne.

— Jordan Rieger

Użycie adresu IP lub nazwy FQDN serwera (nie tylko nazwy hosta) sprawiło mi ogromną trudność. Był zdecydowanie powolny problem DNS w moim przypadku.

— userSteve

0

Rozszerzyłem C:\Windows\System32\drivers\etc\hostsplik, dodając taką linię:

201.202.203.204     mysqlserver

201.202.203.204 to adres IP twojego SQL Server.

mysqlserver - dowolna nazwa, którą lubisz (nigdzie nie musisz jej używać).

To przyspieszyło mój serwer.

Podziękowania dla: d -_- b, Jordan, Rieger, felickz, RobbZ

— Dennis Gorelik
źródło

0

Wyłącz Zaporę systemu Windows na serwerze SQL dla profilu sieci domeny.

Uruchom PowerShell
Uruchom, Get-NetFirewallProfile -Profile Domainaby sprawdzić jego bieżący stan
Jeśli jest włączony, uruchom: Set-NetFirewallProfile -Profile Domain -Enabled Falseaby go wyłączyć.

Jeśli tak, możesz włączyć go później i dostosować ustawienia. Lub, jeśli jesteś w bezpiecznym środowisku, możesz to wyłączyć.

Dziwne jest to, że nawet jeśli Zapora systemu Windows blokuje komunikację, nadal będziesz mógł się połączyć, ale zarówno początkowy uścisk dłoni, jak i kolejne żądania będą niesamowicie wolne. Moja teoria (oparta na braku prawdziwych dowodów) jest taka, że w tych przypadkach komunikacja opiera się na nazwanych potokach, co jest znacznie wolniejsze między zdalnymi komputerami.

— Laszlo Mako
źródło