Tiempo de espera extremo al desconectar una base de datos de SQL Server

Estoy tratando de realizar un mantenimiento fuera de línea (restauración de la base de datos de desarrollo desde una copia de seguridad en vivo) en mi base de datos de desarrollo, pero el comando 'Desconectar' a través de SQL Server Management Studio está funcionando extremadamente lento, en el orden de 30 minutos más ahora. Estoy a punto de perder el control y parece que no puedo encontrar referencias en línea sobre lo que podría estar causando el problema de la velocidad o cómo solucionarlo.

Algunos sitios han sugerido que las conexiones abiertas a la base de datos causan esta desaceleración, pero la única aplicación que usa esta base de datos es la instancia IIS de mi máquina de desarrollo, y el servicio se detiene; no hay más conexiones abiertas.

¿Qué podría estar causando esta desaceleración y qué puedo hacer para acelerarla?

Después de algunas búsquedas adicionales (nuevos términos de búsqueda inspirados en la respuesta de gbn y el comentario de u07ch sobre la respuesta de KMike) encontré esto, que se completó con éxito en 2 segundos:

ALTER DATABASE <dbname> SET OFFLINE WITH ROLLBACK IMMEDIATE

(Actualizar)

Cuando esto todavía falla con el siguiente error, puede solucionarlo según lo inspirado en esta publicación de blog :

ALTER DATABASE falló porque no se pudo colocar un bloqueo en la base de datos 'dbname' Vuelva a intentarlo más tarde.

puede ejecutar el siguiente comando para averiguar quién mantiene un bloqueo en su base de datos:

EXEC sp_who2

Y use lo SPIDque encuentre en el siguiente comando:

KILL <SPID>

Luego ejecute el ALTER DATABASEcomando nuevamente. Ahora debería funcionar.

Lo más probable es que haya una conexión con la base de datos desde algún lugar (un raro ejemplo: actualización estadística asincrónica )

Para buscar conexiones, use sys.sysprocesses

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

Para forzar las desconexiones, use ROLLBACK INMEDIATE

USE master
ALTER DATABASE MyDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE

¿Tiene alguna ventana abierta de SQL Server Management Studio que esté conectada a esta base de datos?

Póngalo en modo de usuario único e intente nuevamente.

En mi caso, después de esperar tanto para que terminara, no tuve paciencia y simplemente cerré el estudio de administración. Antes de salir, mostró el mensaje de éxito, db está fuera de línea. Los archivos estaban disponibles para cambiar el nombre.

ejecutar el procedimiento almacenado sp_who2

Esto le permitirá ver si hay bloqueos de bloqueo ... matarlos debería solucionarlo.

En SSMS: haga clic derecho en el icono del servidor SQL, Monitor de actividad. Procesos abiertos. Encuentra el procesado conectado. Haz clic derecho en el proceso, Kill.

cada vez que te encuentres con este tipo de cosas, siempre debes pensar en tu registro de transacciones. La declaración alter db con reversión inmediata indica que este es el caso. Mira esto: http://msdn.microsoft.com/en-us/library/ms189085.aspx

Hágase con puntos de control, etc. Debe decidir si vale la pena guardar las transacciones en su registro o no y luego elegir el modo para ejecutar su base de datos en consecuencia. Realmente no hay razón para que tengas que esperar, pero tampoco hay razón para que pierdas datos: puedes tener ambas.

Cerrar la instancia de SSMS (SQL Service Manager) desde el que se realizó la solicitud resolvió el problema para mí .....

En mi caso, había visto algunas tablas en el DB antes de ejecutar esta acción. Mi cuenta de usuario tenía una conexión activa a este DB en SSMS. Una vez que me desconecté del servidor en SSMS (dejando abierto el cuadro de diálogo 'Desconectar la base de datos'), la operación tuvo éxito.

Para evitar esto, detuve el sitio web que estaba conectado a la base de datos en IIS e inmediatamente el panel 'congelado' desconectar db 'se descongeló.

Intenté todas las sugerencias a continuación y nada funcionó.

1. EXEC sp_who

2. Matar <SPID>

3. ALTER DATABASE SET SINGLE_USER WITH Rollback Inmediate

   ALTERAR BASE DE DATOS DESCONECTADA CON ROLLBACK INMEDIATA

   Resultado: los dos comandos anteriores también se atascaron.

4) Haga clic con el botón derecho en la base de datos -> Propiedades -> Opciones Establecer la base de datos de solo lectura en True Haga clic en 'Sí' en el cuadro de diálogo que advierte que SQL Server cerrará todas las conexiones a la base de datos.

Resultado: la ventana se atascó al ejecutarse.

Como último recurso, reinicié el servicio del servidor SQL desde el administrador de configuración y luego ejecuté ALTER DATABASE SET OFFLINE WITH ROLLBACK INMEDIATE. Funcionó a las mil maravillas

Además, cierre cualquier ventana de consulta que pueda tener abierta y que esté conectada a la base de datos en cuestión;)

En SSMS, configure la base de datos en solo lectura y luego vuelva. Las conexiones se cerrarán, lo que libera las cerraduras.

En mi caso, había un sitio web que tenía conexiones abiertas a la base de datos. Este método fue bastante fácil:

1. Haga clic derecho en la base de datos -> Propiedades -> Opciones
2. Establecer Database Read-Onlyen verdadero
3. Haga clic en 'Sí' en el cuadro de diálogo que advierte que SQL Server cerrará todas las conexiones a la base de datos.
4. Vuelva a abrir Opciones y desactive la opción de solo lectura
5. Ahora intente renombrar la base de datos o desconectarla.

Para mí, solo tenía que ir al Monitor de actividad laboral y detener dos cosas que estaban procesando. Luego se desconectó de inmediato. En mi caso, sin embargo, sabía cuáles eran esos 2 procesos y que estaba bien detenerlos.

En mi caso, la base de datos estaba relacionada con una instalación antigua de Sharepoint. Al detener e inhabilitar los servicios relacionados en el administrador del servidor, se "desconectó" la acción fuera de línea, que había estado ejecutándose durante 40 minutos, y se completó de inmediato.

Es posible que desee verificar si algún servicio está utilizando actualmente la base de datos.

La próxima vez, desde el cuadro de diálogo Desconectar, recuerde marcar la casilla de verificación 'Descartar todas las conexiones activas'. También estaba en SQL_EXPRESS en una máquina local sin conexiones, pero esta desaceleración ocurrió a menos que marque esa casilla de verificación.

En mi caso detuve el servidor Tomcat. entonces inmediatamente el DB se desconectó.