Reconstruyendo el registro de transacciones

Tenemos una base de datos muy grande (~ 6 TB), cuyo archivo de registro de transacciones se eliminó (mientras SQL Server se cerró. Hemos intentado:

1. Separar y volver a conectar la base de datos; y
2. Recuperar el archivo de registro de transacciones

... pero nada ha funcionado hasta ahora.

Actualmente estamos ejecutando:

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

... pero dado el tamaño de la base de datos, esto probablemente demorará unos días en completarse.

Preguntas

• ¿Hay alguna diferencia entre el comando anterior y el siguiente?

  DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• ¿Deberíamos estar ejecutando en su REPAIR_ALLOW_DATA_LOSSlugar?

Vale la pena señalar que los datos se derivan de otras fuentes para que la base de datos se pueda reconstruir, sin embargo, sospechamos que será mucho más rápido reparar la base de datos que volver a insertar todos los datos nuevamente.

Actualizar

Para aquellos que mantienen puntaje: el ALTER DATABASE/REBUILD LOGcomando se completó después de aproximadamente 36 horas e informó:

Advertencia: El registro para la base de datos 'dbname' ha sido reconstruido. Se ha perdido la coherencia transaccional. La cadena RESTORE se rompió y el servidor ya no tiene contexto en los archivos de registro anteriores, por lo que deberá saber cuáles eran.
Debe ejecutar DBCC CHECKDB para validar la consistencia física. La base de datos se ha puesto en modo solo dbo. Cuando esté listo para que la base de datos esté disponible para su uso, deberá restablecer las opciones de la base de datos y eliminar los archivos de registro adicionales.

Luego DBCC CHECKDBejecutamos un (tomó alrededor de 13 horas) que tuvo éxito. Digamos que todos hemos aprendido la importancia de las copias de seguridad de la base de datos (y de otorgar a los administradores de proyectos acceso al servidor ...).

Nunca separe una base de datos sospechosa. De todos modos, ¿cómo adjuntaste la base de datos después de separarla? ¿Usaste CREATE DATABASEcon FOR ATTACH_REBUILD_LOGopción?

Estos comandos deberían haber hecho el truco:

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

Escribí una publicación para esta situación:

Procedimiento de recuperación de la base de datos SQL 2005/2008: archivo de registro eliminado (parte 3)

Preguntaste sobre la diferencia entre:

• DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) y
• ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

La cuestión es que puede ejecutar ambos para reconstruir el archivo de registro, pero CHECKDBtambién reconstruye el registro y comprueba la base de datos en busca de errores de integridad.

Además, el segundo (alterar la base de datos) no funcionará si hubo transacciones activas (no escritas en el disco) cuando se perdió el archivo de registro. Al iniciar o adjuntar, SQL Server querrá realizar la recuperación (reversión y avance) del archivo de registro que no está allí. Ocurre cuando se bloquea un disco o se produce un apagado inesperado del servidor y la base de datos no se apaga limpiamente. Supongo que no fue tu caso y todo se resolvió bien para ti.

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)ejecutar en una base de datos en estado de emergencia comprueba la base de datos en busca de errores de inconsistencia, primero intenta usar el archivo de registro para recuperarse de cualquier inconsistencia. Si esto falta, el registro de transacciones se reconstruye.

2. ALTER DATABASE REBUILD LOG ON...es un procedimiento no documentado y requiere un subsiguiente DBCC CHECKDBpara corregir cualquier error.

Sí, esas son dos declaraciones diferentes, cada una haciendo cosas muy diferentes.

Dependiendo del estado de la base de datos cuando se eliminó el archivo, es posible que pueda comenzar a trabajar adjuntando la base de datos y reconstruyendo el registro utilizando:

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

Consulte sp_attach_single_file_db (Transact-SQL) en la documentación del producto.

Vea también esta publicación de blog de Paul S. Randal :

Reparación en modo de emergencia: el último recurso