Temps d'attente extrême lors de la mise hors ligne d'une base de données SQL Server
J'essaie d'effectuer une maintenance hors connexion (restauration de la base de données dev à partir d'une sauvegarde en direct) sur ma base de données dev, mais la commande "Take Offline" via SQL Server Management Studio effectue extrêmement lentement - de l'ordre de 30 minutes, plus à présent. Je suis presque au bout de mes peines et je n'arrive pas à trouver de références en ligne sur ce qui pourrait causer le problème de vitesse, ou sur la façon de le résoudre.
Certains sites ont suggéré que les connexions ouvertes à la base de données étaient à l'origine de ce ralentissement, mais la seule application utilisant cette base de données est l'instance IIS de mon ordinateur dev et le service est arrêté. Il n'y a plus de connexions ouvertes.
Qu'est-ce qui pourrait causer ce ralentissement et que puis-je faire pour l'accélérer?
Après quelques recherches supplémentaires (nouveaux termes de recherche inspirés par la réponse de gbn et le commentaire de u07ch sur la réponse de KMike), j'ai trouvé ceci, qui s'est terminé avec succès en 2 secondes:
ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE
(Mettre à jour)
Lorsque cela échoue toujours avec l'erreur suivante, vous pouvez le corriger comme inspiré par cet article de blog :
ALTER DATABASE a échoué car un verrou n'a pas pu être placé sur la base de données 'nombase'. Réessayez ultérieurement.
vous pouvez exécuter la commande suivante pour savoir qui garde un verrou sur votre base de données:
EXEC sp_who2
Et utilisez la variable SPID que vous trouverez dans la commande suivante:
KILL <SPID>
Ensuite, exécutez à nouveau la commande ALTER DATABASE. Cela devrait maintenant fonctionner.
Il existe probablement une connexion à la base de données quelque part (exemple rare: mise à jour de statistiques asynchrones )
Pour rechercher des connexions, utilisez sys.sysprocesses
USE master
SELECT * FROM sys.sysprocesses WHERE dbid = DB_ID('MyDB')
Pour forcer les déconnexions, utilisez - ROLLBACK IMMEDIATE
USE master
ALTER DATABASE MyDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE
Avez-vous des fenêtres SQL Server Management Studio ouvertes et connectées à cette base de données?
Mettez-le en mode mono-utilisateur, puis réessayez.
Dans mon cas, après avoir tant attendu que cela se termine, je n’ai plus eu de patience et j'ai tout simplement fermé le studio de gestion. Avant de quitter, il a montré le message de réussite, db est hors ligne. Les fichiers étaient disponibles pour renommer.
exécuter la procédure stockée sp_who2
Cela vous permettra de voir s'il y a des verrous de blocage .. tuer leur devrait résoudre le problème.
Dans SSMS: cliquez avec le bouton droit sur l'icône du serveur SQL, Moniteur d'activité. Processus ouverts. Trouvez le connecté connecté. Cliquez avec le bouton droit sur le processus, Kill.
chaque fois que vous rencontrez ce type de problème, pensez toujours à votre journal des transactions. La déclaration alter db avec annulation immédiate indique que tel est le cas. Découvrez ceci: http://msdn.Microsoft.com/en-us/library/ms189085.aspx
Bone up sur les points de contrôle, etc. Vous devez décider si les transactions dans votre journal valent la peine d'être sauvegardées, puis choisissez le mode pour exécuter votre base de données en conséquence. Il n’ya vraiment aucune raison pour vous d’attendre, mais également pour perdre des données - vous pouvez avoir les deux.
Pour résoudre ce problème, j'ai arrêté le site Web qui était connecté à la base de données dans IIS et immédiatement le panneau "gelé", "déconnecter la base de données", est devenu figé.
La fermeture de l'instance de SSMS (SQL Service Manager) à partir de laquelle la demande a été effectuée a résolu le problème pour moi .....
Dans mon cas, j'avais consulté certaines tables de la base de données avant d'exécuter cette action. Mon compte utilisateur détenait une connexion active à cette base de données dans SSMS. Une fois que je me suis déconnecté du serveur dans SSMS (en laissant ouverte la boîte de dialogue "Déconnecter la base de données"), l'opération a réussi.
Dans SSMS, définissez la base de données sur lecture seule puis retour. Les connexions seront fermées, ce qui libère les serrures.
Dans mon cas, un site Web avait des connexions ouvertes à la base de données. Cette méthode était assez simple:
- Cliquez avec le bouton droit sur la base de données -> Propriétés -> Options
- Définissez
Database Read-Onlysur True - Cliquez sur 'Oui' dans la boîte de dialogue d'avertissement SQL Server fermera toutes les connexions à la base de données.
- Rouvrez Options et désactivez la lecture seule.
- Maintenant, essayez de renommer la base de données ou de la déconnecter.
Fermez également toutes les fenêtres de requête ouvertes connectées à la base de données en question;)
J'ai essayé toutes les suggestions ci-dessous et rien n'a fonctionné.
- EXEC sp_who
Tuer <SPID>
ALTER DATABASE SET SINGLE_USER WITH Rollback Immediate
ALTER DATABASE SET OFFLINE AVEC ROLLBACK IMMEDIATE
Résultat: les deux commandes ci-dessus étaient également bloquées.
4 Cliquez avec le bouton droit sur la base de données -> Propriétés -> Options Définissez Base de données en lecture seule sur True Cliquez sur 'Oui' dans la boîte de dialogue d'avertissement SQL Server fermera toutes les connexions à la base de données.
Résultat: la fenêtre était bloquée à l'exécution.
En dernier recours, j'ai redémarré le service serveur SQL à partir du gestionnaire de configuration, puis exécuté ALTER DATABASE SET OFFLINE AVEC ROLLBACK IMMEDIATE. Ça a marché comme sur des roulettes
Dans mon cas, j'ai arrêté le serveur Tomcat. alors immédiatement la DB est passée hors ligne.
Pour moi, je devais simplement accéder au moniteur d'activité et arrêter deux tâches en cours de traitement. Ensuite, il s'est déconnecté immédiatement. Dans mon cas, je savais quels étaient ces deux processus et que c’était acceptable de les arrêter.
La prochaine fois, dans la boîte de dialogue Take Offline, n'oubliez pas de cocher la case "Supprimer toutes les connexions actives". J'étais également sur SQL_EXPRESS sur une machine locale sans connexion, mais ce ralentissement s'est produit pour moi sauf si j'ai coché cette case.
Dans mon cas, la base de données était liée à une ancienne installation de Sharepoint. L'arrêt et la désactivation des services associés dans le gestionnaire de serveur ont "déclenché" l'action de mise hors ligne, qui fonctionnait depuis 40 minutes et s'est terminée immédiatement.
Vous voudrez peut-être vérifier si des services utilisent actuellement la base de données.