Tempo di attesa estremo quando si porta offline un database di SQL Server

Sto cercando di eseguire un po 'di manutenzione offline (ripristino del database degli sviluppatori dal backup live) sul mio database degli sviluppatori, ma il comando "Take Offline" tramite SQL Server Management Studio sta funzionando molto lentamente, nell'ordine di 30 minuti più adesso. Sono quasi alla fine del mio ingegno e non riesco a trovare riferimenti online su ciò che potrebbe causare il problema di velocità o su come risolverlo.

Alcuni siti hanno suggerito che le connessioni aperte al database causano questo rallentamento, ma l'unica applicazione che utilizza questo database è l'istanza IIS della mia macchina di sviluppo e il servizio è interrotto: non ci sono più connessioni aperte.

Cosa potrebbe causare questo rallentamento e cosa posso fare per accelerarlo?

Dopo alcune ricerche aggiuntive (nuovi termini di ricerca ispirati alla risposta di gbn e al commento di u07ch sulla risposta di KMike) ho trovato questo, che è stato completato con successo in 2 secondi:

ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE

(Aggiornare)

Se l'errore persiste con il seguente errore, puoi risolverlo come ispirato da questo post del blog :

ALTER DATABASE non è riuscito perché non è stato possibile posizionare un blocco sul database 'dbname' Riprovare più tardi.

puoi eseguire il comando seguente per scoprire chi mantiene un blocco sul tuo database:

EXEC sp_who2

E usa tutto ciò SPIDche trovi nel seguente comando:

KILL <SPID>

Quindi eseguire ALTER DATABASEnuovamente il comando. Ora dovrebbe funzionare.

Molto probabilmente esiste una connessione al DB da qualche parte (un raro esempio: aggiornamento statistico asincrono )

Per trovare le connessioni, utilizzare sys.sysprocesses

USE master
SELECT * FROM sys.sysprocesses WHERE dbid = DB_ID('MyDB')

Per forzare le disconnessioni, utilizzare ROLLBACK IMMEDIATE

USE master
ALTER DATABASE MyDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Hai delle finestre aperte di SQL Server Management Studio connesse a questo DB?

Mettilo in modalità utente singolo, quindi riprova.

Nel mio caso, dopo aver aspettato così tanto che finisse, non ho avuto pazienza e ho semplicemente chiuso lo studio di gestione. Prima di uscire, mostrava il messaggio di successo, db non è in linea. I file erano disponibili per rinominare.

eseguire la procedura memorizzata sp_who2

Questo ti permetterà di vedere se ci sono blocchi di blocco .. uccidere i loro dovrebbe risolverlo.

In SSMS: fare clic con il pulsante destro del mouse sull'icona del server SQL, Activity Monitor. Processi aperti. Trova il elaborato connesso. Fai clic con il tasto destro del mouse sul processo, Kill.

ogni volta che ti imbatti in questo tipo di cose dovresti sempre pensare al tuo registro delle transazioni. Lo statuto alter db con rollback immediato indica che questo è il caso. Dai un'occhiata a: http://msdn.microsoft.com/en-us/library/ms189085.aspx

Osserva i checkpoint, ecc. Devi decidere se vale la pena salvare le transazioni nel tuo registro e quindi scegliere la modalità per eseguire il tuo db di conseguenza. Non c'è davvero alcun motivo per cui devi aspettare, ma non c'è nemmeno motivo per perdere dati - puoi avere entrambi.

Chiudere l'istanza di SSMS (SQL Service Manager) da cui è stata effettuata la richiesta ha risolto il problema per me .....

Nel mio caso avevo esaminato alcune tabelle nel DB prima di eseguire questa azione. Il mio account utente aveva una connessione attiva a questo DB in SSMS. Una volta disconnesso dal server in SSMS (lasciando aperta la finestra di dialogo "Porta database offline") l'operazione è riuscita.

Per ovviare a questo, ho bloccato il sito Web che era collegato al db in IIS e immediatamente il pannello "congelato" "porta offline db" è stato sbloccato.

Ho provato tutti i suggerimenti di seguito e niente ha funzionato.

1. EXEC sp_who

2. Uccidi <SPID>

3. ALTER DATABASE SET SINGLE_USER CON Rollback immediato

   ALTER DATABASE SET OFFLINE CON ROLLBACK IMMEDIATO

   Risultato: entrambi i comandi precedenti sono stati bloccati.

4 Fare clic con il tasto destro del mouse sul database -> Proprietà -> Opzioni Imposta il database in sola lettura su True. Fare clic su "Sì" nella finestra di dialogo di avviso. SQL Server chiuderà tutte le connessioni al database.

Risultato: la finestra era bloccata durante l'esecuzione.

Come ultima risorsa, ho riavviato il servizio server SQL da Configuration Manager e quindi ho eseguito ALTER DATABASE SET OFFLINE CON ROLLBACK IMMEDIATE. Ha funzionato come un fascino

Inoltre, chiudi tutte le finestre di query che potresti avere che sono connesse al database in questione;)

In SSMS, impostare il database in sola lettura, quindi indietro. Le connessioni verranno chiuse, il che libera i blocchi.

Nel mio caso c'era un sito Web con connessioni aperte al database. Questo metodo è stato abbastanza semplice:

1. Fare clic con il tasto destro del mouse sul database -> Proprietà -> Opzioni
2. Impostare Database Read-Onlysu True
3. Fare clic su "Sì" nella finestra di dialogo di avviso. SQL Server chiuderà tutte le connessioni al database.
4. Riaprire Opzioni e disattivare la sola lettura
5. Ora prova a rinominare il database o portarlo offline.

Per me, dovevo solo entrare nel Job Activity Monitor e interrompere due cose che stavano elaborando. Quindi è andato offline immediatamente. Nel mio caso, però, sapevo quali fossero quei 2 processi e che era giusto fermarli.

Nel mio caso, il database era correlato a una vecchia installazione di Sharepoint. L'arresto e la disabilitazione dei servizi correlati nel server manager "hanno annullato" l'azione take offline, in esecuzione da 40 minuti, e si è conclusa immediatamente.

Potresti voler verificare se qualche servizio sta attualmente utilizzando il database.

La prossima volta, dalla finestra di dialogo Take Offline, ricordati di selezionare la casella di controllo "Elimina tutte le connessioni attive". Ero anche su SQL_EXPRESS sul computer locale senza connessioni, ma questo rallentamento è accaduto per me a meno che non avessi spuntato quella casella.

Nel mio caso ho arrestato il server Tomcat. quindi immediatamente il DB è andato offline.