it-swarm.com.de

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

Beim Versuch, eine Verbindung zu einer SQL Server 2012-Instanz über TCP using Windows Authentication 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, werden Abfragen schnell ausgeführt. Das Problem tritt nicht auf, wenn ich eine Verbindung mit 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 am Windows 7-Computer eines Kollegen anmeldete und über dasselbe VPN eine Verbindung mit demselben SQL Server herstellte, gab es keine Verzögerung. Als sich derselbe Mitarbeiter mit seinem eigenen Domain-Konto bei meinem PC anmeldete, trat die Verzögerung auf. Diese Tests zeigen, dass das Problem tritt nur bei meinem PC auf. 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:

  • Antivirus und Firewall deaktiviert
  • Der Ordner "12.0" wurde unter "% Benutzerprofil%\AppData\Roaming\Microsoft\SQL Server Management Studio" in "_12.0" umbenannt, um SSMS zu zwingen, meine Benutzereinstellungen neu zu erstellen.
  • Erzwingen Sie das Netzwerkprotokoll auf TCP anstatt auf <default>. Ich habe auch Named Pipes ausprobiert, aber mein Server ist dafür nicht eingerichtet.
  • Installierte SSMS 2012 und versuchte dies anstelle von 2014.
  • IPv6 deaktiviert
  • Blackholed crl.Microsoft.com auf 127.0.0.1 in meiner Datei etc\hosts.
  • Deaktiviert das Programm zur Verbesserung der Kundenerfahrung in SSMS, Visual Studio und Windows.
  • Deinstallierte alle SQL Server-bezogenen Apps von meinem PC und installierte sie erst 2012 neu.

TCPView-Hinweise:

  • Bei der Verwendung von TCPView ist mir aufgefallen, dass beim Herstellen einer neuen Verbindung der Status sofort hergestellt wird. Dann werden ein oder zwei weitere Verbindungen mit dem SQL Server kontinuierlich 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 schlagen sie fehl? (Ich habe keine Addons in meinem SSMS.)

Irgendwelche Ideen?

pdate: Intellisense/Autocomplete-Hinweis (?) :

Ich habe festgestellt, dass Intellisense/Autocomplete nach dem endgültigen 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.

24
Jordan Rieger

Versuchen Sie, einen Trace mit SQL Profiler auszuführen, während Sie und dann Ihr Mitarbeiter 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 Verbindung über IP herstellen, wird möglicherweise eine Reverse-DNS-Suche durchgeführt. Wenn ja, fügen Sie einen Eintrag in Ihre Hosts-Datei ein.

20
d-_-b

Was Sie zuerst überprüfen sollten, sind die DNS-Einstellungen Ihres Servers oder Clients

Es ist nicht selten, dass Ihr SQL Server Probleme beim Herstellen einer 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 zu DC herstellt, um die Anmeldeinformationen zu überprüfen und zu überprüfen), wird versucht, den öffentlichen DNS anstelle des DNS-Servers des zu kontaktieren AD. Da diese Informationen nicht im öffentlichen DNS gespeichert sind, kann sie nicht überprüft werden. Dies führt zu einer Verzögerung, bis der richtige DNS-Server oder DC über den NTLM) kontaktiert werden kann

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

Feuern Sie den Befehl IPConfig.exe/all vom cmd ab, um die 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.

5
NikolaD

Ich verlängerte C:\Windows\System32\drivers\etc\hosts Datei durch Hinzufügen einer Zeile wie folgt:

201.202.203.204     mysqlserver

201.202.203.204 ist die IP-Adresse Ihres SQL Servers.

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

Dies hat meinen Server schneller gemacht.

Vielen Dank an: d -_- b, Jordanien, Rieger, felickz, RobbZ

0
Dennis Gorelik

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

  • Starten Sie Powershell
  • Lauf 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 False um es auszuschalten.

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 diese auch weglassen.

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

0
Laszlo Mako