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 ligne (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 maintenant. Je suis à peu près à la fin de mon esprit et je n'arrive pas à trouver de références en ligne sur ce qui pourrait causer le problème de vitesse, ou comment le résoudre.

Certains sites ont suggéré que les connexions ouvertes à la base de données provoquent ce ralentissement, mais la seule application qui utilise cette base de données est l'instance IIS de ma machine de développement, 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?

259
demandé sur Erik Forbes 2009-04-30 21:53:15

17 réponses

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

(mise à jour)

Quand cela échoue avec l'erreur suivante, vous pouvez le fixer comme inspiré par ce blog:

ALTER DATABASE a échoué car un verrou n'a pas pu être placé sur la base de données 'dbname' réessayez plus tard.

Vous pouvez exécuter la commande suivante pour qui garde un verrou sur votre base de données:

EXEC sp_who2

Et utilisez ce que SPID vous trouverez dans la commande suivante:

KILL <SPID>

Puis exécutez à nouveau la commande ALTER DATABASE. Cela devrait maintenant fonctionner.

376
répondu Erik Forbes 2016-02-03 17:13:24

Il y a très probablement une connexion à la base de données de quelque part (un exemple rare: mise à jour statistique asynchrone )

Pour trouver 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
120
répondu gbn 2012-01-23 08:45:17

Avez-vous des fenêtres ouvertes de SQL Server Management Studio qui sont connectées à cette base de données?

Mettez - le en mode mono-utilisateur, puis réessayez.

25
répondu KM. 2016-05-30 09:36:33

Dans mon cas, après avoir tant attendu que cela se termine, je n'ai pas eu de patience et j'ai simplement fermé le studio de gestion. Avant de quitter, il a montré le message de succès, db est hors ligne. Les fichiers étaient disponibles pour renommer.

16
répondu Rudy 2013-08-20 15:02:42

Exécute la procédure stockée sp_who2

Cela vous permettra de voir s'il y a des verrous bloquants.. tuer leur devrait le réparer.

6
répondu woodwa 2017-01-24 03:16:05

Dans SSMS: cliquez avec le bouton droit sur L'icône SQL server, Moniteur D'activité. Processus Ouverts. Trouvez le connecté traité. Faites un clic droit sur le processus, tuer.

5
répondu nzeemin 2014-12-10 16:23:13

Chaque fois que vous rencontrez ce type de chose, vous devriez toujours penser à votre journal des transactions. L'état alter db avec rollback immediate indique que c'est le cas. Vérifiez ceci: http://msdn.microsoft.com/en-us/library/ms189085.aspx

Os sur les points de contrôle, etc. Vous devez décider si les transactions dans votre journal valent la peine d'être sauvegardées ou non, puis choisir le mode pour exécuter votre base de données en conséquence. Il n'y a vraiment aucune raison pour que vous ayez à attendre, mais aussi aucune raison pour la perte de données - vous pouvez avoir les deux.

4
répondu yetanotherdave 2009-04-30 18:25:36

Pour contourner 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é ''take db offline' est devenu non gelé.

2
répondu Dan 2014-01-23 13:45:49

La fermeture de L'instance de SSMS (SQL Service Manager) à partir de laquelle la demande a été faite a résolu le problème pour moi.....

2
répondu Armand G. 2015-02-25 15:52:31

Dans mon cas, j'avais regardé quelques tables dans 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 la boîte de dialogue' Take database offline ' ouverte), l'opération a réussi.

2
répondu RamenNoodle 2017-09-11 15:45:25

Fermez également toutes les fenêtres de requête ouvertes qui sont connectées à la base de données en question ;)

1
répondu Steve Woods 2015-08-17 11:58:33

Dans SSMS, définissez la base de données en lecture seule puis revenez. Les connexions seront fermées, ce qui libère les verrous.

Dans mon cas, il y avait un site web qui avait des connexions ouvertes à la base de données. Cette méthode était assez facile:

  1. cliquez avec le bouton droit sur la base de données -> propriétés -> Options
  2. définit Database Read-Only sur True
  3. Cliquez sur " Oui " dans la boîte de dialogue Avertissement SQL Server fermera toutes les connexions à la base de données.
  4. rouvrez les Options et désactivez la lecture seule
  5. Maintenant, essayez renommer la base de données ou la mettre hors ligne.
1
répondu zacharydl 2016-02-01 19:24:28

Pour moi, je devais juste aller dans le moniteur D'activité de travail et arrêter deux choses qui étaient en cours de traitement. Ensuite, il s'est déconnecté immédiatement. Dans mon cas, je savais ce que ces processus 2 étaient et qu'il était correct de les arrêter.

0
répondu craig 2015-07-02 12:19:50

Dans mon cas, j'ai arrêté le serveur Tomcat . puis immédiatement la base de données s'est déconnectée .

0
répondu Java Main 2015-12-02 12:49:23

Dans mon cas, la base de données était liée à une ancienne installation Sharepoint. L'arrêt et la désactivation des services connexes dans le gestionnaire de serveur "unhung" l'action take offline, qui avait été en cours d'exécution pendant 40 minutes, et il a terminé immédiatement.

Vous pouvez vérifier si des services utilisent actuellement la base de données.

0
répondu Jonathan 2016-08-11 18:45:21

La prochaine fois, dans la boîte de dialogue prendre hors ligne, n'oubliez pas de cocher la case "Supprimer toutes les connexions actives". J'étais aussi sur SQL_EXPRESS sur une machine locale sans connexion, mais ce ralentissement s'est produit pour moi à moins que je coche cette case.

0
répondu Brett Drake 2018-09-19 16:51:55

J'ai essayé toutes les suggestions ci-dessous et rien n'a fonctionné.

  1. EXEC sp_who
  2. Tuer

  3. ALTER DATABASE SET SINGLE_USER avec Rollback Immediate

    MODIFIER LA BASE DE DONNÉES HORS LIGNE AVEC RESTAURATION IMMÉDIATE

    Résultat: les deux commandes ci-dessus ont également été bloquées.

4 . Cliquez avec le bouton droit sur la base de données - > propriétés - > Options Définir la base de données en lecture seule sur True Cliquez sur " Oui " dans la boîte de dialogue Avertissement SQL Server fermera tout les connexions à la base de données.

Résultat: la fenêtre était bloquée lors de l'exécution.

En dernier recours, j'ai redémarré le service SQL server à partir du gestionnaire de configuration, puis j'ai exécuté ALTER DATABASE SET OFFLINE avec ROLLBACK IMMEDIATE. Cela a fonctionné comme un charme

0
répondu Viraj A 2018-10-03 09:23:31