web-dev-qa-db-fra.com

Connexion lente ou délai d'attente de SQL Server Management Studio lors de l'utilisation de l'authentification Windows

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 Authentification Windows . Cela se produit lors de la connexion de l'Explorateur d'objets ou d'une nouvelle fenêtre de requête vierge. 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 et VPN spécifique; 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 à 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:

  • En utilisant TCPView, j'ai remarqué que lorsque j'établis une nouvelle connexion, son état devient immédiatement ÉTABLI, mais ensuite une ou deux autres connexions 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.

sql-serversql-server-2012ssmsconnectivity
24
Jordan Rieger

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, puisque 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.

20
d-_-b

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 rare 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 du 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 approprié ou DC 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

Lancez la commande IPConfig.exe/all à 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.

5
NikolaD

J'ai étendu C:\Windows\System32\drivers\etc\hosts fichier 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

0
Dennis Gorelik

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

  • Démarrer Powershell
  • Courir Get-NetFirewallProfile -Profile Domain pour vérifier son état actuel
  • S'il est activé, exécutez: Set-NetFirewallProfile -Profile Domain -Enabled False pour le désactiver.

Si c'était 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.

0
Laszlo Mako