Esci dalla modalità utente singolo

Attualmente, il mio database è in modalità utente singolo. Quando provo ad espandere il database, ricevo un errore:

Il database "my_db" non è accessibile. (ObjectExplorer)

Inoltre, quando provo a eliminare il database, ottengo l'errore:

Al momento non è possibile apportare modifiche allo stato o alle opzioni del database 'my_db'. Il database è in modalità utente singolo e un utente è attualmente connesso ad esso.

Come uscire dalla modalità utente singolo? Non ho nessun utente che utilizza questo database.

Quando provo a navigare nel mio sito con IIS, l'errore che ottengo è:

È stata generata un'eccezione non gestita durante l'esecuzione della richiesta Web corrente. Le informazioni relative all'origine e alla posizione dell'eccezione possono essere identificate utilizzando la traccia dello stack delle eccezioni riportata di seguito.

Sento che la modalità monoutente sta causando questo.

SSMS in generale utilizza diverse connessioni al database dietro le quinte.

Sarà necessario interrompere queste connessioni prima di modificare la modalità di accesso.

Innanzitutto, assicurati che Esplora oggetti sia indirizzato a un database di sistema come master.

In secondo luogo, eseguire uno sp_who2 e trovare tutte le connessioni al database 'my_db'. Uccidere tutte le connessioni facendo KILL { session id }dove ID sessione è SPIDelencato da sp_who2.

In terzo luogo, aprire una nuova finestra di query.

Eseguire il codice seguente.

-- Start in master
USE MASTER;

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

Vedi il mio articolo sul blog sulla gestione dei file di database. Questo è stato scritto per lo spostamento di file, ma la gestione degli utenti è la stessa.

Innanzitutto, trova e KILLtutti i processi che sono stati attualmente in esecuzione.

Quindi, eseguire quanto segue T-SQLper impostare il database in MULTI_USERmodalità.

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

Per uscire dalla modalità Utente singolo, prova:

ALTER DATABASE [my_db] SET MULTI_USER

Per tornare alla modalità Utente singolo, è possibile utilizzare:

ALTER DATABASE [my_db] SET SINGLE_USER

1. Fare clic con il tasto destro del mouse sul database nella sezione database
2. Seleziona "Proprietà"
3. Seleziona la pagina "Opzioni"
4. Scorri verso il basso "Altre opzioni" e modifica il campo "Limita accesso"

Ho provato che funziona

ALTER DATABASE dbName SET MULTI_USER WITH ROLLBACK IMMEDIATE

Ho avuto lo stesso problema e il session_id da uccidere è stato trovato usando questa query:

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

Premi CTRL + 1

trova il processo che blocca il tuo database. Cerca nella colonna dbname il tuo db e osserva lo spid. Ora devi eseguire questa affermazione:

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

Per me ha funzionato:

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

Un'altra opzione è:

• portare offline il database; in SMSS, fai clic con il pulsante destro del mouse sul database e scegli Porta offline, seleziona "Elimina tutte le connessioni"
• correre ALTER DATABASE [Your_Db] SET MULTI_USER

Nel caso in cui qualcuno si imbatta in questo thread, ecco una soluzione a prova di proiettile a SQL Server bloccata in MODALITÀ UTENTE SINGOLO

- Ottieni l'ID del processo (spid) della connessione che devi
interrompere - Sostituisci 'DBName' con il nome effettivo del DB

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'

In alternativa, puoi anche usare il comando "sp_who" per ottenere lo "spid" della connessione aperta:

- Oppure usa questo SP invece

exec sp_who

- Quindi eseguire quanto segue e sostituire [spid] e [DBName] con i valori corretti

KILL SpidToKillGoesHere
GO

SET DEADLOCK_PRIORITY HIGH
GO

ALTER DATABASE [DBName] SET MULTI_USER WITH ROLLBACK IMMEDIATE
GO

Non sono sicuro che questo aiuti qualcuno, ma ho avuto lo stesso problema e non sono riuscito a trovare il processo che mi stava trattenendo. Ho chiuso SSMS e ho interrotto tutti i servizi colpendo l'istanza locale. Poi una volta rientrato e ho eseguito il comando exec sp_who2, mi ha mostrato il colpevole. Ho interrotto il processo e sono riuscito a far funzionare Multi_User, quindi ho riavviato i servizi. Abbiamo avuto IIS a colpirlo ogni pochi minuti / secondi alla ricerca di determinati pacchetti.

Ho riscontrato lo stesso problema questa mattina. Si è rivelato essere un problema semplice. Avevo una finestra di query aperta che era impostata sul database utente singolo in Esplora oggetti. La procedura memorizzata sp_who2 non ha mostrato quindi la connessione. Una volta chiuso, sono stato in grado di impostarlo su

Aggiungendo alla risposta di Jespers , per essere ancora più efficace:

SET DEADLOCK_PRIORITY 10;-- Be the top dog.

SET DEADLOCK_PRIORITY HIGHusi DEADLOCK_PRIORITYdi 5.

Quello che sta succedendo è che gli altri processi ottengono una crepa nel database e, se il processo ha un valore inferiore DEADLOCK_PRIORITY, allora perde la corsa.

Ciò evita di trovare e uccidere l'altro spid (che potrebbe essere necessario eseguire più volte).

È possibile che tu debba correre ALTER DATABASEpiù di una volta (ma lo fa Jesper). Codice modificato:

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

Usa questo script

exec sp_who

Trova la colonna dbname e spid

ora esegui

kill spid 
go
ALTER DATABASE [DBName]
SET MULTI_USER;

Oggi ho affrontato lo stesso problema in cui il mio database è stato cambiato dalla modalità multiutente alla modalità utente singolo e questo alla fine mi ha impedito di pubblicare il database.

Per risolvere questo problema, ho dovuto chiudere tutte le istanze di Visual Studio ed eseguire il comando seguente nella finestra delle query di SQL Server -

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

Questo comando ha cambiato il DB da Utente singolo a Utente multiplo e, successivamente, sono stato in grado di pubblicare con successo.

Anche io mi imbatto nello stesso problema, non riesco a trovare connessioni attive a my_db per ucciderlo ma mostra ancora lo stesso errore. Finisco per disconnettere tutte le possibili connessioni SSMS per qualsiasi database sul Server, creo una nuova connessione da SSMS e la cambio in Multiutente.

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

Nota: questo sembra essere un possibile bug in SQL Server 2005!

L'abbiamo appena sperimentato in SQL 2012. È iniziato un processo di replica quando abbiamo interrotto la sessione originale che lo ha impostato su singolo utente. Ma sp_who2 non ha mostrato quel nuovo processo collegato al DB. La chiusura di SSMS e la riapertura ci hanno quindi permesso di vedere questo processo sul database e quindi abbiamo potuto ucciderlo e passare immediatamente alla modalità multiutente e ha funzionato.

Non riesco a capire la logica dietro questo, ma sembra essere un bug in SSMS e si sta ancora manifestando in SQL 2012.

usa il maestro

PARTIRE

selezionare d.name, d.dbid, spid, login_time, nt_domain, nt_username, loginame da sysprocesses p interno sysdatabase d su p.dbid = d.dbid dove d.name = 'nome database'

kill 568 - kill spid

Nome database ALTER DATABASE '

SET MULTI_USER vai