Connexion lente ou délai d'attente du studio de gestion SQL Server lors de l'utilisation de l'authentification Windows

23

Je reçois des délais extrêmement longs (10 à 30 secondes) dans SQL Server Management Studio 2014 lorsque j'essaie de me connecter à une instance SQL Server 2012 via TCP à l'aide de l' authentification Windows . Cela se produit lors de la connexion de l'Explorateur d'objets ou d'une nouvelle fenêtre de requête vide. Une fois connecté, l'exécution des requêtes est rapide. Le problème ne se produit pas lorsque je me connecte à l'aide de l'authentification SQL Server.

Environnement:

Windows 7, connecté en tant qu'utilisateur de domaine
Connexion TCP via l'adresse IP (pas le nom d'hôte)
Le serveur est à un emplacement distant connecté via VPN
Pas de cryptage

Lorsque je me suis connecté à l'ordinateur Windows 7 d'un collègue avec mon compte de domaine et que je me suis connecté au même serveur SQL via le même VPN, il n'y a eu aucun retard. Lorsque le même collègue s'est connecté à mon PC avec son propre compte de domaine, il a subi le retard. Ces tests montrent que le problème est propre à mon PC. En outre, le problème n'apparaît que lors de la connexion à ce serveur SQL spécifique et VPN; Je peux me connecter à d'autres serveurs SQL sur le réseau local via l'authentification Windows sans aucun délai.

Des choses que j'ai essayées sans succès:

Anti-virus et pare-feu désactivés
Renommé le dossier «12.0» sous «% userprofile% \ AppData \ Roaming \ Microsoft \ SQL Server Management Studio» en «_12.0» pour forcer SSMS à recréer mes paramètres utilisateur.
Forcer le protocole réseau sur TCP plutôt que <default>. J'ai également essayé Named Pipes mais mon serveur n'est pas configuré pour cela.
Installé SSMS 2012 et essayé cela au lieu de 2014.
IPv6 désactivé
Blackholed crl.microsoft.com à 127.0.0.1 dans mon fichier etc \ hosts.
Désactivé le programme d'amélioration de l'expérience client dans SSMS, Visual Studio et Windows.
Désinstallé toutes les applications liées à SQL Server de mon PC et réinstallé seulement 2012.

Indices TCPView:

À l'aide de TCPView, j'ai remarqué que lorsque j'établis une nouvelle connexion, son état devient IMMÉDIATEMENT établi, mais une ou deux connexions supplémentaires avec SQL Server sont continuellement tentées et fermées avec TIME_WAIT . Sur l'ordinateur de mon collègue, ces connexions sont ÉTABLIES et solides. Je suis donc presque sûr que c'est la source des délais d'attente, mais à quoi servent les connexions et pourquoi échouent-elles? (Je n'ai aucun addon dans mon SSMS.)

Des idées?

Mise à jour: indice Intellisense / Autocomplete (?):

J'ai remarqué qu'une fois que je me suis enfin connecté, Intellisense / Autocomplete ne fonctionne pas. Ceux-ci nécessitent-ils des connexions distinctes de SSMS? J'ai essayé de les désactiver et cela n'a pas semblé résoudre le long délai de connexion.

— Jordan Rieger
source

Avez-vous essayé d'exécuter SSMS avec le commutateur / log?

— Monsieur Magoo

@MisterMagoo essaye ça maintenant. Il n'enregistre en fait rien sur ses tentatives de connexion (le fichier ne s'agrandit pas lors d'une nouvelle connexion). Il s'agit principalement de charger certains packages dans l'interface utilisateur, par exemple "Assemblage de composants correctement chargé à partir du cache". Je n'ai trouvé aucune erreur ou exception.

— Jordan Rieger

D'accord, je ne savais pas si c'était le cas, mais je pensais que cela valait la peine d'essayer rapidement. Si vous êtes vraiment intéressé par ce qui se passe, vous devrez peut-être séparer Sysinternals Process Monitor et voir si vous pouvez identifier ce qui se passe. technet.microsoft.com/en-us/library/bb896645.aspx

— Mister Magoo

Je regarde les vidages ProcMon depuis environ une heure, mais il y a tellement d'événements (même filtrés vers Ssms.exe) que je ne peux pas en faire grand cas.

— Jordan Rieger

@MisterMagoo Tout ce que je peux voir, c'est que les tentatives de connexion que j'ai vues avec TcpView prennent en effet beaucoup de temps (plus de 5 secondes chacune). Je base cela en voyant l'événement "TCP Connect" sur un port local particulier, et la prochaine fois que je vois quoi que ce soit envoyé ou reçu sur ce port local, c'est toujours après au moins 5 secondes.

— Jordan Rieger

19

Essayez d'exécuter une trace avec SQL Profiler pendant que vous, puis votre collègue, vous connectez au serveur.
Sélectionnez RPC, SQL Statement & PreConnect - Démarrage / Terminé.
Sélectionnez l'option Enregistrer les résultats dans le tableau, puis comparez les 2 tableaux pour trouver le goulot d'étranglement.

Ou, comme vous vous connectez par IP, il peut s'agir d'une recherche DNS inversée. Si c'est le cas, ajoutez une entrée dans votre fichier d'hôtes.

— d -_- b
source

2

J'ai ajouté une entrée locale etc / hosts pour l'adresse IP de mon serveur, puis j'ai réessayé SSMS. Bingo! Super rapide. Merci! (J'ai laissé SSMS se connecter via l'adresse IP comme auparavant, pas le nom d'hôte.) Je me demande simplement pourquoi j'ai besoin de cette solution de contournement, mais mes collègues n'en ont pas. Il semble être lié au DNS. En tout cas, c'est une assez bonne solution pour moi, donc je vous accorderai la prime une fois que vous aurez mis à jour votre réponse.

— Jordan Rieger

Je pense que c'était la recherche inversée car lorsque j'ai supprimé l'entrée des hôtes, la commande ping - a ###. ###. ###. ### était très lente avant le premier ping (pause de 5 secondes pour la recherche inversée.) Une fois ajouté à l'entrée des hôtes, le ping -a était rapide. Il n'y avait cependant aucune différence dans le tracert ou le nslookup. Je pense que quelque chose doit être différent sur mon PC qui me fait faire la recherche inversée lorsque mes collègues ne le sont pas (ou c'est juste beaucoup plus rapide sur le leur.) BTW, mon Intellisense fonctionne à nouveau maintenant que la vitesse de connexion est rapide.

— Jordan Rieger

Même une fausse entrée DNS pour l'IP dans le fichier hosts rend ce travail beaucoup plus rapide! Merci!

— felickz

J'obtenais des délais d'attente en essayant de connecter SSMS via un VPN jusqu'à ce que je lise votre réponse, oui, cela a du sens car je me connectais au serveur via IP et la résolution de noms ne fonctionnait pas. L'ajout d'une entrée dans le fichier hôte l'a finalement fait fonctionner après plusieurs heures à essayer de le faire fonctionner. Merci! En tant que note de bas de page, je tiens à dire que j'utilise l'authentification Windows à partir de différents domaines avec les runas / netonly et cela fonctionne très bien avec cette solution.

— RobbZ

5

Ce que vous devez d'abord vérifier, ce sont les paramètres DNS de votre serveur ou client

Il n'est pas rare que votre serveur SQL rencontre des problèmes de connexion à Active Directory. Si vous essayez avec un compte Windows local, je suis sûr que vous n'aurez pas le problème. Il n'est pas inhabituel que le serveur soit configuré avec un DNS Internet public et lorsque SQL Server se connecte à DC pour vérifier les informations d'identification et le vérifier, il essaiera de contacter le DNS public au lieu du serveur DNS de l'AD. Étant donné que ces informations ne sont pas stockées sur le DNS public, elles ne seront pas vérifiées et cela entraînera le retard jusqu'à ce qu'elles parviennent à contacter le serveur DNS ou le contrôleur de domaine approprié via le NTLM.

Étant donné que vous ne rencontrez pas le problème avec d'autres serveurs SQL, il est presque certain que le problème n'est pas lié aux configurations AD ou DC

Feu le IPConfig.exe / all commande à partir du cmd pour vérifier les serveurs DNS configurés. Vous ne devez configurer que les serveurs DNS d'AD. Supprimez tous les serveurs DNS publics et ne laissez que les serveurs DNS d'AD.

— NikolaD
source

Êtes-vous en train de suggérer que SQL Server contacte un DNS public pour rechercher l'adresse IP du contrôleur de domaine, ce qui entraîne un retard lorsqu'il tente de valider mon authentification Windows? Si tel est le cas, pourquoi cela fonctionnerait-il bien depuis le PC de mon collègue sur le même réseau local, sur le même VPN? J'ai vérifié les paramètres DNS sur mon ordinateur et il y avait un troisième serveur DNS supplémentaire que mon service IP m'avait demandé d'ajouter, qui n'était pas présent sur le PC de mon collègue. Mais quand j'ai supprimé ce serveur, fait un ipconfig / flushdns et réessayé, c'était toujours lent.

— Jordan Rieger

L'utilisation de l'adresse IP ou du nom de domaine complet du serveur (pas seulement le nom d'hôte) a fait une énorme différence pour moi. Était certainement un problème DNS lent dans mon cas.

— userSteve

0

J'ai étendu le C:\Windows\System32\drivers\etc\hostsfichier en ajoutant une ligne comme celle-ci:

201.202.203.204     mysqlserver

201.202.203.204 est l'adresse IP de votre serveur SQL.

mysqlserver - n'importe quel nom que vous aimez (vous n'avez pas besoin de l'utiliser n'importe où).

Cela a rendu mon serveur plus rapide.

Merci à: d -_- b, Jordan, Rieger, felickz, RobbZ

— Dennis Gorelik
source

0

Désactivez le pare-feu Windows sur votre serveur SQL pour le profil réseau de domaine.

Démarrer Powershell
Exécuter Get-NetFirewallProfile -Profile Domainpour vérifier son état actuel
S'il est activé, exécutez: Set-NetFirewallProfile -Profile Domain -Enabled Falsepour le désactiver.

Si tel est le cas, vous pouvez le réactiver plus tard et affiner vos paramètres. Ou, si vous êtes dans un environnement sûr, vous pouvez le laisser de côté.

La chose étrange est que même si le pare-feu Windows bloque la communication, vous pourrez toujours vous connecter, mais la poignée de main initiale et les demandes suivantes seront incroyablement lentes. Ma théorie (basée sur aucune preuve réelle) est que dans ces cas, la communication retombe sur les canaux nommés, ce qui est beaucoup plus lent entre les PC distants.

— Laszlo Mako
source