Quitter le mode mono-utilisateur

Actuellement, ma base de données est en mode mono-utilisateur. Lorsque j'essaie de développer ma base de données, j'obtiens une erreur:

La base de données 'my_db' n'est pas accessible. (ObjectExplorer)

De plus, lorsque j'essaie de supprimer la base de données, j'obtiens l'erreur:

Impossible de modifier l'état ou les options de la base de données 'my_db' pour le moment. La base de données est en mode mono-utilisateur et un utilisateur y est actuellement connecté.

Comment sortir du mode mono-utilisateur? Je n'ai aucun utilisateur utilisant cette base de données.

Lorsque j'essaie de parcourir mon site avec IIS, l'erreur que j'obtiens est:

Une exception non gérée a été générée lors de l'exécution de la demande Web actuelle. Les informations concernant l'origine et l'emplacement de l'exception peuvent être identifiées à l'aide de la trace de pile d'exceptions ci-dessous.

J'ai l'impression que le mode mono-utilisateur est à l'origine de cela.

SSMS en général utilise plusieurs connexions à la base de données en arrière-plan.

Vous devrez supprimer ces connexions avant de changer le mode d'accès.

Tout d'abord, assurez-vous que l'explorateur d'objets pointe vers une base de données système comme master.

Deuxièmement, exécutez un sp_who2 et recherchez toutes les connexions à la base de données 'my_db'. Tuez toutes les connexions en faisant KILL { session id }où l'ID de session est SPIDrépertorié par sp_who2.

Troisièmement, ouvrez une nouvelle fenêtre de requête.

Exécutez le code suivant.

-- Start in master
USE MASTER;

-- Add users
ALTER DATABASE [my_db] SET MULTI_USER
GO

Voir mon article de blog sur la gestion des fichiers de base de données. Cela a été écrit pour déplacer des fichiers, mais la gestion des utilisateurs est la même.

Tout d'abord, trouvez et KILL tous les processus en cours d'exécution.

Ensuite, exécutez ce qui suit T-SQLpour définir la base de données en MULTI_USERmode.

USE master
GO
DECLARE @kill varchar(max) = '';
SELECT @kill = @kill + 'KILL ' + CONVERT(varchar(10), spid) + '; '
FROM master..sysprocesses 
WHERE spid > 50 AND dbid = DB_ID('<Your_DB_Name>')
EXEC(@kill);

GO
SET DEADLOCK_PRIORITY HIGH
ALTER DATABASE [<Your_DB_Name>] SET MULTI_USER WITH NO_WAIT
ALTER DATABASE [<Your_DB_Name>] SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

Pour quitter le mode mono-utilisateur, essayez:

ALTER DATABASE [my_db] SET MULTI_USER

Pour revenir en mode mono-utilisateur, vous pouvez utiliser:

ALTER DATABASE [my_db] SET SINGLE_USER

1. Faites un clic droit sur votre base de données dans la section bases de données
2. Sélectionnez "Propriétés"
3. Sélectionnez la page "Options"
4. Faites défiler vers le bas "Autres options" et modifiez le champ "Restreindre l'accès"

J'ai essayé ça marche

ALTER DATABASE dbName SET MULTI_USER WITH ROLLBACK IMMEDIATE

J'ai eu le même problème, et le session_id à tuer a été trouvé en utilisant cette requête:

Select request_session_id From sys.dm_tran_locks Where resource_database_id=DB_ID('BI_DB_Rep');

Appuyez sur CTRL + 1

trouvez le processus qui verrouille votre base de données. Recherchez dans la colonne dbname votre db et notez le spid. Vous devez maintenant exécuter cette instruction:

kill <your spid>
ALTER DATABASE <your db> SET MULTI_USER;

Ce qui suit a fonctionné pour moi:

USE [master]
SET DEADLOCK_PRIORITY HIGH
exec sp_dboption '[StuckDB]', 'single user', 'FALSE';
ALTER DATABASE [StuckDB] SET MULTI_USER WITH NO_WAIT
ALTER DATABASE [StuckDB] SET MULTI_USER WITH ROLLBACK IMMEDIATE

Une autre option consiste à:

• mettre la base de données hors ligne; dans SMSS, cliquez avec le bouton droit sur la base de données et choisissez Take Offline, cochez 'Drop all connections'
• courir ALTER DATABASE [Your_Db] SET MULTI_USER

Au cas où quelqu'un tomberait sur ce fil, voici une solution pare-balles à SQL Server coincé en MODE UTILISATEUR UNIQUE

- Obtenez l'ID de processus (spid) de la connexion que vous devez tuer
- Remplacez 'DBName' par le nom réel de la base de données

SELECT sd.[name], sp.spid, sp.login_time, sp.loginame 
FROM sysprocesses sp 
INNER JOIN sysdatabases sd on sp.dbid = sd.dbid  
WHERE sd.[name] = 'DBName'

Comme alternative, vous pouvez également utiliser la commande "sp_who" pour obtenir le "spid" de la connexion ouverte:

- Ou utilisez ce SP à la place

exec sp_who

- Exécutez ensuite ce qui suit et remplacez [spid] et [DBName] par des valeurs correctes

KILL SpidToKillGoesHere
GO

SET DEADLOCK_PRIORITY HIGH
GO

ALTER DATABASE [DBName] SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

Je ne sais pas si cela aide quelqu'un, mais j'ai eu le même problème et je n'ai pas pu trouver le processus qui me tenait. J'ai fermé SSMS et arrêté tous les services atteignant l'instance locale. Puis une fois que je suis rentré et que j'ai exécuté l'exécutable sp_who2, il m'a montré le coupable. J'ai tué le processus et j'ai réussi à faire fonctionner Multi_User, puis à redémarrer les services. Nous avons eu IIS le frapper toutes les quelques minutes / secondes à la recherche de certains packages.

J'ai rencontré le même problème ce matin. Cela s'est avéré être un problème simple. J'avais une fenêtre de requête ouverte qui était définie sur la base de données mono-utilisateur dans l'explorateur d'objets. La procédure stockée sp_who2 n'a pas montré la connexion. Une fois que je l'ai fermé, j'ai pu le régler sur

Ajout à la réponse Jespers , pour être encore plus efficace:

SET DEADLOCK_PRIORITY 10;-- Be the top dog.

SET DEADLOCK_PRIORITY HIGH les usages DEADLOCK_PRIORITY de 5.

Ce qui se passe, c'est que les autres processus obtiennent une fissure dans la base de données et, si votre processus a un DEADLOCK_PRIORITY , il perd la course.

Cela évite de trouver et de tuer l'autre spid (ce qui pourrait devoir être fait plusieurs fois).

Il est possible que vous deviez exécuter ALTER DATABASEplusieurs fois (mais Jesper le fait). Code modifié:

USE [master]
SET DEADLOCK_PRIORITY HIGH
exec sp_dboption '[StuckDB]', 'single user', 'FALSE';
ALTER DATABASE [StuckDB] SET MULTI_USER WITH NO_WAIT
ALTER DATABASE [StuckDB] SET MULTI_USER WITH ROLLBACK IMMEDIATE

Utilisez ce script

exec sp_who

Rechercher la colonne dbname et spid

maintenant exécuter

kill spid 
go
ALTER DATABASE [DBName]
SET MULTI_USER;

Aujourd'hui, j'ai rencontré le même problème lorsque ma base de données est passée du mode multi-utilisateur au mode mono-utilisateur et cela m'a finalement empêché de publier la base de données.

Afin de résoudre ce problème, j'ai dû fermer toutes les instances de Visual Studio et exécuter la commande ci-dessous dans la fenêtre de requête Sql Server -

USE [Your_Database_Name]; ALTER DATABASE [Your_Database_Name] SET MULTI_USER GO

Cette commande a changé la base de données de mono-utilisateur à multi-utilisateur et par la suite, j'ai pu publier avec succès.

Même moi, je rencontre le même problème, pas en mesure de trouver des connexions actives à my_db pour le tuer, mais montre toujours la même erreur. Je finis par déconnecter toutes les connexions SSMS possibles pour toute base de données sur le serveur, créer une nouvelle connexion à partir de SSMS et la changer en multi-utilisateur.

-- Actual Code to change my_db to multi user mode
USE MASTER;
GO
ALTER DATABASE [my_db] SET MULTI_USER

Remarque: cela semble être un bogue possible dans SQL Server 2005!

Nous venons de vivre cela dans SQL 2012. Un processus de réplication s'est déclenché lorsque nous avons tué la session d'origine qui la définissait sur un seul utilisateur. Mais sp_who2 n'a pas montré ce nouveau processus attaché à la base de données. La fermeture de SSMS et sa réouverture nous ont ensuite permis de voir ce processus dans la base de données et nous avons ensuite pu le tuer et passer immédiatement en mode multi-utilisateurs et cela a fonctionné.

Je ne peux pas travailler sur la logique derrière cela, mais cela semble être un bogue dans SSMS et se manifeste toujours dans SQL 2012.

utiliser le maître

ALLER

sélectionnez d.name, d.dbid, spid, login_time, nt_domain, nt_username, loginame from sysprocesses p inner join sysdatabases d on p.dbid = d.dbid where d.name = 'database name'

kill 568 - kill spid

ALTER DATABASE nom de la base de données '

SET MULTI_USER go