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.
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.
Comentarios
Publicar un comentario