SQL Server: Base de datos atascada en estado de "Restauración"

Tuve esta situación restaurando una base de datos a una instancia de SQL Server 2005 Standard Edition usando Symantec Backup Exec 11d. Después de que el trabajo de restauración se completó, la base de datos permaneció en un estado de "Restauración". No tenía problemas de espacio en disco the la base de datos simplemente no salió del estado de "Restauración".

Ejecuté la siguiente consulta contra la instancia de SQL Server y descubrí que la base de datos se podía usar inmediatamente:

RESTORE DATABASE <database name> WITH RECOVERY

Así es como lo haces:

1. Detener el servicio (MSSQLSERVER);
2. Cambie el nombre o elimine la Base de datos y los archivos de registro (C:\Program Archivos \ Microsoft SQL Server\MSSQL.1\MSSQL \ Data...) o donde quiera que tenga los archivos;
3. Iniciar el servicio (MSSQLSERVER);
4. Eliminar la base de datos con problema;
5. Restaure la base de datos de nuevo.

¡Buena suerte!

Tuve un incidente similar al detener un servidor secundario de envío de registros. Después del comando para eliminar el servidor del envío de registros y detener el envío de registros desde el servidor primario, la base de datos en el servidor secundario se atascó en la restauración del estado después del comando

RESTORE DATABASE <database name> WITH RECOVERY

Los mensajes de la base de datos:

RESTAURAR LA BASE de DATOS procesada con éxito 0 páginas en 18.530 segundos (0.000 MB / seg).

La base de datos fue utilizable de nuevo después de esos 18 segundos.

Tuve un problema similar con la restauración usando SQL Management Studio. Traté de restaurar una copia de seguridad de la base de datos a una nueva con un nombre diferente. Al principio esto falló y después de arreglar los nombres de archivo de la nueva base de datos se realizó con éxito - en cualquier caso, el problema que estoy describiendo volvió a ocurrir incluso si lo hice bien desde la primera vez. Por lo tanto, después de la restauración, la base de datos original se mantuvo con una (Restauración...) junto a su nombre. Teniendo en cuenta las respuestas del foro anterior (Bhusan) He intentado ejecutar en el editor de consultas en el lado de lo siguiente:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

Que solucionó el problema. Estaba teniendo problemas al principio debido al nombre de la base de datos que contenía caracteres especiales. Resolví esto agregando comillas dobles alrededor-comillas simples no funcionarían dando una " Sintaxis incorrecta cerca ..." error.

Esta fue la solución mínima que he intentado resolver este problema (base de datos atascada en estado de restauración) y espero que se pueda aplicar a más casos.

OK, tengo un problema similar y exactamente como fue en el caso de Pauk, fue causado por el servidor que se queda sin espacio en disco mientras se restaura y por lo tanto causó un estado de restauración permanente. ¿Cómo terminar este estado sin detener los servicios de SQL Server?

He encontrado una solución :)

Drop database *dbname*

CON la opción de RECUPERACIÓN se usa por defecto cuando se ejecutan los comandos RESTORE DATABASE/RESTORE LOG. Si está atascado en el proceso de "restauración", puede devolver una base de datos al estado en línea ejecutando:

RESTORE DATABASE YourDB WITH RECOVERY
GO

Si hay una necesidad de restaurar varios archivos, los comandos CLI requieren CON NORECOVERY y CON RECOVERY respectivamente-solo el último archivo en el comando debe tener CON RECOVERY para traer de vuelta la base de datos en línea:

RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'
WITH NORECOVERY
GO
RESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'
WITH RECOVERY
GO

Puede usar el asistente de SQL Server Management Studio también:

También hay un proceso de restauración virtual, pero tendrá que usar soluciones de terceros. Por lo general, puede utilizar una copia de seguridad de la base de datos como base de datos en línea en vivo. ApexSQL e Idera tienen sus propias soluciones. Revisión de SQL Hammer sobre ApexSQL Restore. La restauración virtual es una buena solución si se trata de un gran número de copias de seguridad. El proceso de restauración es mucho más rápido y también puede ahorrar mucho espacio en la unidad de disco. Puedes echar un vistazo a la infografía aquí para una comparación.

Esto puede ser bastante obvio, pero me hizo tropezar justo ahora:

Si está tomando una copia de seguridad de tail-log, este problema también puede ser causado por tener esta opción marcada en el asistente de restauración de SSMS: "Dejar la base de datos de origen en el estado de restauración (CON NORECOVERY)"

Descubrí por qué.

Si el cliente que emitió el comando RESTORE DATABASE se desconecta durante la restauración, la restauración se bloqueará.

Es extraño que el servidor, cuando se le dice que restaure una base de datos por una conexión de cliente, no termine la restauración a menos que el cliente permanezca conectado todo el tiempo.

Este funcionó :

Http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/8dd1b91d-3e14-4486-abe6-e3a550bfe457

Tuve una situación en la que mi base de datos mostraba estado de restauración y no podía ejecutar ninguna consulta y no podía conectarse con nuestro software.

Lo que hice para salir de esta situación es:

1. Detenga todos los servicios relacionados con SQL de los servicios de Windows.

2. Abrí la carpeta de DATOS donde el Ldf y Mdf archivos reside en el directorio SQL, normalmente es como : "C:\Program Archivos***********\MSSQL \ DATA

3. Luego copié los archivos Ldf y Mdf de la base de datos: [nombre db].mdf y [db name]_log.ldf

Copié ambos archivos a otra carpeta.

1. Luego comencé todos los servicios relacionados con SQL (en el paso 1) de nuevo desde servicios de Windows.

2. Iniciado mi MS SQL Management studio con normal sesión.

3. Haga clic derecho en la base de datos culpable y pulse ELIMINAR (para eliminar la base de datos en absoluto).

4. Todos los archivos LDF y MDF relacionados con esta base de datos han pasado de la carpeta de DATOS (mencionada en el paso 2).

5. Se creó una nueva base de datos con el mismo nombre (el mismo nombre de la que eliminé en el paso 6 - la base de datos culpable).

6. Luego [nombre de la base de datos] - > clic derecho -> tareas - > Desconectar.

7. Luego copié tanto el archivos (del paso 3) de vuelta a la carpeta de DATOS (paso 2).

8. [nombre de la base de datos] - > clic derecho - > tareas - > Poner en línea.

Tuve una . en mi nombre de base de datos, y la consulta no funcionó debido a eso (diciendo sintaxis incorrecta cerca de '.') Entonces me di cuenta de que necesito un corchete para el nombre:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

He tenido este problema cuando también recibí un error TCP en el registro de eventos...

Suelte la base de datos con sql o haga clic derecho sobre ella en el administrador " eliminar" Y restaurar de nuevo.

Realmente he comenzado a hacer esto por defecto. Script la caída de la base de datos, recrear y luego restaurar.

Por defecto, cada RESTORE DATABASE viene con RECOVERY configurar. Las opciones' NORECOVERY', básicamente le dice al servidor SQL que la base de datos está esperando más archivos de restauración (podría ser un archivo DIFF y un archivo LOG y, podría incluir un archivo de copia de seguridad de tail-log, si es posible). Las opciones de' RECUPERACIÓN', terminar todas las transacciones y dejar que la base de datos listo para realizar transacciones.

Así que:

1. si su base de datos está configurada con SIMPLE modelo de recuperación, solo puede realice una restauración COMPLETA con la opción NORECOVERY, cuando tenga una copia de seguridad DIFF. No se permiten copias de seguridad LOG en la base de datos del modelo de recuperación SIMPLE.
2. De lo contrario, si su base de datos está configurada con FULL o BULK-LOGED recovery model, puede realizar una restauración FULL seguida de la opción NORECOVERY, luego realice una restauración DIFF seguida de NORECOVERY, y, por último, realice la restauración LOG con la opción RECOVERY.

Recuerde, LA ÚLTIMA CONSULTA DE RESTAURACIÓN DEBE TENER RECOVERY OPCIÓN. Podría ser una forma explícita o no. En las termas de T-SQL, la situación:

1. USE [master] GO RESTORE DATABASE Database_name FROM DISK = N'\\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD, RECOVERY -- This option could be omitted. GO

CON la opción REEMPLAZAR debe utilizarse con precaución, ya que puede conducir a la pérdida de datos

O, si realiza una copia de seguridad COMPLETA y DIFF, puede usar esta

USE [master]
GO
RESTORE DATABASE Database_name
  FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
   NOUNLOAD,NORECOVERY
GO
RESTORE DATABASE Database_name
  FROM DISK =N'\\path_of_**diff**backup_file.bak' WITH FILE = 1, 
 NOUNLOAD, RECOVERY
GO

1. USE [master] GO -- Perform a Tail-Log backup, if possible. BACKUP LOG Database_name GO -- Restoring a FULL backup RESTORE DATABASE Database_name FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, NOUNLOAD,NORECOVERY GO -- Restore the last DIFF backup RESTORE DATABASE Database_name FROM DISK = N'\\path_of_DIFF_backup_file.bak' WITH FILE = 1, NORECOVERY,NOUNLOAD GO -- Restore a Log backup RESTORE LOG Database_name FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2, RECOVERY, NOUNLOAD GO

Por supuesto, puede realizar una restauración con la opción STATS = 10 esto le indica al servidor SQL que informe cada 10% completado.

Si lo prefiere, puede observar el proceso o restaurar en consulta basada en tiempo real. Como sigue:

USE[master]
GO
SELECT session_id AS SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time 
    FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a 
        WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
GO

Espero que esta ayuda.

También puede haber problemas para eliminar una base de datos atascada si la instantánea está habilitada. Para mí esto funcionó:

1. Primero seguí Tipu Delacablu pasos (leer algunos posts)
2. ejecutar comando: soltar base de datos[su base de datos], que le dará un error que le dice el nombre de la base de datos de instantáneas
3. ejecutar comando: suelte database [snapshot database] y, a continuación, vuelva a ejecutar el comando en el paso 2.

En mi caso, fue suficiente con soltar la base de datos que estaba colgando en estado "Restoring..." con el comando SQL

 drop database <dbname> 

En una ventana de consulta.

Luego hice clic con el botón derecho en Databases y seleccioné Refresh que eliminó la entrada en Management Studio. Después hice una nueva restauración que funcionó bien (tenga en cuenta que ponerlo fuera de línea no funcionó, un reinicio del servicio SQL no funcionó, un reinicio del servidor no funcionó tan bien).

¿Ha intentado ejecutar SOLO una VERIFICACIÓN? Sólo para asegurarme de que es una copia de seguridad de sonido.

Http://msdn.microsoft.com/en-us/library/ms188902.aspx

1. Vamos a comprobar y ejecutar SQL Agent Service en primer lugar.

2. Usando el siguiente T-SQL:

   SELECCIONE el nombre del archivo DEL maestro.sys.sysaltfiles DONDE dbid = DB_ID ('db_name');

3. Usando T-SQL continuamente:

   RESTORE DATABASE FROM DISK = 'DB_path' CON REINICIAR, REEMPLAZAR;

Espero que esta ayuda!

Todas las opciones basadas en RECUPERACIÓN no funcionaron para mí.

Lo que hizo fue hacer la restauración completa desde Management Studio.

USE [master]
RESTORE DATABASE Sales_SSD
FROM  DISK = N'D:\databaseBackups02\Daily_Sales_20150309_0941.bak' 
WITH  FILE = 1,  
MOVE N'Sales_Data' TO N'C:\Data\SSD\Sales.mdf',  
MOVE N'Sales_Log' TO N'C:\Data\SSD\Sales_1.ldf',  
NOUNLOAD,  REPLACE,  STATS = 5

Tuve el mismo problema... aunque no sé por qué mi base de datos experimentó este problema ya que mi unidad no estaba llena... Es como si se hubiera corrompido o algo así. Probé todo lo anterior, ninguno de ellos funcionó completamente, especialmente pensé que la sugerencia de detener el servicio y eliminar los archivos mdf y ldf funcionaría... pero todavía se congeló en restaurar?

Terminé resolviendo esto eliminando los archivos como se mencionó, pero en lugar de intentar restaurar la base de datos nuevamente copié fresh .mdf y .archivos ldf y Adjuntos estos usando el asistente para Adjuntos de Front End. Alivio, funcionó!!

Me tomó UNA ETERNIDAD copiar los nuevos archivos ya que estoy usando una Máquina Virtual... así que copiar y pegar usando el portapapeles tomó como una hora, así que solo recomendaría esto como un último intento.

Tengo el MyDbName (Restoring...) caso debido al límite de licencia de SQL Express.

En el archivo de registro, encontré esto:

CREATE DATABASE or ALTER DATABASE failed because the resulting el tamaño acumulado de la base de datos excedería su límite de licencia de 10240 MB por base de datos.

Así que si está tratando de restaurar una base de datos más grande, necesita cambiar su servidor SQL Express a Developer edition para instancia.