Corrupción de datos

La corrupción de datos es algo con lo que ningún DBA se quiere encontrar en su vida profesional, lamentablemente es una posible ocurrencia, debido a que no es algo común es probable que el DBA entre en pánico, lo primero en todo momento es tener una copia de seguridad (Backup) de la información y conservar la calma.

Las mejores prácticas existen por una razón, una de ellas es tener una copia de seguridad reciente y sana de la base de datos, está siempre debe de ser la primera opción de cualquier DBA cuando esta enfrentándose a corrupción de datos, esto debe de estar de acuerdo con los SLA (Acuerdos de nivel de servicio) de su compañía y que tanto pueden perder de información y como espero que todos los que visiten este lugar tengan mejores prácticas al día no deberíamos de pasar a lo siguiente.

Lo primero es saber a qué nos enfrentamos para lo cual usaremos la siguiente sentencia.

DBCC TRACEON(3604)
DBCC CHECKDB (yourdb) WITH ALL_ERRORMSGS, NO_INFOMSGS

Nota: El traceflag 3604 forza los resultados en la pantalla de resultados, el ALL_ERRORMSGS que nos de todos los resultados que encuentre y no solo los primeros 200, NO_INFOMSGS simplemente elimina mensajes informativos.

Si esto nos da como resultado cualquiera de los siguientes códigos de error es muy posible que la información sea irrecuperable y será necesario hacer una restauración de una copia de seguridad.

8909, 8938, 8939, 8970, 8992 (Es posible arreglar esta última por registros de sus páginas aunque no es recomendado).

Una vez obtengamos el resultado y si no tenemos una copia de seguridad valida.

Podemos proceder con:

REPAIR_REBUILD ejemplo:

DBCC TRACEON(3604)
DBCC CHECKDB (yourdb, REPAIR_REBUILT) WITH ALL_ERRORMSGS, NO_INFOMSGS

Esto intentara reconstruir los índices y hacer reparaciones que no comprometen la información o nos conyeben a una inconsistencia de datos, si esto falla, lamentablemente las siguientes opciones no son agradables.

La última opción y repito ultima ya nunca debe de ser usada como la primera opción es.

 REPAIR_ALLOW_DATA_LOSS ejemplo:

DBCC TRACEON(3604)
DBCC CHECKDB (yourdb, REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS, NO_INFOMSGS

Esto intentara desalocar, borrar y reparar sectores o páginas, lo cual es muy probable que cause perdida de información y por consiguiente inconsistencia en la información que se contiene, como bien menciona la documentación en línea esto puede estar dentro de una transacción para hacer rollback en caso de fallo (lo cual deja la base corrupta).

Si hemos llegado a este punto no hay nada más que hacer, o pueden intentar herramientas de la red, aunque es altamente probable que se incurra en inconsistencia de datos... o poner la base en emergency mode, pero es algo de otro tema.

Más Información:

DBCC CHECKDB
Detecting and correcting database corruption