SQL Server Management Studio 2012 se bloque
Lorsque je clique sur le nœud "Bases de données" dans "Explorateur d'objets", il continue de "Chargement d'éléments" jusqu'à ce qu'il se bloque.
Cela se produit uniquement lors de la connexion à un serveur distant, pas lors de l'accès à une base de données sur mon PC.
Cela ne se produit pas non plus avec un autre noeud.
Les gars de la société d'hébergement Web n'ont eu aucun problème avec cela. (Mais ils tournent en 2008 et le serveur SQL est là aussi)
J'ai réinstallé tout le serveur SQL, etc., mais en vain.
Quel pourrait être le problème?
J'ai rencontré le même problème: lors de l'accès à un serveur distant avec l'explorateur d'objets, SSMS se bloquait indéfiniment. L'erreur système DCOM dans le journal des événements système Windows indiquait l'erreur 10009 ("DCOM n'a pas pu communiquer avec l'ordinateur MACHINE_NAME à l'aide de l'un des protocoles configurés.").
La solution était d'effacer l'historique de MRU et d'autres paramètres de mon profil. Pour faire ça:
- Fermez toutes les instances ouvertes de SSMS 2012
- Dans l'explorateur, ouvrez "% AppData%\Microsoft\SQL Server Management Studio"
- Renommez le dossier "11.0" en quelque chose d'autre, comme "11.0.old"
- Ouvrir SSMS 2012
Vous verrez que votre liste de MRU a été effacée. Vous devriez alors pouvoir entrer à nouveau vos informations d'identification et utiliser SSMS normalement.
Si tout fonctionne, vous pouvez supprimer le dossier renommé. Sinon, supprimez le nouveau dossier "11.0" créé et renommez le dossier d'origine en "11.0".
Je ne sais pas du tout si c'est la liste des MRU qui est à l'origine de ce problème ou s'il s'agit d'autres données de profil.
Nous avons pu découvrir que SSMS tente d'établir une connexion DCOM sur le port 135 vers SQL Server (peut-être pour SSIS, le débogage T-SQL ou autre chose). Notre pare-feu a été configuré pour bloquer le port 135. En ouvrant le port dans le pare-feu, nous avons pu utiliser SSMS (ce qui explique sa compatibilité avec les bases de données locales mais pas avec les bases distantes). Malheureusement, un port ouvert 135 est une invitation à de nombreuses attaques, ce n’était donc pas une solution pratique pour nous.
Désactivez la fermeture automatique sur toutes les bases de données. Cela a fonctionné comme un charme pour moi! Chaque fois que vous développez ou actualisez la liste de bases de données, le serveur doit réveiller les bases de données à l'origine du blocage.
Il suffit d’exécuter ceci pour trouver toutes les bases de données qui se ferment automatiquement
SELECT name, is_auto_close_on
FROM master.sys.databases AS dtb
WHERE is_auto_close_on = 1
ORDER BY name
Pour désactiver ce paramètre pour une base de données - Cliquez avec le bouton droit de la souris sur une instance de base de données dans l'explorateur d'objets -> Cliquez sur Propriétés -> Cliquez sur "Options" dans le volet de navigation de gauche dans la fenêtre des propriétés de la base de données -> Définissez la valeur de la propriété Fermeture automatique sur "False" dans volet de droite, comme indiqué dans l’instantané ci-dessous:
En supposant que vous n’ayez accès qu’à une seule base de données de la société d’hébergement (ce qui est presque toujours le cas, du moins avec un nom d’utilisateur/mot de passe donné), vous pouvez éviter d’utiliser la liste déroulante en définissant votre serveur enregistré comme valeur par défaut. base de données à laquelle vous êtes censé accéder:
(Cela peut prendre plus de temps ici aussi, mais ce ne sera qu'une seule fois. Vous pouvez aussi le saisir au lieu d'attendre que la liste soit remplie.)
Ainsi, même si la connexion créée par l'hôte pour vous vous dirige vers tempdb ou quelque chose par défaut, Management Studio vous placera toujours dans le contexte de votre base de données.
Je vois maintenant que vous parlez du nœud de l'Explorateur d'objets, et non du menu déroulant "Utiliser la base de données" que j'ai interprété de manière erronée. Un exercice à essayer peut être de mettre en évidence le nœud des bases de données (ne pas le développer) et de cliquer sur F7 (Détails de l’explorateur d’objets). Si cela vous charge, cela peut être une alternative pour naviguer dans la hiérarchie et, en prime, vous pouvez afficher de nombreux attributs d'entité ici, ainsi qu'une sélection multiple, deux choses sur lesquelles vous n'avez aucun contrôle dans l'Explorateur d'objets.
Si cela ne vous aide pas, alors votre hôte devrait vous aider mieux qu’il n’apparaît. Si SSMS 2012 est pris en charge, ils devraient pouvoir le tester dans SSMS 2012 et confirmer ou infirmer qu'ils peuvent le reproduire. S'il n'est pas pris en charge, je pense que votre recours consiste à installer également SSMS 2008 (ils peuvent coexister) et à l'utiliser pour gérer ce serveur spécifique.
Bien sûr, à peu près tout ce que vous pouvez faire dans l'explorateur d'objets (et plein d'autres choses que vous ne pouvez pas faire), vous pouvez le faire en utilisant les vues catalog et/ou DMV . Donc, avant de décider quoi faire, vous voudrez peut-être revoir (ou partager avec nous) exactement ce pour quoi vous utilisez l'explorateur d'objets. S'il existe un moyen de le faire sans l'explorateur d'objets, vous préférerez peut-être la solution de contournement plutôt que d'avoir deux versions. de l'outil (depuis les améliorations de 2012, SSMS n'a absolument rien à voir avec l'explorateur d'objets).
J'ai passé plus d'un mois avec le support technique Microsoft SQL à résoudre ce problème. Il a été soumis en tant que bogue.
J'ai à la fois SQL 2012 SSMS et VS 2012 installé sur Windows 7 (64).
La suppression du dossier de profil n'a jamais fonctionné pendant un laps de temps raisonnable.
La solution de contournement que nous avons trouvée consistait à nous assurer que mon profil SSMS était configuré par défaut sur la base de données Master lors de la connexion. Cela semble avoir quelque chose à voir avec le fait que je me connecte avec l'authentification Windows et que j'appartiens à plus d'un groupe d'AD auquel des autorisations SQL ont été attribuées ET je n'ai pas d'autorisations spécifiques à SQL définies sur mon compte AD.
Je me connecte à plusieurs serveurs distants de 2000 à 2012 . SMSS sur un PC local est SQL Server 2012, SMSS est 11.0.2100.60
SSMS se bloque plusieurs fois par jour.Lorsque cela se produit, je me connecte via RDP au serveur local /SMSS/Activity Monitor et je tue les processus de mon PC avec Nom de base de données = maître, un à la fois, jusqu'à ce que SMSS se trouve sur mon PC dégèle.
Cela fonctionne toujours, cependant, un traitement pour la maladie plus que les symptômes seraient les bienvenus.
Dans mon cas, la suppression du dossier de profil a fonctionné exactement une fois. La prochaine fois que j'ouvrirai SSMS 2012, il se figerait à nouveau lors de la connexion à un serveur. SP1 n'a pas résolu ce problème non plus.
C'était jusqu'à ce que la solution de contournement simple décrite ci-dessous soit décrite sur un ticket de Ben Amada sur connect.Microsoft.com : Fermez toujours le Détails de l'explorateur d'objets avant de fermer SSMS 2012.
Donc la solution complète pour moi est la suivante:
- Suivez la réponse de Jaecen, mais fermez à nouveau SSMS 2012 après avoir créé un dossier de profil vierge.
- Appliquez la recommandation de Hoodlum et copiez
SqlStudio.binde l'ancien dossier de profil vers le nouveau (l'ancien dossier de profil peut être supprimé par la suite). - Everytime avant de fermer SSMS 2012, assurez-vous que la fenêtre Détails de l'explorateur d'objets est fermée
Les deux premières étapes ne sont requises qu'une seule fois, ou si la fenêtre Détails de l'explorateur d'objets a été laissée ouverte par inadvertance.
Modifier
Je viens de remarquer que la fermeture de la fenêtre Détails de l’explorateur d’objets est également requise lors de la (nouvelle) connexion à un serveur SQL dans la même session SSMS. Donc, en gros, chaque fois que vous vous connectez à un serveur, vous devez fermer la fenêtre Détails de l'explorateur d'objets.
Certains serveurs SQL de 2000 à 2012, accès Puis, via SMSS, à partir de mon ordinateur de bureau .. Un problème se produit à une fréquence variable. Il ressemble à ceci: lorsque je réduis un serveur dans l’explorateur d’objets, SMSS se bloque.
en regardant dans le moniteur d'activité sur le serveur en question, je trouve un processus dans la base de données principale avec Host = mon bureau exécutant la requête suivante.
SELECT dtb.name AS [Nom] FROM master.dbo.sysdatabases AS dtb ORDER BY [Nom] ASC SMSS
tuer le processus libère SMSS.
J'ai testé à peu près toutes les réponses ci-dessus, mais mon SSMS s'est bloqué pour élargir la liste de bases de données. J'ai enfin trouvé le problème. Le problème était dû à une base de données que je l’ai restaurée mais qui a été restaurée correctement à la fin. Ensuite, lorsque j'ai développé la liste de bases de données, elle collait.
Je lance la requête
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM master.sys.databases AS dtb
Ensuite, le résultat a pris trop de temps et à la fin, mais lorsque j'ai filtré la base de données bloquée, j'ai obtenu le résultat.
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM
master.sys.databases AS dtb
Where name <> 'StuckDB' ORDER BY [Name] ASC
À la fin, j'ai décidé de détacher StuckDB pour résoudre mon problème.
Voici ce qui a fonctionné pour moi Ouvrez SSMS Cliquez sur le bouton de connexion à l'explorateur d'objets.
J'ai maintenant appliqué SQL 2012 Service Pack 1 (via Windows Update) et cela semble fonctionner correctement à présent, bien que son chargement prenne beaucoup de temps.
Accédez aux propriétés de la base de données sur SSMS et réglez la compatibilité sur 2012. Vérifiez ensuite.
J'ai résolu ce problème en changeant ma base de données par défaut en maître.
"Ouvrez SSMS, cliquez sur le bouton de connexion à l'explorateur d'objets dans la boîte de dialogue de connexion au serveur, développez les options >> cliquez sur Tout réinitialiser" - cela fonctionne