SQL Server: Base de datos atrapada en el 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 restre over specified database 

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

Algunas personas han teorizado que se debe a que no había ningún archivo de registro en la copia de seguridad y que era necesario avanzar utilizando:

 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 restred. 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 opción WITH RECOVERY , con su comando RESTORE base de datos, para poner su base de datos en línea como parte del proceso de restauración.

Esto es, por supuesto, 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 

Puede tener más éxito utilizando el asistente de restauración de la base de datos en SQL Server Management Studio. De esta forma puede seleccionar las ubicaciones de archivos específicos, la opción de sobrescribir y la opción CON recuperación. A veces, el proceso de restauración se atascó solo por el tamaño del archivo de la base de datos. mira aquí: https://madhivanan.wordpress.com/2016/09/06/issue-in-recovering-a-database-that-is-in-the-restring-state-reference/

Tuve esta situación para restaurar una base de datos a una instancia de SQL Server 2005 Standard Edition utilizando Symantec Backup Exec 11d. Una vez que se completó la tarea de restauración, la base de datos permaneció en estado de “Restauración”. No tenía problemas de espacio en el disco; la base de datos simplemente no salió del estado “Restauración”.

Ejecuté la siguiente consulta en la instancia de SQL Server y descubrí que la base de datos se puede utilizar inmediatamente:

 RESTORE DATABASE  WITH RECOVERY 

Así es como lo haces:

  1. Detenga el servicio (MSSQLSERVER);
  2. Cambie o elimine la base de datos y los archivos de registro (C: \ Archivos de progtwig \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data …) o donde sea que tenga los archivos;
  3. Inicie 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 registro. 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  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 se pudo utilizar nuevamente después de esos 18 segundos.

Tuve un problema similar con la restauración utilizando 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 los archivos de la nueva base de datos, se realizó con éxito. En cualquier caso, el problema que describo volvió a ocurrir incluso si lo entendí bien desde la primera vez. Entonces, después de la restauración, la base de datos original se mantuvo con un (Restaurando …) al lado de su nombre. Teniendo en cuenta las respuestas del foro anterior (de Bhusan) intenté ejecutar en el editor de consultas en el lado 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 “Sintaxis incorrecta cerca …”.

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

De acuerdo, tengo un problema similar y exactamente como en el caso de Pauk, fue causado por la falta de espacio del disco en el servidor mientras se restauraba y, por lo tanto, provocó 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* 

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

 RESTORE DATABASE YourDB WITH RECOVERY GO 

Si es necesario restaurar varios archivos, los comandos CLI requieren CON NORECOVERY y WITH RECOVERY, respectivamente; solo el último archivo en comando debe tener WITH RECOVERY para traer 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:

enter image description here

También hay un proceso de restauración virtual, pero deberá 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 por SQL Hammer sobre ApexSQL Restore . La restauración virtual es una buena solución si se trata de una gran cantidad 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 ver algunas comparaciones.

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

Si está realizando una copia de seguridad de 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 (CON NORECOVERY)”

enter image description here

Descubrí por qué.

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

Es extraño que el servidor, cuando le piden 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 trabajo:

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 el 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 desde los servicios de Windows.

  2. Abrí la carpeta DATA donde residen los archivos Ldf y Mdf en el directorio SQL, normalmente es como: “C: \ Archivos de progtwig *********** \ 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 en otra carpeta.

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

  2. Comencé mi estudio de administración de MS SQL con un inicio de sesión normal.

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

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

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

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

  7. Luego copié los dos archivos (desde el paso 3) a la carpeta DATA (paso 2).

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

Tuve un . en mi nombre de base de datos, y la consulta no funcionó debido a eso (diciendo Sintaxis incorrecta cerca de ‘.’) Luego 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 de TCP en el registro de eventos …

Suelta el DB con sql o haz clic con el botón derecho sobre él en el administrador “eliminar” y restaura de nuevo.

De hecho, he empezado a hacer esto por defecto. Secuencia de comandos del DB drop, recrear y luego restaurar.

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 (leer algunas publicaciones)
  2. ejecutar comando: soltar base de datos [su base de datos], que le dará un error diciéndole el nombre de la base de datos de instantáneas
  3. ejecutar comando: soltar base de datos [base de datos instantánea], y luego ejecutar el comando en el paso 2 de nuevo.

Por defecto, cada RESTORE DATABASE viene con la configuración RECOVERY . Las opciones ‘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 copia de seguridad de registro final). Las opciones de ‘RECUPERACIÓN’ terminan todas las transacciones y dejan que la base de datos esté lista para realizar transacciones.

Asi que:

  1. si su base de datos está configurada con el modelo de recuperación SIMPLE , solo puede realizar una restauración COMPLETA con la opción NORECOVERY , 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 modelo de recuperación FULL o BULK-LOGGED , puede realizar una restauración FULL seguida de la opción NORECOVERY , luego realizar un DIFF seguido de NORECOVERY y, finalmente, realizar la restauración de LOG con la opción RECOVERY .

Recuerde, LA ÚLTIMA CONSULTA DE RESTAURACIÓN DEBE TENER LA OPCIÓN DE RECOVERY . Podría ser una forma explícita o no. En termias 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 REEMPLAZAR debe usarse con precaución ya que puede provocar la pérdida de datos

O bien, 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 
  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 que le indica al SQL Server que debe informar cada 10% completado.

Si lo prefiere, puede observar el proceso o restaurarlo en una consulta 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.

En mi caso, fue suficiente soltar la base de datos que colgaba en estado “Restaurando …” con el comando SQL

  drop database  

en una ventana de consulta.

Luego hice clic derecho en Bases de datos y seleccioné Actualizar lo que eliminó la entrada en Management Studio. Después hice una nueva restauración que funcionó bien (tenga en cuenta que no funcionaba desconectarlo, que no funcionaba el reinicio del servicio SQL, que el reinicio del servidor tampoco funcionaba).

¿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

  1. Primero revise y ejecute SQL Agent Service.
  2. Usando el siguiente T-SQL:

    SELECCIONAR el archivo FROM master.sys.sysaltfiles WHERE dbid = DB_ID (‘db_name’);

  3. Usando T-SQL continuamente:

    RESTABLECER BASE DE DATOS DESDE DISK = ‘DB_path’ CON RESTART, REPLACE;

¡Espero que esto ayude!

Todas las opciones basadas en WITH RECOVERY no me funcionaron.

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 se hubiera corrompido o algo así. Probé 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 congelaba en la restauración?

Terminé resolviendo esto borrando los archivos como se mencionó, pero en lugar de tratar de restaurar el DB de nuevo, copié en archivos frescos .mdf y .ldf y los adjunté usando el asistente de Front End Attachment. Alivio, funcionó !!

Me tomó FOREVER para 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 bash.

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 fallaron 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.

Por lo tanto, si intenta restaurar una base de datos más grande, debe cambiar su servidor SQL Express a Developer Edition, por ejemplo.

    Intereting Posts