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 hostsfichier
• 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 quelques 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 1 et 2 mentionnés ci-dessus 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 découvert 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.

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

1. Installation d'un pilote vidéo mis à jour -OU-
2. Réduction ou désactivation de l'accélération matérielle -OU-
3. 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 sur 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 la 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 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 me suis dit que j'essaierais de désactiver le logiciel AV. Une fois l'analyse Trend Micro Office 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 lorsque je fais 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/

J'ai eu le même problème avec SSMS 2016. J'ai utilisé procmon pour identifier que la dernière chose qu'il a faite 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 HKEY_CURRENT_USER\SOFTWARE\Microsoft\Microsoft SQL Server\130valeur CustomerFeedbackde la clé de registre 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 à la 110place 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.

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.

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 avait 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 la boîte de l'usine avec le nom de PC aléatoire par défaut.

C'est rapide sur mon ordinateur.

SSMS dans SQL Server 2012 utilise désormais le shell Visual Studio 2010, qui nécessite 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.

http://support.microsoft.com/kb/2679368/

changer le nom de l'ordinateur pour qu'il n'y ait pas 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.

Pour moi, c'est le pare-feu BitDefender qui a rendu mon SSM ultra lent. Apparemment, une sorte de pare-feu bloquant l'accès à la liste de la base de données.

Il faut vérifier l'état de la propriété de base de données " Fermer automatiquement " dans " Automatiquement ".

Si vrai, après chaque requête, la connexion sera fermée et rouverte à chaque nouvelle requête. Cela ralentit sûrement votre travail en quelques secondes. La valeur par défaut est fausse.

Se pourrait-il que vous n'ayez pas assez de RAM sur votre ordinateur?

La RAM recommandée pour SQL 2012 est de 4 Go. C'était 2 go pour SQL 2008. http://msdn.microsoft.com/en-us/library/ms143506.aspx

Puisque vous avez mis à niveau SQL 2008 vers 2012, vous avez peut-être besoin de plus de RAM?

Lorsque je démarre SSMS en utilisant les privilèges d'administrateur (clic droit et exécution en tant qu'administrateur), cela fonctionne correctement, sinon la nouvelle fenêtre de requête prend plus de temps

La cause de cela est presque toujours un lecteur réseau manquant - par exemple si vous avez un mappage de lecteur vers votre ordinateur portable, mais que votre ordinateur portable est éteint.

La résolution consiste malheureusement à allumer votre ordinateur portable (pour que les disques se reconnectent) ou à déconnecter vos disques dans l'Explorateur Windows (mais vous devez ensuite les reconnecter plus tard).

Voir ici pour plus d'informations: http://social.msdn.microsoft.com/Forums/en-US/sqltools/thread/64c13a84-3e62-4b0c-a1ce-65fcc78d6787