SQL Server: Utilizar DBCC CHECKDB para comprobar la corrupción de datos

Los datos se corrompen. Las bases de datos se dañan. Sin comprobar de forma regular el estado de las bases de datos, nos podemos encontrar copias de seguridad cuando la corrupción afecte los datos físicos.

Para comprobar la corrupción, DBCC CHECKDB debería ejecutarse contra cada base de datos de forma regular. Lo que se encuentra en la realidad:

1. Nunca se ha ejecutado DBCC CHECKDB.


2. DBCC CHECKDB sólo se ha ejecutado en algunas bases de datos.


3. DBCC CHECKDB se ha ejecutado meses o años atrás.


4. Lo peor: DBCC CHECKDB reportando errores.

Nunca es agradable encontrar corrupción o tener un cliente con un problema de corrupción cuando la corrupción es un heap o índice agrupado y no hay copias de seguridad antes de que ocurra la corrupción.

En estos casos, la corrupción está sobre los datos reales e iniciar la restauración desde antes de la corrupción es en la mayoría de los casos, la única opción. En los casos en que la corrupción es un índice no agrupado, la reconstrucción del índice es la solución.

En algunas situaciones, sucede, las bases de datos presentan un grado alto de corrupción sin copias de seguridad adecuadas, en ese caso, lo único posible de hacer es crear un script de la base de datos y realizar una copia de seguridad en una nueva base de datos.

Esta costosa situación puede evitarse fácilmente ejecutando DBCC CHECKDB de forma regular y teniendo copias de seguridad realizadas de forma programada.

Recomiendo ejecutar DBCC CHECKDB en instancias on-premises, IaaaS, Azure SQL Database, y Azure SQL Managed Instance.  Azure realiza un gran trabajo comprobando la corrupción física; sin embargo, los usuarios debemos comprobar la corrupción lógica.