Es la primera vez que me ocurre en vivo y en directo. Tenía que dar una charla de MOSS 2007 en el currele, y 15 minutos antes de empezar, perdí la base de datos de configuración de MOSS, al entrar esta en estado Sospechoso (Suspect). Es la primera vez que me ocurre con SQL Server 2005. En otras ocasiones, me había encontrado alguna base de datos Sospechosa en SQL Server 2000 o incluso en SQL Server 7.

Además, nunca antes lo había vivido en directo. Es decir, en otras ocasiones me habían llamado, y cuando llegaba ya estaba todo sobre la mesa. Sin embargo, en este caso me ha tocado en primera persona. Tenía levantadas todas las máquinas de la Granja MOSS del entorno de Laboratorio (sobre mi portátil de empresa), y estaba funcionando OK, accediendo al Portal, a la consola de Administración Central, etc. De pronto, intento acceder a MOSS y se muestra un error de acceso a la base de datos (lo siento, no capturé la pantalla, cachis). Entre medias, se me quedó medio colgado el equipo, y en la máquina virtual de SQL Server, manaron errores de acceso a Disco (de esos rojos, que aparecen en el Visor de Eventos del Sistema). Obviosly ;-)

Perplejo yo, me conecté con SQL Server Management Studio, y me encontré el siguiente panorama: la base de datos de configuración estaba en estado Sospechoso (Suspect).

Probé a reiniciar la Instancia de SQL Server 2005, y la base de datos continuaba en estado Sospechoso (Suspect). Lo siguiente, comprobar el ERRORLOG, a ver que nos cuenta, y si nos da alguna pista. El contenido del ERRORLOG relacionado con este problema, es el siguiente:

Antes de continuar, aproveché para detener la Instancia de SQL Server, y copiar los ficheros MDF y LDF de dicha base de datos, más que otra cosa, para experimentar (cual biólogo diseccionando ranas), pues siempre es interesante poder tener una copia de una Base de Datos Sospechosa (Suspect) para poder hacer pruebas de recuperación sobre la misma en un futuro. Lo sé. Vosotros también lo estabais pensando, jeje.

Siguiendo con lo nuestro, parece que hay un problema en el fichero de Log de la base de datos sospechosa, y que deberemos recuperar un Backup (que no tenemos, claro, es un entorno de laboratorio... el último backup es de hace meses) o reconstruir el Log de la base de datos.

Antes de continuar, quería incluir la siguiente entrada escrita por Paul Randal (uno de los grandes en esto de SQL Server) en el Blog de Microsoft SQL Server Storage Engine: When should you rebuild the transaction log? Yo la descubrí después de todo esto, y me pareció interesante. Hecho el Kit-Kat, continuamos.

Como comentábamos, hay que seguir palante e intentar recuperar esto como sea, ya que es un entorno de Laboratorio, y la última copia de seguridad es de la época de Paco Buyo. Lo primero, es poner la base de datos en Modo de Emergencia (Emergency Mode), que como sabemos, a partir de SQL Server 2005 se puede hacer con un comando ALTER DATABASE SET EMERGENCY (ej: ALTER DATABASE SharePoint_Config SET EMERGENCY). Tras realizar esto, me sorprendió el aspecto que tomaba la base de datos en SQL Server Management Studio, cual pimiento morrón, jeje ;-)

Seguidamente, intenté reconstruir el Log de SQL Server (quiero decir, el Log de la base de datos), ejecutando el comando no documentado (y no soportado, excepto que sea ejecutado siguiendo las indicaciones explícitas de Soporte Microsoft) DBCC REBUILD_LOG. Sin embargo, el comando DBCC REBUILD_LOG no sólo no está soportado en SQL Server 2005, sino que además ni existe. Diferencia interesante, frente a SQL Server 2000.

En mi guerra particular por recuperar la susodicha Base de Datos Sospechosa (y evitar así darme a la bebida), intento crear una nueva base de datos utilizando una copia del fichero de datos de la misma (sin utilizar el fichero de Log, que es el que se supone dañado, conforme dictaba el ERRORLOG). Utilizo dos sintaxis diferentes (CREATE DATABASE FOR ATTACH_REBUILD_LOG y el sp_attach_single_file_db), en ambos casos, mi gozo en un pozo (la verdad, que esta mañana está resultando todo un paseo por un campo lleno de... rosas ;-):

¿Cómo coño se reconstruye el Log en SQL Server 2005? Manda Webs.

Tras este último traspies, tiro de Google, y encuentro alguna entrada en algún BLOG, que sugiere poner la base de datos en modo Single User para seguidamente ejecutar un DBCC CHECKDB con la opción REPAIR_ALLOW_DATA_LOSS. Esto tiene sentido (es requisito el modo Single User para lanzar este DBCC), pero a priori, me siento algo excéptico, sobre que sea necesario el DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS (en principio, lo que quiero es reconstruir el Log, y punto). Como no hay mucho más donde rascar, lo pruebo.

Problema: al ejecutar el ALTER DATABASE SET SINGLE_USER, este no progresa. Es curioso, porque había reiniciado la instancia, y al iniciar la instancia con la base de datos en estado sospechoso, no tenía mucho sentido que existiesen transacciones abiertas que bloqueasen la progresión de éste comando ALTER DATABASE ¿Verdad? Desconfiado yo, ejecuto un ALTER DATABASE SET SINGLE_USER WITH ROLLBACK IMMEDIATE, y este si que tira (ipso-facto, como decía mi hermano), con lo cual, puedo lanzar mi tan ansiado como odiado DBCC CHECKDB con la opción REPAIR_ALLOW_DATA_LOSS. La salida de la ejecución del mismo es la siguiente:

Vamos por partes:

• Lo primero, gracias a la ejecución del comando DBCC CHECKDB con la opción REPAIR_ALLOW_DATA_LOSS, hemos conseguido reconstruir el Log de la base de datos. Fijaros en las primeras líneas de la salida de la ejecución del comando DBCC CHECKDB (Warning: The log for database 'SharePoint_Config' has been rebuilt). Os lo recalco, porque con las prisas yo no lo leí, lo que ocurre, es que me guardé la salida, y me fijé un par de días más tarde. Que caña. En fin. Con esto, conseguimos respuesta a la pregunta ¿Cómo reconstruir el Log de una base de datos SQL Server 2005 si DBCC REBUILD_LOG no funciona en 2005? Pues con DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS, con qué sino, jeje.
• Lo segundo, la base de datos se ha recuperado con éxito, detectándose dos errores de consistencia sobre la tabla TimerRunningJobs que han sido corregidos con éxito, quedando en modo de acceso exclusivo para DBO. Con esto, podemos revisar su estado y/o contenido, el ERRORLOG, etc., y cuando estemos seguros, devolver la base de datos a su estado normal con un comando ALTER DATABASE SET MULTI_USER (ej: ALTER DATABASE SharePoint_Config SET MULTI_USER).

Vaya, hemos tenido suerte, y al final hemos recuperado nuestra base de datos SQL Server 2005 desde su estado Sospechoso (Suspect) a un estado normal, y en consecuencia, he recuperado mi Granja de MOSS. Finalmente, incrédulo que soy, intenté acceder a MOSS con Internet Explorer, tanto al Portal como a la Consola de Administración Central, y todo funciona correctamente. Uff, por fín puedo respirar tranquilo.

Como recopilación de los pasos realizados:

Y poco más por hoy. Como siempre, espero os sirva.