SQL Server Management Studio ouvre lentement de nouvelles fenêtres
Après la mise à niveau de SQL Server et de Management Studio de 2008 à 2012, Management Studio 2012 est très lent lorsque de nouvelles fenêtres de requête et boîtes de dialogue sont ouvertes.
Même un clic droit sur les tableaux est lent. Il y a généralement au moins 5 secondes de retard avant que je puisse commencer à faire quoi que ce soit dans une fenêtre. Cela se produit à chaque fois, même si j'ouvre la même fenêtre deux fois de suite. Pourquoi cela se produit-il et comment puis-je le corriger?
D'autres applications établissent des connexions à la base de données très rapidement.
Les choses que j'ai essayées n'ont pas aidé:
- Un hit sur Google où je devrais modifier mon fichier
hosts - Réinitialisation des "paramètres définis par l'utilisateur" SSMS
- Mise à jour des pilotes vidéo, désactivation de l'accélération matérielle, désactivation de DirectX
- Désactiver le service d'authentification biométrique (je ne l'ai pas installé).
Mon ordinateur devrait être plus que suffisamment rapide et j'ai également 16 Go de RAM. Mon matériel ne devrait certainement pas être un problème. Il semble que SSMS attend quelque chose - je peux faire fonctionner d'autres programmes en douceur pendant que cela se produit.
Je n'ai pas la possibilité d'installer la mise à jour SQL Server 2012 CU1 car il semble y avoir un risque d'erreurs lors de l'installation des correctifs et je ne peux pas risquer cela pour le moment.
Démarrage de SQL Server Management Studio
Lorsque Microsoft SQL Server Management Studio (SSMS) démarre, il essaie de connecter la liste de révocation de certificats (CRL) de Microsoft:
http://crl.Microsoft.com/pki/crl/products/MicrosoftRootAuthority.crl
Les composants .NET sous-jacents de SSMS tentent de contacter la liste de révocation de certificats et SSMS ne peut pas le faire. Cela ralentit la procédure de chargement globale. (15 secondes par certificat apparemment)
Ok voici donc ce qui se passe. SSMS a un pourcentage élevé de code managé, tout ce code est signé lorsque nous l'expédions. Au démarrage (si ce paramètre est coché), le .Net Runtime essaie de contacter crl.Microsoft.com pour s'assurer que le certificat est valide (il y a eu de faux certificats émis au nom de Microsoft il y a quelque temps, c'est donc une préoccupation très valable) . S'il n'y a pas de connexion Internet ou s'il y a un problème pour contacter le serveur de liste de révocation de certificats, cela retardera le démarrage de SSMS.
Référence: FAQ, Pourquoi SSMS prend-il 45 secondes pour démarrer? (Blog MSDN)
Un problème qui peut provoquer ce problème est que si le serveur n'a pas accès à Internet, le framework .NET ne peut pas accéder au site Web crl.Microsoft.com pour vérifier que les signatures numériques utilisées pour signer les binaires pour les applications gérées sont valides. Chaque vérification de certificat a un délai d'expiration de 15 secondes dans l'implémentation d'exécution .NET. Selon les fonctionnalités installées, cela peut ajouter jusqu'à une minute de temps de démarrage pour Management Studio.
Référence: heure de démarrage de SQL Server Management Studio (blog MSDN)
Solutions
Vous pouvez contourner une partie du problème en téléchargeant le certificat directement en entrant le lien dans votre navigateur, puis en important le certificat dans votre base de données de certificats
- OU -
Vous pouvez reconfigurer le pare-feu (de votre entreprise) pour autoriser les connexions à la liste de révocation de certificats de Microsoft
- OU -
Vous pouvez reconfigurer votre antivirus/pare-feu personnel pour autoriser les connexions à la liste de révocation de certificats Microsoft
- OU -
Vous pouvez configurer le pare-feu (de votre entreprise) pour envoyer un délai d'attente plus rapidement à votre client pour les demandes d'accès à la liste de révocation de certificats de Microsoft.
- OU -
Vous pouvez configurer IE pour ne plus "Vérifier la révocation du certificat de l'éditeur" dans les paramètres avancés.
(Voir les blogs mentionnés ci-dessus 1 et 2 pour plus de détails)
J'ai la même expérience que vous lorsque je me connecte au nom de serveur "./". Par chance, j'ai constaté que je ne rencontrais pas le problème de performances lorsque je me connectais au nom de serveur "(local)". Il y a probablement un problème avec la façon dont SSMS 2012 résout le serveur via "./".
Edit: Je ne pense pas que ce soit lié à SSMS car je peux reproduire la lenteur avec ./ dans une connexion ADO.NET.
Il se peut que SSMS ait importé des paramètres qui ne peuvent plus être traités correctement (comme des connexions à un serveur ou peut-être des paramètres de complément).
Il existe un moyen brutal de "réinitialiser" les paramètres définis par l'utilisateur de SSMS.
Fermez SSMS, allez dans le dossier:
C:\Users\YOURWINLOGINNAME\AppData\Roaming\Microsoft\SQL Server Management Studio\
Vous trouverez le sous-dossier "11.0". Renommez-le en "11.0_", vous pouvez donc toujours le renommer. Maintenant, lancez SSMS - il recréera des paramètres propres et peut-être que votre problème sera résolu. Sinon - supprimez le "11.0" nouvellement généré et renommez "11.0_" en "11.0".
Cela pourrait également être un comportement de certains compléments, qui ont été corrompus après la mise à niveau. Les compléments s'enregistrent en tant que gestionnaires pour certaines commandes ou événements et le système peut devenir instable s'ils manquent/lèvent des exceptions.
En fait, v2012 utilise un autre mécanisme pour enregistrer les compléments, mais certains compléments s'installent sur toutes les instances. Pour vérifier, examinez cette clé de registre:
[HKEY_CURRENT_USER\Software\Microsoft\SQL Server Management Studio\11.0_Config\AutomationOptions\LookInFolder]
Vous y trouverez la liste des dossiers. Vérifiez tous ces dossiers - ils doivent être vides (signifie que vous n'avez pas de compléments).
Essayez de désactiver l'antivirus, puis vérifiez les performances de sql server 2012 management studio.
J'ai eu le même problème avec SSMS 2016. J'ai utilisé procmon pour identifier que la dernière chose à faire avant un délai de plusieurs secondes était d'établir une connexion réseau à une adresse IP Microsoft. J'ai ensuite essayé de désactiver le programme d'expérience client en définissant la clé de registre HKEY_CURRENT_USER\SOFTWARE\Microsoft\Microsoft SQL Server\130 valeur CustomerFeedback de 1 à 0. Après avoir redémarré SSMS, cela fonctionne à nouveau rapidement. Vraisemblablement, cela ne conduit pas toujours à ralentir les nouvelles fenêtres de requête, mais pour moi, c'est le cas.
Je ne sais pas si c'est ce qui se passait avec votre SSMS 2012, mais cela vaut peut-être la peine d'essayer. La clé de registre sera probablement 110 au lieu de 130.
Concernant SSMS 2016 et le changement de registre. Mon chemin était
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\130\Tools\Setup\UserFeedbackOptIn
Je l'ai changé de 1 à 0 et SSMS était à nouveau rapide.
J'ai le même problème et il s'avère que l'analyse Trend Micro Office est à l'origine du problème.
J'ai essayé tout ce qui est décrit dans plusieurs autres discussions similaires sur ce problème en vain. Je pensais que j'essaierais de désactiver le logiciel AV. Une fois que l'analyse Trend Micro Office est désactivée, SSMS s'éclaircit rapidement.
Cela ne s'est pas produit sous Windows 7.
Moi aussi, je subissais un retard de 5 à 10 secondes lors d'un clic droit sur une table pour afficher le menu contextuel. Ma situation peut cependant être un peu différente de certaines car j'utilise uniquement des bases de données locales. Ma solution:
Après avoir lu la réponse d'Imran sur la désactivation de l'antivirus, j'ai poussé ce concept un peu plus loin car je ne veux pas désactiver complètement mon antivirus JUSTE pour surmonter ce problème.
J'ai considérablement réduit le délai (il est maintenant de 1 seconde maximum) en modifiant les emplacements de base de données par défaut, puis en excluant ce répertoire de l'antivirus (dans mon cas, j'utilise Microsoft System Center Endpoint Protection 2015).
Pour modifier les emplacements de base de données par défaut, consultez l'article suivant pour des informations détaillées. http://thomaslarock.com/2015/02/changing-default-database-file-locations-in-sql-server/
Je n'ai pas personnellement rencontré ce problème, mais il y a un long fil ( ici ) où beaucoup de gens ont. Le conseil général semble être lié à l'utilisation de votre pilote vidéo soit par
- Installation d'un pilote vidéo mis à jour -OU-
- Réduction ou désactivation de l'accélération matérielle -OU-
- Désactiver la prise en charge de DirectX
Du fil, il y avait aussi cette réponse ... "La procédure de démarrage propre de Windows 7 a révélé que le service d'authentification biométrique (DigitalPersona DPHostw.exe) était le problème. La désactivation du service a résolu le problème."
Je serais intéressé de savoir si l'une de ces approches fonctionne également dans votre cas, car le fil que j'ai trouvé concerne les anciennes versions de SSMS, à savoir 2005, 2008, etc.
Je suppose que le problème est que l'ouverture d'une nouvelle connexion à votre serveur prend 5 secondes. Pourquoi exactement c'est le cas, je ne peux pas le dire et cela nécessiterait une trace de fil pour analyser et diagnostiquer. Vous devez rechercher quel (s) protocole (s) sont tentés et quel protocole a finalement réussi. Il se peut que votre client tente d'abord de nommer les canaux (qui dépend de SMB) puis retombe à TCP (bien que le délai habituel dans un tel cas soit beaucoup plus long, environ 20-30 secondes)) .
Je vous recommande de vérifier l'ordre des protocoles clients dans Configuration du réseau client . Vérifiez le protocole utilisé par le client en trouvant votre propre entrée dans sys.dm_exec_connections .
J'ai ssms v17.0, j'ai également eu le problème avec les menus contextuels de clic droit lent.
Le nom de l'ordinateur comportait des tirets, renommant l'ordinateur quelque chose de simple, le corrigeait.
J'ai désinstallé ssms, désinstallé le serveur sql, renommé l'ordinateur quelque chose de simple comme 'MyBox' au lieu de 'xja-13-asdfa3'. Ensuite, j'ai réinstallé le serveur sql, puis ssms, et cela a corrigé TOUS mes problèmes de menu contextuel LENT lors d'un clic droit sur les tables. J'imagine que quelque part des problèmes DNS se produisaient et les attentes étaient liées à l'attente des délais d'attente DNS.
J'avais un ordinateur portable avec 16 Go de RAM, des disques SSD, un processeur 3 GHz tout droit sorti de l'usine avec le nom de PC aléatoire par défaut.
Parfois, ce problème peut être résolu en fermant simplement un grand nombre de fenêtres de requête mises en cache.
Mon instance de SSMS avait environ 15 requêtes dans le cache enregistré (qui s'ouvrait à chaque fois que j'ouvrais SSMS) - J'ai fermé toutes ces fenêtres et redémarré SSMS et le problème a immédiatement disparu.
changer le nom de l'ordinateur pour ne pas avoir de "-" est ce qui l'a corrigé pour moi.
Il est important que vous n'utilisiez pas le nom court NetBIOS!
Si vous le faites, le studio de gestion utilise une sorte de connexion héritée. Tout sera extrêmement lent. Utilisez simplement l'IP ou le nom complet de la machine sur laquelle le serveur SQL s'exécute.
Si vous voulez savoir quel est le nom NetBIOS de votre machine, lancez une requête:
select @@Servername
Cela renvoie le nom hérité court, je pense de 15 caractères de long de la machine. Ne l'utilisez pas.
C'est rapide sur mon ordinateur.
SSMS dans SQL Server 2012 utilise désormais Visual Studio 2010 Shell, qui consomme plus de ressources que le shell utilisé par SSMS dans SQL Server 2008. Je suggère de mettre à niveau votre ordinateur ou d'utiliser SSMS à partir de SQL Server 2008 R2. Vous devriez pouvoir effectuer la plupart des tâches avec l'ancienne version.
Vous pouvez également essayer d'installer la dernière mise à jour cumulative car ils mettront également à jour les outils client. La dernière version de SQL Server 2012 est actuellement CU1.
Pour moi, c'est le pare-feu BitDefender qui a rendu mon SSM ultra lent. Apparemment, une sorte de pare-feu bloquant pour accéder à la liste des bases de données