Mi Base de datos esta en estado SUSPECT en SQL Server ¿A qué se debe?

Mi bases de datos esta en estado suspect o sospechoso. Esto ocurre cuando hay un fallo en la base de datos SQL Server que podemos repararlo.

Cambien podemos interpretar con la corrupción en una base de datos sin embargo los componentes dela computadora fallan, existen cortes en el suministro de energía eléctrica, los controladores de los discos o los discos en sí, son propensos a fallos y pueden corromper las base de datos mediante escrituras incompletas, apagar de forma incorrecta la computadora, etc.

SQL Server tiene una herramienta de autoprotección que evita a su vez la ocurrencia de una corrupción masiva en la base de datos. En este sentido estamos limitados a tener un total de hasta 1000 páginas corruptas en una base de datos. Cuando se alcanza este límite SQL Server pone la base de datos fuera de línea y coloca el estatus SUSPECT para protegerla de un daño mayor. Es así como llegamos al escenario en que una base de datos está en modo SUSPECT.

En términos generales las bases de datos cambian a estado SUSPECT por corrupción en las páginas de datos generados en muchos de los casos por fallas en el hardware a nivel de discos o por un crash del equipo.

Reparar: Ejecutar el siguiente query.

–Habilitar modificación en la base de datos master:
USE master
GO
sp_configure ‘allow updates’, 1
GO
RECONFIGURE WITH OVERRIDE
GO
–Resetear el estado de suspect:
EXEC sp_resetstatus ‘TuBasedeDatos’;
–Para ejecutar el check de integridad hará falta poner la base de datos en single user
ALTER DATABASE TuBasedeDatos SET SINGLE_USER;
–En caso que no sea posible sacarla de suspect, es posible pasarla a modo emergency
Alter Database TuBasedeDatos Set Emergency
–Si esto no funciona es posible que haya que reinicar la instancia entera de SQL Server
–Pasamos integrity check, para reparar sin perdida de datos:
DBCC checkdb(‘TuBasedeDatos’,REPAIR_REBUILD);
–Para reparar con posible perdida de datos:
DBCC checkdb(‘TuBasedeDatos’,REPAIR_ALLOW_DATA_LOSS);
–Para volver a dejar la base de datos en modo multiusuario:
ALTER DATABASE TuBasedeDatos SET MULTI_USER
–Deshabilitar la opción de allow_updates para volver a dejarlo como antes
USE master
GO
sp_configure ‘allow updates’, 0
GO
RECONFIGURE WITH OVERRIDE
GO
–Ya tenemos la base de datos reparada.

Otro método mas resumido seria el siguiente:

Para reparar una base de datos que esté en este estado, bastará con lanzar sobre ella cuatro consultas, estas cuatro:

1. ALTER DATABASE TuBasedeDatos SET EMERGENCY;
2. ALTER DATABASE TuBasedeDatos SET SINGLE_USER;
3. DBCC CHECKDB (TuBasedeDatos , REPAIR_ALLOW_DATA_LOSS);
4. ALTER DATABASE TuBasedeDatos SET MULTI_USER;

Gracias a estos comandos estaremos solicitando una reparación de la misma, logrando así el resultado esperado en muchos de los casos de bases de datos sospechosas.

Si no hemos logrado el resultado esperado, también podemos realizar esta otra consulta:

• DBCC checkdb (TuBasedeDatos, REPAIR_REBUILD);

Claramente, en todos los casos debemos cambiar TuBasedeDatos  por el nombre real de nuestra base de datos y también debemos contar con los privilegios necesarios para llevar a cabo esta tarea.