Mantenimiento Parte 3/4 Revision de integridad (Integrity check)


Las revisiones de integridad posiblemente sean la menos usada de las 3 principales partes del mantenimiento, cuando vemos su importancia normalmente es después de un desastre lo cual no es la mejor manera de aprender, pero en ocasiones necesaria. La integridad de datos que hablaremos aquí no est{a relacionada con la que se enfoca en que los datos entren de la manera esperada sino la consistencia de los archivos que contienen los datos.

La integridad está compuesta principalmente por la ejecución del comando dbcc checkdb o sus derivados, como lo serian el checkfilegroup, en el checkdb este hace lo que sería un checkalloc, checktable y checkcatalog.

¿Porque hacerlo?

La revisión de integridad se debe de llegar acabo rutinariamente para saber cuándo tenemos presencia de corrupción tanto recuperable como irrecuperable y poder volver un estado sano, esto puede ser por diferentes razones que van desde fallas de usuario, fallas de voltaje, daño en storage hasta fallas del mismo motor, sino lo hacemos y sacamos backups estos llevaran la corrupción y el restaurarlos nos dará como resultado una base corrupta, en ocasiones la corrupción es leve y puede ser reparada, en otros más severos y no haber otra opción que restaurar del backup.

¿Qué hacer?

Las revisiones de integridad es un proceso rápido (en comparación de un backup) pero también tiene opciones, las más importantes que tienen que ver con la revisión de integridad son Physical_Only y Data_Purity. 
  • Data Purity: Lo que esta opción nos da el ver que no los valores en las tablas no estén fuera de los rangos de sus tipos de datos, esto es especialmente importante hacerlo cuando cambiamos o hacernos una migración "in place" es bueno hacer una revisión de este tipo por decir si los valores de fecha cambiaron, o si el número máximo de un campo numérico cambio.
  • Physical Only: Como el nombre lo dice es una revisión que solo toca las páginas y los cabezas de registro, aunque también revisa por "torn pages" y checksum" buscando daños en la estructura física normalmente comprometida por el hardware donde se trabaja, a cambio de una revisión exhaustiva se obtiene una mejora de velocidad sobre el checkdb completo.

¿Como hacerlo?

Aunque la afección es mucho menor que un backup lo mejor es buscar dentro de un SLA hacer la revisión de integridad, normalmente va atada a los backups (o antes o después), en caso de que la base empiece a ser muy grande como DWH o bases de SAP es bueno usar en su lugar el "Physical Only" checkfilegroup aunque cada cierto tiempo es bueno hacer una revisión completa.

¿A que hacerlo?

Esta pregunta es de más importante y también va mucho de la mano sobre los SLA, que bases son las más críticas, normalmente lo haremos en especial sobre las de usuario pero es importante considerar la master y la MSDB, la master almacena logins, etc y es posible que se corrompa, y la MSDB tiene mucha información sobre lo que son los jobs.

Ejemplo por linea de comandos

dbcc checkdb('master')

Ejemplo por SSMS



Posiblemente la imagen menos interesante de toda la red, como puede apreciar no existe una manera de hacerlo con SSMS, fuera de los planes internos de mantenimiento.

Ejemplo con scripts de OLA Hallengren

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'USER_DATABASES',
@CheckCommands = 'CHECKDB',
@PhysicalOnly = 'Y'

https://ola.hallengren.com/sql-server-integrity-check.html

Este script por citar un ejemplo donde se revisaran la integridad a nivel físico de todas las bases de usuario usando Checkdb.

Nota: Una cosa que no mencione en el post anterior es que los scripts de ola pueden dejar un log, lo cual es bastante util en varios casos ya que podemos ver el crecimiento de una base en tiempo.

Post Relacionados:

Comentarios

Entradas más populares de este blog

Mover indices no clustered a un nuevo filegroup