ALTER DATABASE a échoué car un verrou n’a pas pu être placé sur la firebase database

Je dois redémarrer une firebase database car certains processus ne fonctionnent pas. Mon plan est de le déconnecter et de le remettre en ligne.

J’essaie de le faire dans Sql Server Management Studio 2008:

use master; go alter database qcvalues set single_user with rollback immediate; alter database qcvalues set multi_user; go 

Je reçois ces erreurs:

 Msg 5061, Level 16, State 1, Line 1 ALTER DATABASE failed because a lock could not be placed on database 'qcvalues'. Try again later. Msg 5069, Level 16, State 1, Line 1 ALTER DATABASE statement failed. Msg 5061, Level 16, State 1, Line 4 ALTER DATABASE failed because a lock could not be placed on database 'qcvalues'. Try again later. Msg 5069, Level 16, State 1, Line 4 ALTER DATABASE statement failed. 

Qu’est-ce que je fais mal?

Après avoir reçu l’erreur, lancez

 EXEC sp_who2 

Recherchez la firebase database dans la liste. Il est possible qu’une connexion ne soit pas terminée. Si vous trouvez des connexions à la firebase database, exécutez

 KILL  

est le SPID des sessions connectées à la firebase database.

Essayez votre script après avoir supprimé toutes les connexions à la firebase database.

Malheureusement, je n’ai aucune raison de voir le problème, mais voici un lien qui montre que le problème est survenu ailleurs.

http://www.geakeit.co.uk/2010/12/11/sql-take-offline-fails-alter-database-failed-because-a-lock-could-not-error-5061/

J’ai réussi à reproduire cette erreur en procédant comme suit.

Connexion 1 (laissez fonctionner quelques minutes)

 CREATE DATABASE TESTING123 GO USE TESTING123; SELECT NEWID() AS X INTO FOO FROM sys.objects s1,sys.objects s2,sys.objects s3,sys.objects s4 ,sys.objects s5 ,sys.objects s6 

Connexions 2 et 3

 set lock_timeout 5; ALTER DATABASE TESTING123 SET SINGLE_USER WITH ROLLBACK IMMEDIATE; 

Essayez ceci si c’est “en transition” …

http://learnmysql.blogspot.com/2012/05/database-is-in-transition-try-statement.html

 USE master GO ALTER DATABASE  SET OFFLINE WITH ROLLBACK IMMEDIATE ... ... ALTER DATABASE  SET ONLINE 

Dans SQL Management Studio, accédez à Sécurité -> Connexions et double-cliquez sur votre connexion. Choisissez Rôles du serveur dans la colonne de gauche et vérifiez que sysadmin est coché.

Dans mon cas, j’étais connecté à un compte sans ce privilège.

HTH!

Tuer l’identifiant du processus fonctionnait parfaitement pour moi. Lorsque vous exécutez “EXEC sp_who2” Commande sur une nouvelle fenêtre de requête … et filtrez les résultats pour la firebase database “occupée”, Tuer les processus avec la commande “KILL” a réussi à faire l’affaire. Après cela, tout a fonctionné à nouveau.

Juste pour append mes deux cents. Je me suis mis dans la même situation, tout en recherchant les privilèges minimum requirejs d’un identifiant de firebase database pour exécuter l’instruction avec succès:

 ALTER DATABASE ... SET SINGLE_USER WITH ROLLBACK IMMEDIATE 

Il semble que l’instruction ALTER se termine avec succès , lorsqu’elle est exécutée avec un identifiant sysadmin , mais qu’elle nécessite la partie nettoyage des connexions, lorsqu’elle est exécutée sous une connexion qui ne dispose “que” d’permissions limitées comme:

 ALTER ANY DATABASE 

Post-scriptum J’ai passé des heures à essayer de comprendre pourquoi “ALTER DATABASE ..” ne fonctionne pas lorsqu’il est exécuté sous un identifiant doté des privilèges dbcreator role + ALTER ANY DATABASE . Voici mon thread MSDN !

Je sais que c’est un ancien message, mais j’ai récemment rencontré un problème très similaire. Malheureusement, je n’ai pu utiliser aucune des commandes alter database car un verrou exclusif ne pouvait pas être placé. Mais je n’ai jamais pu trouver une connexion ouverte à la firebase database. J’ai finalement dû supprimer avec force l’état d’intégrité de la firebase database pour le forcer dans un état de restauration plutôt que dans la récupération.

Je vais append ceci ici au cas où quelqu’un serait aussi chanceux que moi.

Lors de l’examen de la liste de processus sp_who2 , notez les processus qui s’exécutent non seulement pour la firebase database concernée mais également pour master . Dans mon cas, le problème qui bloquait la firebase database était lié à une procédure stockée qui démarrait un fichier xp_cmdshell.

Vérifiez si vous avez des processus dans l’état KILL / RollBack pour la firebase database master

 SELECT * FROM sys.sysprocesses WHERE cmd = 'KILLED/ROLLBACK' 

Si vous avez le même problème, la commande KILL ne vous aidera probablement pas. Vous pouvez redémarrer le serveur SQL, ou mieux, trouver le fichier cmd.exe sous les processus Windows sur le système d’exploitation SQL et le tuer.

Dans de rares cas (par exemple, après la validation d’une transaction lourde), un processus système CHECKPOINT en cours d’exécution avec un verrou FILE sur le fichier de firebase database empêche la transition vers le mode MULTI_USER.