HowTo: Recuperar base de datos (SOSPECHOSO) en SQL Server

8927bd748f26a72A veces siendo el Administrador de Base de Datos se recuerda que es casi imposible malograrse una base de datos en un Gestor de Base de Datos “tan bueno” como el SQL Server de Microsoft, pero ésto suele suceder…  normalmente ocurre por problemas físicos (como por ejemplo: corte en el suministro de energía, problemas con los discos duros, etc.), lo más recomendable y sano es restablecerlo desde una copia de seguridad de la base de datos, pero si en caso no la tenemos, todavia es posible recuperarlo -o repararlo, sólo hacen falta ejecutar unos QUERY’s (consultas), veamos paso a paso.

1.- Desde el Microsoft SQL Server Management Studio, ejecutamos la siguiente consulta: “USE master GO sp_configure ‘allow updates’, 1 GO RECONFIGURE WITH OVERRIDE GO“, esto nos permitirá trabajar (modificar, alterar, reparar, …) las base de datos.

2.- Continuamos con siguiente consulta: “Alter Database NAME_DATABASE Set Single_user;“, esto nos permitirá que sólo exista un único usuario trabajando en la base de datos (osea nosotros, para que otros no se conecten y exista problemas después –más vale prevenir, que luego lamentar).

3.- Ahora ejecutamos la siguiente consulta: “Alter Database NAME_DATABASE Set Emergency“, para poder comprobar su estado y repararlo.1

Una vez terminado la consulta, se puede comprobar que se haya ejecutado correctamente, mirando en la imagen de anterior con la siguiente; en la base de datos paso de un Icono de “Advertencia” a un estado de color “Anaranjado“, si todo salió bien continuamos…

2

3.- Una vez en el estado de Emergencia, ejecutamos las siguientes consultas una por una (aqui lo fuerte):

  • DBCC checkdb (NAME_DATABASE, REPAIR_REBUILD);
  • DBCC checkdb (NAME_DATABASE, REPAIR_ALLOW, DATA_LOSS);

Este proceso puede demorar un poco de tiempo, dependerá de cuanto este dañado y de que tamaño (Mb, Gb, …) sea la base de datos, una vez terminado podemos continuar.

3Una buena práctica será: Guardar en un TXT del estado del LOG de las consultas, para después analizar a detalle si existió pérdida de información y si es posible comprobar la consistencia de las mismas.

4.- Hasta aqui ya se han reparado las base de datos, ahora falta regresar la base de datos al estado original, para que todos puedan usarlo, haciendo la siguiente consulta: “Alter Database NAME_DATABASE Set MULTIUSER”.

4

5.- No nos olvidemos del gestor y también regresar a su normalidad: “USE master GO SP_Configure ‘allow updates’, 0 GO RECONFIGURE WITH OVERRIDE GO”

Listo, con estas siete consultas en estos 5 pasos, tendremos restablecidos nuestra base de datos, lista para operar nuevamente.

Adicional: Es necesario se examine rigurosamente el LOG de las consultas para evitar sorpresas en el futuro, en caso te ha servido este articulo déjame un comentario como agradecimiento y/o alguna otra consulta que quieras hacerme.

6 comentarios

  1. Buenas,

    No sé porque la instrucción EMERGENCY no me la detecta y me da error en la consulta.

    La consulta que inserto es la siguiente.

    Alter Database PRODCON Set EMERGENCY

  2. Excelente tutorial, muchas gracias de paso me sirvió para recuperar una base de datos y solo te quiero hacer unas pequeñas observaciones, en la consulta: DBCC checkdb (NAME_DATABASE, REPAIR_REBUILD); me dió error diciendo que no podía realizar la instrucción en modo de emergencia, la siguiente instrucción DBCC checkdb (NAME_DATABASE, REPAIR_ALLOW, DATA_LOSS); tuve que cambiar la coma (,) que hay entre Allow y Data sustituyéndola por un guión bajo (_) y por último tienes repetido el paso 3 por lo que en vez de 5 pasos que defines en el documento realmente son 6

    Te agradezco mucho por haber hecho tan excelente tutorial que me salvó!

  3. Excelente….. Gracias….Por compartir conocimiento…. !!!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *