Corrupción... que hacer? (Parte 1)

Posiblemente uno de los mayores temores que tengamos siempre serán el hecho de que tengamos corrupción en una base o en varias de ellas, sino han tenido corrupción es bueno pero es altamente probable que tengas que enfrentarla en alguno momento en la vida, la corrupción puede ser instantánea o puede tener mucho tiempo en el sistema y hasta afectar las copias de seguridad.

Lo primero a saber es qué hacer cuando la tengamos, esto será un serie de post y es muy posible que la gente ignore esto y vaya a los métodos de recuperación, eso sería un error.

Si tienes corrupción lo mejor que puedes hacer es tener una copia de seguridad sana. Sino lo tienes tu segunda mejor opción es tener una mente calmada y fría ya que entrar en pánico y tomar malas decisiones hará una mala solución algo peor o irrecuperable en el peor de los casos.

¿Qué no hacer?

• Reiniciar: cuando se reinicia una instancia o se hace un failover, la base tiene que hacer una prueba de consistencia, si la base antes era accesible es posible que ya no lo sea porque falle esta prueba, si el error se encuentra en el log de transacciones este hace un proceso es rollback y rollforward y también es posible que falle en este
• IO: No apagar el almacenamiento pues puede haber transacciones en el bus, aunque si se ve que la base está detenida y no existe movimiento en las transacciones, sea una opción
• Reparar: La primera opción en todo momento es usar una copia de seguridad para volver a un estado sano, sin pérdida de datos y consistente, al hacer una reparación es posible que tengamos que borrar registros, de los cuales desconocemos cuándo y qué información se perdió
• Remover el log de transacciones: En ocasiones al hacer una investigación es posible que veamos corrupción en el log de transacciones y intentemos apagar la instancia para borrarlo y volver a un estado operativo, esto crearía errores de consistencia o si alguna transacción no termino sea imposible volver la base a un estado en línea
• Hacer un detach: Se piensa que el volver a hacer un attach de la base de datos puede hacer que tome de manera correcta la base, la corrupción ya existe en una parte de la base y esta opción no es viable para solventar este problema
• Si no sabemos qué hacer o no estamos seguros, consultar con un experto en el tema es mejor ser sinceros y no arriesgarnos a algo mucho peor por hacernos pasar por el superhombre de la empresa

¿Qué hacer antes?

• Como varias cosas en la vida, no podemos prevenir que pase esto, pero si podemos estar prevenidos y saber que hacer, recuerden que uno de los pilares de un DBA es resguardar la información, esto no es solo de robo de la misma sino que siempre esté disponible y sea consistente
• Hacer un checkdb y conocer cómo lo podemos hacer para prevenir

¿Qué hacer después?

• Un análisis causa raíz:  Saber que causo el problema es posiblemente lo más importante una vez que el evento a sido sobrepasado, debido a principalmente saber si fue algo aislado o existe la posibilidad de que se vuelva a presentar
• Ver los errores de mensaje antes y durante la corrupción
• Verificar que cambios tanto en software como en hardware se han suscitado (incluye parches de seguridad)
• Revisar en el error log de errores de SQL Server, Event log de aplicación y sistema de Windows, Cluster log
• Revisión de la red y el subsistema de IO
• Antivirus, verificar que el mismo este diseñado para no afectar a SQL Server o si tiene exclusiones
• Verificar que el firmware del hardware esté al día, preferentemente que no sea más antiguo de dos años

¿Que no causa corrupción?

• Cerrar el sistema rápido (no hablamos de fallas de corriente)
• Shrink, índices (creación o reorganización)
• Comandos soportados (mucha gente recomienda algunos comandos o TF no públicos en sus blogs, algunas de las cuales no es recomendado usarlas en producción)

Cómo detectar la corrupción

La corrupción se puede detectar en dos lugares, en el disco y en la memoria, la principal forma de corrupción será en disco, como es esto, las paginas están contenidas en memoria lo que conocemos normalmente como el Buffer Pool, cuando escribimos estas paginas al almacenamiento para hacerlas permanentes lo hacemos en 8k bytes, los discos normales escriben en sectores de 512 o de 4k (https://en.wikipedia.org/wiki/Disk_sector), la menor medida en SQL Server es una pagina o sea 8k, lo cual quiere decir que escribiremos de 2 a 16 veces, el contenido de la pagina puede cambiar en lo que se realiza la escritura (por lo cual es recomendado que se usen discos de 4k).

SQL Server puede detectar si existe un fallo por 2 medios el cual es "Torn page" y "Checksum" a partir de SQL Server 2005 es recomendado el uso de checksum, es bueno notar que estos métodos no nos corrigen el error pero si nos avisan de un error.

La mayor diferencia es que torn page puede fallar, pero checksum al ser un algoritmo de cálculo sobre la página, nos estaría haciendo notar que es un problema de hardware, mientras que Torn Page es posible que sea generado por  una falla de software.

Cuando existen estos errores normalmente veremos fallas de IO

En el event log, sql server error log podremos encontrar los errores:

• 823 hard IO error
• 824 soft IO error
• 825 read-retry errors (hasta 4 intentos fallidos de 823 u 825)

Si vemos cualquiera de estos errores quiere decir que el subsistema de IO está fallando y es fundamental que hagamos un analisis causa raiz y verifiquemos el hardware

Para limitarnos a los errores de SQL Server podemos consultar msdb.dbo.suspect_pages, esta tabla de sistema debe ser depurada cada cierto tiempo para evitar problemas.

En sistemas de Mirror o Availability Groups, estos pueden ser reparados debido a un método de auto repair, pero el que SQL Server solvente el problema no quita que el origen del error aun exista y pueda replicarse.

Otro caso es corrupción en memoria, normalmente se da de manera inversa, la corrupción en disco es cuando escribimos de memoria a disco, en el caso de memoria es cuando llevamos información de disco a memoria y la denotamos con el error 832 (no el 823).

SQL Server 2012 y superiores en Windows 2012 o superior también cuentan con reparación automática a paginas en memoria.

La mejor manera de prevenir corrupción es monitorear por este tipo de errores o backups que no terminan a tiempo, debemos de ser conscientes que la corrupción a pesar de nuestros mejores esfuerzos es algo que no podemos prevenir, y lo mejor es tener copias de seguridad al día.

Más información

En el blog personal de Paul Randal

http://www.sqlskills.com/blogs/paul/

(Por favor tengan calma y lean varias veces los post de Paul Randal son muy buenos pero altamente tecnicos)

• Los bugs pueden causar co o de rrupción aunque es bastante raro en genera