Un archivo de registro de transacciones dañado o faltante es una de las situaciones más estresantes a las que puede enfrentarse un DBA. El primer instinto es restaurar desde el último backup completo — pero dependiendo de las circunstancias, SQL Server ofrece rutas de recuperación más rápidas que minimizan tanto el tiempo de inactividad como la pérdida de datos. Este artículo describe los dos escenarios principales y el procedimiento para cada uno.

Advertencia: estos procedimientos implican omitir los mecanismos de recuperación normales. Valide siempre la consistencia de datos a nivel de aplicación tras completar la recuperación, y realice un backup completo en cuanto la base de datos esté accesible.

Posibles Condiciones de Partida

• Archivo de registro dañado (fallo de hardware, error de almacenamiento)
• Archivo de registro dañado durante una transacción de larga duración
• Volumen del archivo de registro perdido o desmontado mientras había transacciones en curso

Escenario 1: No Había Transacciones en Ejecución en el Momento del Fallo

Si la base de datos estaba inactiva cuando se perdió o dañó el archivo de registro, SQL Server puede reconstruir automáticamente el archivo de registro durante el inicio. Esta es la ruta de recuperación más limpia.

1. Desasociar la base de datos: sp_detach_db
2. Renombrar el archivo de registro dañado a *.OLD (no eliminarlo todavía)
3. Asociar usando FOR ATTACH_REBUILD_LOG

-- SQL Server will rebuild the log file at the original path
CREATE DATABASE [MYDATABASE] ON
    (FILENAME = N'D:SQLDataDatabase.mdf')
FOR ATTACH_REBUILD_LOG
GO

Si el archivo de registro reconstruido necesita estar en una ubicación diferente, SQL Server intentará crearlo en la ruta original especificada en los metadatos internos del MDF. Es posible que deba asegurarse de que esa ruta sea accesible.

Escenario 2: Había Transacciones en Ejecución en el Momento del Fallo

ATTACH_REBUILD_LOG no está permitido cuando SQL Server detecta transacciones abiertas u operaciones de reversión pendientes. Al intentarlo se devolverá:

The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. […] Msg 1813, Level 16, State 2: Could not open new database. CREATE DATABASE is aborted.

En este caso, utilice el siguiente procedimiento para forzar la reconstrucción del registro:

1. Desasociar la base de datos
2. Renombrar tanto el MDF como el LDF a *.OLD
3. Crear una nueva base de datos vacía con el mismo nombre, la misma ruta de archivo de datos y la misma ruta de archivo de registro
4. Poner la nueva base de datos fuera de línea: ALTER DATABASE MyDatabase SET OFFLINE
5. Copiar el MDF original (*.OLD) de vuelta a su ruta original, sobrescribiendo el nuevo vacío
6. Poner la base de datos en línea: ALTER DATABASE MyDatabase SET ONLINE — esto fallará, pero es lo esperado
7. Reconstruir el archivo de registro:

ALTER DATABASE [MyDatabase]
REBUILD LOG ON (
    NAME     = 'MyDatabaseLog',
    FILENAME = 'D:SQLDataMyDatabase_log.ldf'
)

8. Abrir la base de datos a todos los usuarios:

ALTER DATABASE [MyDatabase] SET MULTI_USER

Lista de Verificación Post-Recuperación

• Ejecutar DBCC CHECKDB inmediatamente para verificar la consistencia física y lógica.
• Realizar un backup completo lo antes posible — la cadena de restauración está rota y la cadena de backup anterior ya no es válida.
• Validar los datos de la aplicación con el equipo de aplicación. Las transacciones que estaban en curso en el momento del fallo no fueron confirmadas — verifique si hay operaciones parciales que puedan haber dejado los datos de negocio en un estado inconsistente.
• Si no se puede restaurar la consistencia a nivel de aplicación, una restauración completa desde el último backup válido es la única opción segura.