GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Recuperar Base de Datos Sospechosa (Suspect) en SQL Server 2005


Recientemente, tuve un problema de corrupción sobre la base de datos de configuración de MOSS que se puso en estado Sospechoso (Suspect), en un entorno de laboratorio. Es la primera vez que me encuentro una base de datos Sospechosa (Suspect) en SQL Server 2005, ya que en veces anteriores, lo había experimentado en SQL Server 7 y SQL Server 2000. Me sorprendió, que encontré algunas diferencias durante el procedimiento de recuperación de la base de datos Sospechosa, y en especial, en cómo reconstruir el Log en SQL Server 2005 (DBCC REBUILD_LOG no existe en SQL Server 2005), aunque finalmente recuperé la base de datos y la Granja de MOSS. Aquí va el detalle...

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:

2009-07-24 11:07:47.30 spid13s Starting up database 'SharePoint_Config'.
2009-07-24 11:07:49.32 spid13s An error occurred while processing the log for database 'SharePoint_Config'. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log.
2009-07-24 11:07:49.32 spid13s Error: 3414, Severity: 21, State: 1.
2009-07-24 11:07:49.32 spid13s An error occurred during recovery, preventing the database 'SharePoint_Config' (database ID 18) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

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 ;-):

-- Ejemplo con CREATE DATABASE FOR ATTACH_REBUILD_LOG
USE [master]
GO
CREATE DATABASE [Test]
ON (FILENAME = N'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SharePoint_Config.suspect.mdf')
FOR ATTACH_REBUILD_LOG

-- Mensaje que recibo:
Msg 1813, Level 16, State 2, Line 1
Could not open new database 'test'. CREATE DATABASE is aborted.
Msg 9004, Level 23, State 4, Line 1
An error occurred while processing the log for database 'test'. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log.

-- Ejemplo con sp_attach_single_file_db
sp_attach_single_file_db @dbname = 'test' , @physname = 'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SharePoint_Config.suspect.mdf'

-- Mensaje que recibo:
Msg 1813, Level 16, State 2, Line 1
Could not open new database 'test'. CREATE DATABASE is aborted.
Msg 9004, Level 23, State 4, Line 1
An error occurred while processing the log for database 'test'. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log.

¿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:

Warning: The log for database 'SharePoint_Config' has been rebuilt. Transactional consistency has been lost. The RESTORE chain was broken, and the server no longer has context on the previous log files, so you will need to know what they were. You should run DBCC CHECKDB to validate physical consistency. The database has been put in dbo-only mode. When you are ready to make the database available for use, you will need to reset database options and delete any extra log files.
...
...
DBCC results for 'TimerRunningJobs'.
Repair: Successfully inserted row in index "dbo.TimerRunningJobs, IX_TimerRunningJobs_ServerName_Status" in database "SharePoint_Config".
Repair: Successfully deleted row in index "dbo.TimerRunningJobs, IX_TimerRunningJobs_ServerName_Status" in database "SharePoint_Config".
Msg 8951, Level 16, State 1, Line 1
Table error: table 'TimerRunningJobs' (ID 1157579162). Data row does not have a matching index row in the index 'IX_TimerRunningJobs_ServerName_Status' (ID 2). Possible missing or invalid keys for the index row matching:
The error has been repaired.
Msg 8955, Level 16, State 1, Line 1
Data row (1:798:7) identified by (ServiceId = 'F3CF25E3-A1C5-425A-8D18-421162CEDB68' and VirtualServerId = NULL and JobId = 'F5FCF504-D1A7-45C9-95B3-7BC033A6EE7A' and ServerName = 'VMOSS01MOB') with index values 'ServerName = 'VMOSS01MOB' and Status = 1 and ServiceId = 'F3CF25E3-A1C5-425A-8D18-421162CEDB68' and VirtualServerId = NULL and JobId = 'F5FCF504-D1A7-45C9-95B3-7BC033A6EE7A''.
Msg 8952, Level 16, State 1, Line 1
Table error: table 'TimerRunningJobs' (ID 1157579162). Index row in index 'IX_TimerRunningJobs_ServerName_Status' (ID 2) does not match any data row. Possible extra or invalid keys for:
The error has been repaired.
Msg 8956, Level 16, State 1, Line 1
Index row (1:872:10) with values (ServerName = 'VMOSS01MOB' and Status = 2 and ServiceId = 'F3CF25E3-A1C5-425A-8D18-421162CEDB68' and VirtualServerId = NULL and JobId = 'F5FCF504-D1A7-45C9-95B3-7BC033A6EE7A') pointing to the data row identified by (ServiceId = 'F3CF25E3-A1C5-425A-8D18-421162CEDB68' and VirtualServerId = NULL and JobId = 'F5FCF504-D1A7-45C9-95B3-7BC033A6EE7A' and ServerName = 'VMOSS01MOB').
There are 55 rows in 2 pages for object "TimerRunningJobs".
CHECKDB found 0 allocation errors and 2 consistency errors in table 'TimerRunningJobs' (object ID 1157579162).
CHECKDB fixed 0 allocation errors and 2 consistency errors in table 'TimerRunningJobs' (object ID 1157579162).
...
...
CHECKDB found 0 allocation errors and 2 consistency errors in database 'SharePoint_Config'.
CHECKDB fixed 0 allocation errors and 2 consistency errors in database 'SharePoint_Config'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

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:

ALTER DATABASE SharePoint_Config SET EMERGENCY
GO
-- NOTA: He tenido que utilizar WITH ROLLBACK IMMEDIATE,
-- porque el ALTER DATABASE no progresaba
ALTER DATABASE SharePoint_Config SET SINGLE_USER
WITH ROLLBACK IMMEDIATE
GO
DBCC CHECKDB (SharePoint_Config, REPAIR_ALLOW_DATA_LOSS)
GO
ALTER DATABASE SharePoint_Config SET MULTI_USER
GO

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


[Fecha del Artículo (UTC): 28/07/2009]
[Autor: GuilleSQL]


Comentarios

jgpuppo - 25/01/2011 (UTC)
Gracias amigo un exito, me salvaste la vida.


hemel_23 - 28/03/2011 (UTC)
Gracias amigo me salvastes de una buena, desde Peru te brindo las gracias


jack - 31/03/2011 (UTC)
Excelente articulo.
Me salvo la chamba (jejejejjejeje)
Agradesco a todas las personas que publican sus conocimientos.
Saludos


peter - 19/04/2011 (UTC)
Muchísimas gracias, me has salvado. Mi fichero de log había crecido hasta los 41 gigas y se corrompió. Hice exactamente lo que pusiste y perfecto. Mil gracias por el aporte.


mASter software - 20/05/2011 (UTC)
Gracias, me salvaste, había buscado antes esto que me paso con hace tiempo y tuve que volver a generar la base ahora que un corte de luz me daño otra base, me salvaste de muchas horas de trabajo. Gracias de nuevo


rodrigo morales - 08/09/2011 (UTC)
He seguido los pasos tal como aparece más arriba, pero en la ejecución del DBCC CHECKDB con la opción REPAIR_ALLOW_DATA_LOSS me está demorando MAS DE 10 HORAS, ¿ésto es normal? si el archivo log.ldf pesa 47 MB?


azaelsan - 08/05/2012 (UTC)
muchas gracias por este aporte y por tus conocimientos,me fue de gran ayuda para corregir mi base de datos.
DIOS TE BENDIGA.



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Abril de 2014 (3)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas