Le processus «TASK MANAGER» reprend une base de données en mode mono-utilisateur. Qu'Est-ce que c'est?

13

Ceci est un double de la question que j'ai posée sur stackoverflow , mais on m'a dit que quelqu'un ici pourrait avoir une meilleure idée de ce qui se passe.

J'ai un problème sporadique, lors de la mise à niveau de SQL Server en mode mono-utilisateur, à l'aide de .NET SqlConnection, une autre application se connecte en quelque sorte à la base de données, tandis que le code SQL est en cours d'exécution et lance mon processus. SqlConnection n'est pas fermé ou éliminé de quelque façon que ce soit. Mais une autre application se retrouve en quelque sorte connectée à la base de données et cela met fin à ma connexion.

Lorsque j'exécute sp_who, je pouvais voir qu'un processus qui prenait le contrôle de la base de données était Command = "TASK MANAGER".

N'importe qui pourrait me dire quel est ce processus, quel est son objectif et comment, dans le monde, il pourrait entrer dans une base de données, qui est en mode mono-utilisateur, et il y a une connexion active?

sql-server sql-server-2008

— galets
source

Arrêtez-vous SQL Agent au cours de ce processus? Les tâches nommées "TASK MANAGER" (avec un faible nombre de spid) sont des processus internes.

— Jon Seigel

@ JonSeigel non, je ne l'ai pas fait. Êtes-vous en train de dire que SQL Agent est un processus réel qui exécute TASK MANAGER?

— galets

Je ne suis pas sûr à 100%. Ce que je sais, c'est que l'Agent SQL se connecte à l'instance lorsqu'il est en cours d'exécution, ce qui peut vous empêcher de vous connecter lorsque le serveur est en mode mono-utilisateur. J'ai eu ce problème hier, et l'arrêt de l'Agent SQL l'a corrigé.

— Jon Seigel

2

Pour être clair, ce n'est pas le même gestionnaire de tâches que vous utilisez dans Windows pour afficher les processus et les performances du système.

— Aaron Bertrand

10

Eu le même problème aujourd'hui, si vous n'avez pas désactivé votre AUTO_UPDATE_STATISTICS ASYNC, vous ne pourrez pas entrer dans votre base de données, vous pouvez résoudre ce problème en mettant votre base de données hors ligne. Il est important de savoir que vous devez définir votre priorité de blocage sur élevé, sinon vous serez bloqué hors de la commande. Utilisez les commandes suivantes pour sortir du mode utilisateur UNIQUE

SET DEADLOCK_PRIORITY HIGH

ALTER DATABASE [YourDBName] SET OFFLINE WITH ROLLBACK IMMEDIATE

Suivi par

SET DEADLOCK_PRIORITY HIGH

ALTER DATABASE [YourDBName] SET ONLINE WITH ROLLBACK IMMEDIATE

Suivi par

SET DEADLOCK_PRIORITY HIGH

ALTER DATABASE [YourDBName] SET MULTI_USER WITH ROLLBACK IMMEDIATE

— Stijn Wynants
source

3

Merci beaucoup pour cela. Cependant, j'ai trouvé que l'étape OFFLINE / ONLINE n'était pas requise; le SET MULTIUSER WITH ROLLBACK IMMEDIATEtravail juste par lui-même quand a SET DEADLOCK_PRIORITY HIGHété fait pour la première fois

— Ross Presser

6

Je pense que le mystère a finalement été résolu :

Avant de définir la base de données sur SINGLE_USER, vérifiez que l'option AUTO_UPDATE_STATISTICS_ASYNC est définie sur OFF. Lorsqu'il est défini sur ON, le thread d'arrière-plan utilisé pour mettre à jour les statistiques prend une connexion avec la base de données et vous ne pourrez pas accéder à la base de données en mode mono-utilisateur.

— galets
source

6

Arrêtez la trace des événements étendus "system_health". Il sera répertorié sous

SQL Server Management Studio
-> [ServerName]
-> Management
-> Extended Events
-> Right-Click on 'System_health'
-> Hit Stop Session

Une fois le bloqueur résolu, redémarrez la session.

— Raghu Nair
source

Bien que l'autre réponse explique pourquoi cela se produit, celui-ci explique comment le résoudre.

— Boris Callens

Résolution parfaite pour moi. Cela a fonctionné comme prévu

— Im88

0

Vous devez désactiver SQL Agent «avant» de démarrer le mode à usage unique. Comme l'agent accout accédera à l'utilisateur unique. N'oubliez pas que l'utilisateur unique n'est pas vous le premier utilisateur / processus à se connecter.

— Nick Winstanley
source