DBCC CHECKDB es vital para que las bases de datos de SQL Server estén 100% seguras de que no hay corrupción. Sin embargo, debido a que las bases de datos crecen en tamaño, es muy difícil encontrar una ventana de mantenimiento cuando afirmas que funciona 24x7. A lo largo de los años, el equipo de SQL Server ha implementado varios mecanismos que detectarán las formas más comunes de corrupción especialmente relacionadas con la corrupción física causada por el hardware.
SQL Server 2005 y versiones posteriores tienen PAGE_VERIFY = CHECKSUM que puede ayudarlo a detectar de manera proactiva la corrupción física en las páginas de la base de datos, lo que agrega una suma de verificación a cada página a medida que se escribe en el sistema de E / S y valida la suma de verificación a medida que se lee desde el disco.
Además, la copia de seguridad (completa o diferencial) con CHECKSUM garantizará detectar cualquier daño de E / S causado por el hardware.
Por lo tanto, desde el lado del hardware de la corrupción, SQL Server hace un buen trabajo al detectarlo e informarlo. (Asegúrese de establecer alertas importantes relacionadas con la corrupción también).
Dicho esto, sigue siendo corrupción lógica , errores inducidos por el garabateador , donde las páginas en memoria están dañadas por código de terceros que se ejecuta dentro del proceso de SQL Server o por controladores u otro software con privilegios suficientes que se ejecutan en modo kernel de Windows y / o SQL Server Los errores , etc. son indetectables utilizando los métodos anteriores y, por lo tanto, CHECKDB aparece en la imagen.
DBCC CHECKDB realiza verificaciones más exhaustivas que incluyen la verificación de encabezados de página para detectar posibles daños que no son detectables por ningún otro medio.
¿Hay guiones existentes por ahí?
En lugar de reinventar la rueda, le recomiendo que eche un vistazo a la solución de comprobación de integridad del servidor SQL de Ola
Ejecución eficiente de DBCC CHECKDB:
Solo necesita ser creativo cuando tiene poco espacio de mantenimiento con grandes bases de datos o una gran cantidad de bases de datos para ejecutar CHECKDB.
Después de asistir a la capacitación SQLSkills, lo que he implementado en mi entorno es:
- priorizar qué tablas son críticas para verificar.
- separar las mesas en grupos con diferentes prioridades y luego ejecutar
DBCC CHECKTABLEjunto con el corredor DBCC CHECKALLOCyDBCC CHECKCATALOG
- Cree una tabla de trabajo que almacenará los nombres de las tablas con prioridades. Solo asegúrese de que todas las tablas de alta prioridad (que son masivamente grandes) no estén en un grupo; de lo contrario, su CHECKDB no se completará en absoluto.
- Incluso puede tener una columna de tiempo de espera en su tabla de trabajadores que orquestará cuándo su CHECKDB será asesinado una vez que haya pasado la ventana de mantenimiento
- Añadir el tiempo que tomó por mesa a plazo
DBCC CHECKTABLE, DBCC CHECKALLOCy DBCC CHECKCATALOG. Para que pueda tener una idea de cuánto tiempo tarda generalmente en ejecutarse sus cheques.
- Incluso puede ejecutar con la
NOINDEXopción ya que acelerará la operación ya que no verifica los índices no agrupados en las tablas de usuario. Esto tiene cierta ventaja, ya que no es tan importante como la corrupción de datos, ya que no se pierden datos y puede soltar y volver a crear el índice si es necesario.
Obviamente, la edición Enterprise puede aprovechar la ejecución paralela de las sentencias DBCC, pero tenga en cuenta la configuración MAXDOP, ya que podría acabar con toda su CPU. Esto puede ser difícilmente limitado por el gobernador de recursos.
Nota: Si tiene una columna SPARSE, su CHECKDB estará muy lento como se describe aquí .
Finalmente, es cómo prevenir la corrupción de la base de datos utilizando todo el conjunto de herramientas disponibles + su fe en el sistema de hardware de su servidor de base de datos y lo más importante el valor de sus datos.
Algunas excelentes referencias: