Langsame Verbindung oder Zeitüberschreitung in SQL Server Management Studio bei Verwendung der Windows-Authentifizierung

23

Beim Versuch, mithilfe der Windows-Authentifizierung über TCP eine Verbindung zu einer SQL Server 2012-Instanz herzustellen, treten in SQL Server Management Studio 2014 extrem lange Verzögerungen (10 bis 30 Sekunden) auf . Dies geschieht beim Verbinden des Objekt-Explorers oder eines neuen leeren Abfragefensters. Sobald die Verbindung hergestellt ist, können Abfragen schnell ausgeführt werden. Das Problem tritt nicht auf, wenn ich eine Verbindung mithilfe der SQL Server-Authentifizierung herstelle.

Umgebung:

  • Windows 7, als Domänenbenutzer angemeldet
  • TCP-Verbindung über IP-Adresse (nicht Hostname)
  • Der Server befindet sich an einem Remote-Standort, der über VPN verbunden ist
  • Keine Verschlüsselung

Als ich mich mit meinem Domänenkonto bei einem Windows 7-Computer eines Kollegen angemeldet und über dasselbe VPN mit demselben SQL Server verbunden habe, gab es keine Verzögerung. Als sich derselbe Mitarbeiter mit seinem eigenen Domänenkonto bei meinem PC anmeldete, kam es zu einer Verzögerung. Diese Tests zeigen, dass das Problem nur auf meinem PC auftritt. Außerdem tritt das Problem nur auf, wenn eine Verbindung zu diesem bestimmten SQL Server und VPN hergestellt wird. Ich kann ohne Verzögerung über die Windows-Authentifizierung eine Verbindung zu anderen SQL-Servern im lokalen Netzwerk herstellen.

Dinge, die ich ohne Erfolg versucht habe:

  • Deaktiviert Antivirus und Firewall
  • Der Ordner "12.0" unter "% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio" wurde in "_12.0" umbenannt, damit SSMS meine Benutzereinstellungen neu erstellt.
  • Erzwinge das Netzwerkprotokoll auf TCP anstatt <default>. Ich habe auch Named Pipes ausprobiert, aber mein Server ist nicht dafür eingerichtet.
  • Installierte SSMS 2012 und versuchte das anstelle von 2014.
  • IPv6 deaktiviert
  • Blackholed crl.microsoft.com auf 127.0.0.1 in meiner etc \ hosts-Datei.
  • Deaktivierte das Programm zur Verbesserung der Benutzerfreundlichkeit in SSMS, Visual Studio und Windows.
  • Deinstalliert alle SQL Server-bezogenen Apps von meinem PC und erst 2012 neu installiert.

TCPView Hinweise:

  • Bei der Verwendung von TCPView ist mir aufgefallen, dass beim Herstellen einer neuen Verbindung der Status sofort auf ESTABLISHED gesetzt wird. Anschließend werden ein oder zwei weitere Verbindungen mit dem SQL Server fortlaufend versucht und mit TIME_WAIT geschlossen . Auf dem Computer meines Kollegen sind diese Verbindungen hergestellt und solide. Ich bin mir ziemlich sicher, dass dies die Ursache für die Zeitüberschreitungen ist, aber wozu dienen die Verbindungen und warum scheitern sie? (Ich habe keine Addons in meinem SSMS.)

Irgendwelche Ideen?

Update: Intellisense / Autocomplete Hinweis (?):

Ich habe festgestellt, dass Intellisense / Autocomplete nach dem Herstellen der Verbindung nicht mehr funktioniert. Benötigen diese separate Verbindungen von SSMS? Ich habe versucht, sie zu deaktivieren, und es schien die lange Verbindungsverzögerung nicht zu beheben.

sql-server sql-server-2012 ssms connectivity Jordan Rieger
quelle
Haben Sie versucht, SSMS mit der Option / log auszuführen?
Herr Magoo
@MisterMagoo versuchen das jetzt. Es protokolliert nichts über seine Verbindungsversuche (die Datei wächst nicht, wenn eine neue Verbindung hergestellt wird). Meist geht es darum, bestimmte Pakete in die Benutzeroberfläche zu laden, z. B. "Komponentenassembly erfolgreich aus dem Cache geladen". Ich konnte keine Fehler oder Ausnahmen finden.
Jordan Rieger
Ok, ich war mir nicht sicher, ob das der Fall sein würde, aber ich dachte, es wäre einen kurzen Versuch wert. Wenn Sie wirklich daran interessiert sind, was gerade passiert, müssen Sie möglicherweise Sysinternals Process Monitor auflösen und prüfen, ob Sie erkennen können, was gerade passiert. technet.microsoft.com/en-us/library/bb896645.aspx
Mister Magoo
Ich habe ungefähr eine Stunde lang über ProcMon-Dumps nachgedacht, aber es gibt nur so viele Ereignisse (sogar in Ssms.exe gefiltert), dass ich nicht viel daraus machen kann.
Jordan Rieger
@MisterMagoo Alles, was ich sehen kann, ist, dass die Verbindungsversuche, die ich mit TcpView gesehen habe, in der Tat sehr lange dauern (jeweils über 5 Sekunden). Ich gehe davon aus, dass das "TCP Connect" -Ereignis auf einem bestimmten lokalen Port angezeigt wird und das nächste Mal, wenn ich etwas sehe, das auf diesem lokalen Port gesendet oder empfangen wird, immer nach mindestens 5 Sekunden.
Jordan Rieger

Antworten:

19

Versuchen Sie, eine Ablaufverfolgung mit SQL Profiler auszuführen, während Sie und anschließend Ihr Kollege eine Verbindung zum Server herstellen.
Wählen Sie RPC, SQL-Anweisung und PreConnect - Starten / Abgeschlossen.
Wählen Sie die Option Ergebnisse in Tabelle speichern und vergleichen Sie die beiden Tabellen, um den Engpass zu ermitteln.

Da Sie eine IP-Verbindung herstellen, kann auch eine Reverse-DNS-Suche durchgeführt werden. Wenn ja, fügen Sie einen Eintrag in Ihre hosts-Datei ein.

d -_- b
quelle
2
Ich fügte einen lokalen etc / hosts-Eintrag für die IP-Adresse meines Servers hinzu und versuchte es dann erneut mit SSMS. Bingo! Super schnell. Vielen Dank! (Ich habe SSMS mit der IP-Adresse wie zuvor verbunden, nicht mit dem Hostnamen.) Ich frage mich nur, warum ich diese Problemumgehung benötige, aber meine Kollegen tun dies nicht. Es scheint sich um DNS zu handeln. In jedem Fall ist dies eine ziemlich gute Lösung für mich, daher werde ich Ihnen das Kopfgeld gewähren, sobald Sie Ihre Antwort aktualisiert haben.
Jordan Rieger
Ich denke, es war die umgekehrte Suche, weil, als ich den Host-Eintrag entfernte, Ping - ein ###. ###. ###. ### vor dem ersten Ping sehr langsam war (pausierte 5 Sekunden für die umgekehrte Suche). Als der Host-Eintrag wieder hinzugefügt wurde, war ping -a schnell. Es gab jedoch keinen Unterschied im Tracert oder Nslookup. Ich denke, etwas muss auf meinem PC anders sein, was dazu führt, dass ich die umgekehrte Suche durchführe, wenn meine Kollegen nicht (oder nur viel schneller) sind. Übrigens, mein Intellisense funktioniert jetzt wieder, da die Verbindungsgeschwindigkeit schnell ist.
Jordan Rieger
Selbst ein gefälschter DNS-Eintrag für die IP in der Hosts-Datei beschleunigt die Arbeit erheblich! Vielen Dank!
Felickz
Es kam zu Zeitüberschreitungen beim Versuch, SSMS über ein VPN zu verbinden, bis ich Ihre Antwort gelesen habe. Ja, dies ist sinnvoll, da ich über IP eine Verbindung zum Server hergestellt habe und die Namensauflösung nicht funktioniert hat. Durch das Hinzufügen eines Eintrags in die Host-Datei funktionierte es nach vielen Stunden, in denen versucht wurde, diese Datei zum Laufen zu bringen. Vielen Dank! Als Fußnote möchte ich sagen, dass ich die Windows-Authentifizierung von verschiedenen Domänen mit runas / netonly verwende und dass sie mit dieser Lösung gut funktioniert.
RobbZ
5

Was Sie zuerst überprüfen sollten, sind Ihre Server- oder Client-DNS-Einstellungen

Es ist nicht selten, dass Ihr SQL Server Probleme mit der Verbindung zu Active Directory hat. Wenn Sie es mit einem lokalen Windows-Konto versuchen, bin ich sicher, dass Sie das Problem nicht haben werden. Es ist nicht ungewöhnlich, dass der Server mit öffentlichem Internet-DNS konfiguriert ist. Wenn SQL Server eine Verbindung mit dem Domänencontroller herstellt, um die Anmeldeinformationen zu überprüfen und zu überprüfen, wird versucht, den öffentlichen DNS-Server anstelle des DNS-Servers des AD zu kontaktieren. Da diese Informationen nicht im öffentlichen DNS gespeichert sind, kann sie nicht überprüft werden. Dies führt zu einer Verzögerung, bis die Verbindung zum richtigen DNS-Server oder DC über den NTLM hergestellt wird

Da das Problem bei anderen SQL-Servern nicht auftritt, hängt das Problem mit ziemlicher Sicherheit nicht mit AD- oder DC-Konfigurationen zusammen

Feuer des IPConfig.exe / all Befehls aus dem cmd den konfigurierten DNS - Server zu überprüfen. Sie sollten nur die DNS-Server von AD konfiguriert haben. Entfernen Sie alle öffentlichen DNS-Server und belassen Sie nur die DNS-Server von AD.

NikolaD
quelle
Schlagen Sie vor, dass der SQL Server eine öffentliche DNS-Adresse kontaktiert, um die IP-Adresse des Domänencontrollers abzurufen, und dass dies die Verzögerung verursacht, wenn versucht wird, meine Windows-Authentifizierung zu validieren? Wenn dies der Fall ist, warum funktioniert es dann auf dem PC meines Kollegen im selben lokalen Netzwerk über dasselbe VPN? Ich überprüfte die DNS-Einstellungen auf meinem Computer und es gab einen zusätzlichen dritten DNS-Server, den meine IP-Abteilung hinzufügen wollte, der auf dem PC meines Kollegen nicht vorhanden war. Aber als ich diesen Server entfernte, ipconfig / flushdns ausführte und es erneut versuchte, war es immer noch langsam.
Jordan Rieger
Die Verwendung der IP-Adresse oder des FQDN des Servers (nicht nur des Hostnamens) machte einen großen Unterschied für mich. War definitiv ein langsames DNS-Problem in meinem Fall.
UserSteve
0

Ich erweiterte die C:\Windows\System32\drivers\etc\hostsDatei, indem ich folgende Zeile hinzufügte:

201.202.203.204     mysqlserver

201.202.203.204 ist die IP-Adresse Ihres SQL Servers.

mysqlserver - jeder Name, den Sie mögen (Sie müssen ihn nirgendwo verwenden).

Das hat meinen Server schneller gemacht.

Danke an: d -_- b, Jordan, Rieger, felickz, RobbZ

Dennis Gorelik
quelle
0

Deaktivieren Sie die Windows-Firewall auf Ihrem SQL Server für das Domänennetzwerkprofil.

  • Starten Sie Powershell
  • Führen Sie aus Get-NetFirewallProfile -Profile Domain, um den aktuellen Status zu überprüfen
  • Wenn es aktiviert ist, führen Sie Folgendes aus:, Set-NetFirewallProfile -Profile Domain -Enabled Falseum es zu deaktivieren.

Wenn dies der Fall war, können Sie es später wieder einschalten und Ihre Einstellungen optimieren. Wenn Sie sich in einer sicheren Umgebung befinden, können Sie dies auch auslassen.

Das Seltsame ist, dass Sie auch dann eine Verbindung herstellen können, wenn die Windows-Firewall die Kommunikation blockiert, der anfängliche Handshake und die nachfolgenden Anforderungen jedoch unglaublich langsam sind. Meine Theorie (basierend auf keinen wirklichen Beweisen) ist, dass in diesen Fällen die Kommunikation auf Named Pipes zurückgreift, was zwischen Remote-PCs sehr viel langsamer ist.

Laszlo Mako
quelle