Escenario: Se dañó la base de datos MIBASE.MDF, el registro de transacciones MIBASE_LOG.LDF se encuentra roto. El estado de la base de datos es “Sospechoso” y no se puede acceder a las tablas.
Motor de Base de Datos: SQL SERVER 2000
Método utilizado:
- Separar la base de datos. (detach)
-
Crear una nueva base de datos (en otra carpeta) con el mismo nombre. Por ejemplo, la base original esta en C:\MSSQL7\DATA\MIBASE.MDF crear la nueva en C:\MSSQL7\DATA_REPARADA\MIBASE.MDF
Asegurarse de crear el archivo LOG en la misma ubicación y con el mismo nombre que tenia antes
Por ejemplo, el log original esta en C:\MSSQL7\DATA\MIBASE_LOG.LDF crear la nueva en C:\MSSQL7\DATA_REPARADA\MIBASE_LOG.LDF
- Detener el Servicio del SQL Server
-
Copiar el archivo MIBASE.MDF original y reemplazar el nuevo
Copy C:\MSSQL7\DATA\MIBASE.MDF C:\MSSQL7\DATA_REPARADA\MIBASE.MDF
Ojo, solo copiar el MDF no el LOG
- Iniciar nuevamente el SQL Server, ahora verá la base de datos en estado sospechoso, pero puede acceder a los datos
Para reparar la base, ejecutar los siguientes comandos.
USE master;
ALTER DATABASE mibase
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
ALTER DATABASE ALFANET
SET READ_ONLY;
USE mibase
DBCC CHECKTABLE (‘MV_ASIENTOS’, REPAIR_ALLOW_DATA_LOSS) — Repara en este ejemplo la tabla de Asientos, también puede usar el comando CHECKDB
Esto me salvó varias veces.
Otras opciones de restauración:
/**
PROBADO, FUNCIONA BIEN
— FUENTE: http://www.guillesql.es/Articulos/base_Datos_Sospechosa_Suspect_SQL_Server_2005.aspx
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 ALFANET SET EMERGENCY
GO
— NOTA: He tenido que utilizar WITH ROLLBACK IMMEDIATE,
— porque el ALTER DATABASE no progresaba
ALTER DATABASE ALFANET SET SINGLE_USER
WITH ROLLBACK IMMEDIATE
GO
DBCC CHECKDB (ALFANET, REPAIR_ALLOW_DATA_LOSS)
GO
ALTER DATABASE ALFANET SET MULTI_USER
GO
Otros commandos que pueden ser utiles
— pone en modo USUARIO UNICO
–USE master;
–ALTER DATABASE Alfanet
–SET SINGLE_USER
–WITH ROLLBACK IMMEDIATE;
— pone en modo MULTI USUARIO
–USE master;
–ALTER DATABASE Alfanet
–SET MULTI_USER
— pone en modo SOLO LECTURA
–USE master;
–ALTER DATABASE ALFANET
–SET READ_ONLY;
— pone en modo SOLO LECTURA Y ESCRITURA
–USE master;
–ALTER DATABASE ALFANET
–SET READ_WRITE;
— Repara una tabla
–USE ALFANET
–DBCC CHECKTABLE (‘MV_ASIENTOS’, REPAIR_ALLOW_DATA_LOSS)