SQL Server: Base de datos atascada en estado "Restaurando"

Hice una copia de seguridad de una base de datos:

BACKUP DATABASE MyDatabase
TO DISK = 'MyDatabase.bak'
WITH INIT --overwrite existing

Y luego trató de restaurarlo:

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE --force restore over specified database

Y ahora la base de datos está atascada en el estado de restauración.

Algunas personas han teorizado que es porque no había un archivo de registro en la copia de seguridad, y era necesario avanzar usando:

RESTORE DATABASE MyDatabase
WITH RECOVERY 

Excepto que, por supuesto, falla:

Msg 4333, Level 16, State 1, Line 1
The database cannot be recovered because the log was not restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Y exactamente lo que quiere en una situación catastrófica es una restauración que no funcionará.

La copia de seguridad contiene un archivo de datos y de registro:

RESTORE FILELISTONLY 
FROM DISK = 'MyDatabase.bak'

Logical Name    PhysicalName
=============   ===============
MyDatabase    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase.mdf
MyDatabase_log  C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF

Debe usar la WITH RECOVERYopción, con su RESTOREcomando de base de datos , para poner su base de datos en línea como parte del proceso de restauración.

Por supuesto, esto solo si no tiene la intención de restaurar ninguna copia de seguridad del registro de transacciones, es decir, solo desea restaurar una copia de seguridad de la base de datos y luego poder acceder a la base de datos.

Tu comando debería verse así,

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE,RECOVERY

Es posible que tenga más éxito con el asistente de restauración de la base de datos en SQL Server Management Studio. De esta manera, puede seleccionar las ubicaciones específicas de los archivos, la opción de sobrescritura y la opción WITH Recovery.

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 completar el trabajo de restauración, la base de datos permaneció en un estado de "Restauración". No tuve problemas de espacio en disco: la base de datos simplemente no salió del estado "Restaurando".

Ejecuté la siguiente consulta en la instancia de SQL Server y descubrí que la base de datos se volvió inmediatamente utilizable:

RESTORE DATABASE <database name> WITH RECOVERY

Así es como lo haces:

1. Detenga el servicio (MSSQLSERVER);
2. Cambie el nombre o elimine los archivos de base de datos y registro (C: \ Archivos de programa \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data ...) o donde tenga los archivos;
3. Inicie el servicio (MSSQLSERVER);
4. Eliminar la base de datos con problema;
5. Restaurar la base de datos nuevamente.

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 detuvo el envío del registro del servidor primario, la base de datos en el servidor secundario se atascó en el estado de restauración después del comando

RESTORE DATABASE <database name> WITH RECOVERY

Los mensajes de la base de datos:

RESTORE DATABASE procesó con éxito 0 páginas en 18.530 segundos (0.000 MB / seg).

La base de datos fue utilizable nuevamente 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 corregir los nombres de archivo de la nueva base de datos se realizó con éxito; en cualquier caso, el problema que describo volvió a ocurrir incluso si lo hice bien desde la primera vez. Entonces, después de la restauración, la base de datos original permaneció con un (Restaurando ...) al lado de su nombre. Teniendo en cuenta las respuestas del foro anterior (Bhusan), intenté ejecutar en el editor de consultas al lado lo siguiente:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

que solucionó el problema. Al principio tenía problemas debido al nombre de la base de datos que contenía caracteres especiales. Resolví esto agregando comillas dobles: las comillas simples no funcionarían dando un error de "Sintaxis incorrecta cerca de ...".

Esta fue la solución mínima que intenté 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 en el caso de Pauk, fue causado por el servidor que se queda sin espacio en disco durante la restauración y, por lo tanto, causó un estado de restauración permanente. ¿Cómo finalizar este estado sin detener los servicios de SQL Server?

He encontrado una solución :)

Drop database *dbname*

La opción CON RECUPERACIÓN se usa de forma predeterminada cuando se ejecutan los comandos RESTORE DATABASE / RESTORE LOG. Si está atrapado en el proceso de "restauración", puede recuperar una base de datos al estado en línea ejecutando:

RESTORE DATABASE YourDB WITH RECOVERY
GO

Si es necesario restaurar varios archivos, los comandos de la CLI requieren WITH NORECOVERY y WITH RECOVERY respectivamente; solo el último archivo en el comando debe tener WITH RECOVERY para que la base de datos vuelva a estar 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

También puede usar el asistente de SQL Server Management Studio:

También hay un proceso de restauración virtual, pero tendrá que usar soluciones de terceros. Por lo general, puede usar una copia de seguridad de la base de datos como una 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 grandes cantidades 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. Puede consultar la infografía aquí para ver una comparación.

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

Si está realizando una copia de seguridad del registro de cola, este problema también puede deberse a que esta opción esté marcada en el asistente de restauración de SSMS: "Deje la base de datos de origen en el estado de restauración (SIN RECUPERACIÓN)"

Me di cuenta por qué.

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

Es extraño que el servidor, cuando se le pide que restaure una base de datos mediante 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 un estado de restauración y no podía ejecutar ninguna consulta y no podía conectarme 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 DATA donde los archivos Ldf y Mdf residen en el directorio SQL, normalmente es como: "C: \ Archivos de programa *********** \ MSSQL \ DATA

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

Copié ambos archivos a otra carpeta.

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

5. Comencé mi estudio de MS SQL Management con inicio de sesión normal.

6. Haga clic derecho en la base de datos culpable y presione SUPR (para eliminar la base de datos).

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

8. Creé una nueva base de datos con el mismo nombre (el mismo nombre que eliminé en el paso 6: la base de datos culpable).

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

10. Luego copié ambos archivos (del paso 3) de vuelta a la carpeta DATA (paso 2).

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

Tuve un . en el nombre de mi base de datos, y la consulta no funcionó debido a eso (diciendo Sintaxis incorrecta cerca de '.') Luego me di cuenta de que necesito un paréntesis para el nombre:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

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

 drop database <dbname> 

en una ventana de consulta

Luego hice clic derecho en Bases de datos y seleccioné Actualizar que eliminó la entrada en Management Studio. Luego 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).

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

Suelte la base de datos con sql o haga clic derecho sobre ella en el administrador "eliminar" y restaure nuevamente.

De hecho, he comenzado a hacer esto por defecto. Script la caída de DB, recrear y luego restaurar.

Por defecto, todo RESTORE DATABASEviene con la RECOVERYconfiguración. Las opciones de 'NORECOVERY', básicamente le dicen al SQL Server que la base de datos está esperando más archivos de restauración (podría ser un archivo DIFF y un archivo LOG y, si es posible, podría incluir un archivo de respaldo de registro de cola). Las opciones de 'RECUPERACIÓN' finalizan todas las transacciones y dejan la base de datos lista para realizar transacciones.

Entonces:

1. si su base de datos está configurada con el modelo de recuperación SIMPLE , solo puede realizar una restauración COMPLETA con la NORECOVERYopción, cuando tiene una copia de seguridad DIFF . No se permiten copias de seguridad de LOG en la base de datos del modelo de recuperación SIMPLE .
2. De lo contrario, si su base de datos está configurada con un modelo de recuperación COMPLETO o REGISTRO A GRANEL , puede realizar una restauración COMPLETA seguida de la NORECOVERYopción, luego realizar un DIFF seguido de NORECOVERYy, por último, realizar la restauración del LOG con la RECOVERYopción.

Recuerde, LA ÚLTIMA CONSULTA DE RESTAURACIÓN DEBE TENER RECOVERYOPCIÓN . Podría ser una forma explícita o no. En términos 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

La opción CON REEMPLAZO debe usarse 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 esto

   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

 2. 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 que le dice al SQL Server que informe cada 10% completado.

Si lo prefiere, puede observar el proceso o restaurar en una consulta basada en tiempo real. De la siguiente manera:

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 esto ayude.

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í los pasos de Tipu Delacablu (lea algunas publicaciones)
2. comando de ejecución: soltar base de datos [su base de datos], que le dará un error que le indicará el nombre de la base de datos de instantáneas
3. ejecutar comando: soltar base de datos [base de datos de instantáneas], y luego ejecutar el comando en el paso 2 nuevamente.

¿Has intentado ejecutar un VERIFICAR SOLAMENTE? Solo para asegurarme de que sea una copia de seguridad de sonido.

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

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

En el archivo de registro, encontré esto:

CREATE DATABASE o ALTER DATABASE falló porque el tamaño de la base de datos acumulativa resultante excedería su límite de licencia de 10240 MB por base de datos.

Entonces, si está tratando de restaurar una base de datos más grande, debe cambiar su servidor SQL Express a la edición Developer, por ejemplo.

Se encontró con un problema similar al restaurar la base de datos usando el estudio de administración del servidor SQL y se quedó atascado en el modo de restauración. Después de varias horas de seguimiento de problemas, la siguiente consulta funcionó para mí. La siguiente consulta restaura la base de datos de una copia de seguridad existente a un estado anterior. Creo que el problema es tener el archivo .mdf y .log en el mismo directorio.

RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY

1. Deje que compruebe y ejecute el Servicio del Agente SQL en primer lugar.

2. Usando el siguiente T-SQL:

   SELECCIONE el nombre de archivo DESDE master.sys.sysaltfiles DONDE dbid = DB_ID ('db_name');

3. Usando T-SQL continuamente:

   RESTAURAR BASE DE DATOS DESDE DISCO = 'DB_path' CON REINICIAR, REEMPLAZAR;

¡Espero que esto ayude!

Todas las opciones basadas en WITH RECOVERY 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 disco no estaba lleno ... Es como si estuviera dañado o algo así. Intenté todo lo anterior, ninguno de ellos funcionó por completo, especialmente pensé que la sugerencia de detener el servicio y eliminar los archivos mdf y ldf funcionaría ... ¿pero todavía se congeló en la restauración?

Terminé resolviendo esto eliminando los archivos como se mencionó, pero en lugar de intentar restaurar la base de datos nuevamente, copié nuevos archivos .mdf y .ldf y los adjunté usando el asistente de archivos adjuntos de front-end. ¡Alivio, funcionó!

Me llevó SIEMPRE copiar los nuevos archivos ya que estoy usando una máquina virtual ... así que copiar y pegar usando el portapapeles tomó como una hora en sí, por lo que solo recomendaría esto como último intento.

Lo que me arregló fue

1. deteniendo la instancia
2. crear una copia de seguridad de los archivos .mdf y .ldf en la carpeta de datos
3. Reiniciar la instancia
4. eliminar la base de datos atascada en la restauración
5. vuelva a colocar los archivos .mdf y.ldf en la carpeta de datos
6. Adjunte la instancia a los archivos .mdf y .ldf

RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY

Use el siguiente comando para resolver este problema

RESTORE DATABASE [DatabaseName] WITH RECOVERY