Tomando como referencia el tipo de redacción de mi colega DDAZ voy a escribir este POST haciendo alusión a un “posible” caso de la vida real. Quiero aclarar que no soy DBA y no soy una eminencia optimizando sentencias SQL o una cosa por el estilo. Los nombres utilizados y su parecido con la realidad son mera coincidencia. 

El DBA despistado 

Josué, el encargado de la integridad de la información  y de los aspectos ambientales de la información de de una prestigiada empresa prestadora de servicios de tecnología (DBA), consiente y preocupado ante cualquier proceso de recuperación de desastres, análisis de rendimiento y optimización de base datos, olvidó (“por error”). Programar ya sea incrementalmente, diferencialmente o totalmente respaldos propios de la información contenida en las bases de datos de la compañía. 

Un día (viernes, que raro), ocurrió algo que estaba contenido en el plan de recuperación a desastres y solo se pensaba que podría llegar a ocurrir si el experimento que se está realizando en Suiza (entre las montañas del Jura y el lago de Ginebra), generara un poderoso arranque de gravedad que comprimiera la materia y terminara con la vida tal cual la conocemos. Un simple apagón de energía eléctrica, lo cual ocasionó que se dañaran varios sectores en disco duro, se malogrará el sistema de arranque del sistema operativo y se perdieran los log de transacciones de todas las bases de datos (LDF).

Cabe mencionar que el SMBD era SQL Server. La empresa sufrió mucho operativamente y la información vital de la misma, jamás se pudo recuperar. JAMÁS!! 

¿Por qué Sucedió esto? 

Josué, como todo profesionista promedio, tuvo un escenario en donde la teoría no sirve para nada ante situaciones prácticas donde se requiere actuar rápido para mantener el negocio. Adicionalmente también desconocía las bondades y la importancia de realizar respaldos de sus bases de datos como lo detalla la siguiente tabla*: 

*Clasificación de Respaldos. Osmosis Latina - http://www.osmosislatina.com/soporte/respaldos.htm 

¿Qué hacer si ya valió? 

Cabe mencionar que la siguiente alternativa solo funciona para SQL Server y no es una opción muy “elegante” al problema, yo sigo la siguiente filosofía: “A problemas piñatas, soluciones piñatas”, no por algo tengo un diploma a las “marranadas” (hablando de soluciones tecnológicas). 

La solución propuesta sería: 

1.    Crear las bases de datos afectadas en blanco, detener el servicio de SQL Server y cambiar el MDF por el que rescataron del server caído (Q.E.P.D). 

2.    Eliminar el LDF que se generó en blanco y reiniciar el servicio de SQL. Dado esto debería marcar la base de datos como suspect. 

3.    Posicionarse en la base de datos MASTER (USE MASTER) 

4.    Cambiar las opciones de configuración global del servidor actual para que permita hacer cambios al mismo. 

EXEC sp_Configure 'ALLOW UPDATES', 1
RECONFIGURE WITH OVERRIDE 

5.    Cambiar el estado de la base de datos a MODO DE EMERGENCIA. 

UPDATE SYSDATABASES SET STATUS = 32768 WHERE NAME = 'NombreBaseDeDatos'  

6.    Cambiar las opciones de configuración global del servidor actual para que ya no permita hacer cambios al mismo

EXEC sp_Configure 'ALLOW UPDATES', 0
RECONFIGURE WITH OVERRIDE 

7.    Cambiar la base de datos afectada a opción de usuario simple. 

EXEC sp_DBOption 'ArchivoIntegracion', 'SINGLE USER', 'TRUE' 

8.    Reconstruir el LOG de transacciones (LDF) de la base de datos (MDF). 

DBCC REBUILD_LOG ('NombreBaseDeDatos', 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\NombreBaseDeDatos_Log.ldf') 

9.    Cambiar las opciones de configuración global del servidor actual para que permita hacer cambios al mismo. 

EXEC sp_Configure 'ALLOW UPDATES', 1
RECONFIGURE WITH OVERRIDE 

10. Cambiar el estado de la base de datos a MODO NORMAL. 

UPDATE SYSDATABASES SET STATUS = 0 WHERE NAME = 'NombreBaseDeDatos' 

11. Cambiar las opciones de configuración global del servidor actual para que ya no permita hacer cambios al mismo 

EXEC sp_Configure 'ALLOW UPDATES', 0
RECONFIGURE WITH OVERRIDE 

12. Cambiar la base de datos afectada a opción de usuarios múltiples. 

EXEC sp_dboption 'ArchivoIntegracion', 'SINGLE USER', 'FALSE' 

Y voila, ya quedó milagrosamente rescatado nuestro MDF sin necesidad de contar con el LDF respectivo. Josué ya puede estar más tranquilo al respecto y tener más cuidado para la próxima vez que ocurra esto en su organización (que esperemos y jamás vuelva a suceder).