Exit single-user mode

Question

Currently, my database is in Single User mode. When I try to expand me database, I get an error:

The database \'my_db\' is not accessible.(ObjectExplo

Answer 1

Adding to Jespers answer, to be even more effective:

SET DEADLOCK_PRIORITY 10;-- Be the top dog.

SET DEADLOCK_PRIORITY HIGH uses DEADLOCK_PRIORITY of 5.

What is happening is that the other processes get a crack at the database and, if your process has a lower DEADLOCK_PRIORITY, then it loses the race.

This obviates finding and killing the other spid (which might need to be done several times).

It is possible that you would need to run ALTER DATABASE more than once, (but Jesper does that). Modified code:

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

Answer 2

I ran across the same issue this morning. It turned out to be a simple issue. I had a query window open that was set to the single user database in the object explorer. The sp_who2 stored procedure did not show then connection. Once I closed it, I was able to set it to

Answer 3

First, find and KILL all the processes that have been currently running.

Then, run the following T-SQL to set the database in MULTI_USER mode.

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

Answer 4

I tried this is working

ALTER DATABASE dbName SET MULTI_USER WITH ROLLBACK IMMEDIATE

Answer 5

We just experienced this in SQL 2012. A replication process jumped in when we killed the original session that set it to single user. But sp_who2 did not show that new process attached to the DB. Closing SSMS and re-opening then allowed us to see this process on the database and then we could kill it and switch to multi_user mode immediately and that worked.

I can't work out the logic behind this, but it does appear to be a bug in SSMS and is still manifesting itself in SQL 2012.

Answer 6

1. Right click your database in databases section
2. Select "Properties"
3. Select "Options" page
4. Scroll down "Other options" and alter "Restrict access" field