Dividiendo DBCC CHECKDB durante varios días

10

Estoy trabajando en la implementación del método de Paul Randal de difundir manualmente DBCC CHECKDB durante varios días para bases de datos muy grandes, que básicamente consiste en:

  • Dividiendo las tablas en la base de datos aproximadamente por igual entre 7 cubos
  • Ejecutar un DBCC CHECKALLOC dos veces por semana
  • Ejecutar un DBCC CHECKCATALOG una vez por semana
  • Ejecutar un DBCC CHECKTABLE en un cubo cada día de la semana

¿Alguien ha usado esta técnica? ¿Hay guiones existentes por ahí?

Me preocupa que esto en realidad no cubra todo lo que CHECKDB hace; La documentación de Books Online para CHECKDB dice que además de CHECKALLOC, CHECKCATALOG y CHECKTABLE, también:

  • Valida el contenido de cada vista indizada en la base de datos.
  • Valida la consistencia a nivel de enlace entre los metadatos de la tabla y los directorios y archivos del sistema de archivos al almacenar datos varbinary (max) en el sistema de archivos usando FILESTREAM. (Solo SQL 2008)
  • Valida los datos de Service Broker en la base de datos.

Asi que aqui están mis preguntas:

  1. ¿Son estos controles adicionales necesarios / importantes? (Las vistas indexadas son probablemente un poco más preocupantes para mí, no creo que estemos utilizando Service Broker o FILESTREAM todavía).

  2. Si es así, ¿hay formas de realizar estas verificaciones adicionales por separado?

  3. CHECKALLOC y CHECKCATALOG parecen ejecutarse muy rápidamente, incluso en dbs grandes. ¿Alguna razón para no ejecutar estos todos los días?

(Nota: esta será una rutina estándar para miles de bases de datos existentes en cientos de servidores, o al menos para todas las bases de datos de cierto tamaño. Esto significa que opciones como la reestructuración de todas las bases de datos para usar CHECKFILEGROUP no son realmente prácticas para nosotros).

sql-server dbcc-checkdb vldb BradC
fuente
Paul respondió a una versión de esta pregunta en los comentarios en su blog. Dijo: "No se preocupe por la validación de la vista indexada. Está desactivada por defecto desde 2008 en adelante porque no encontró problemas".
BradC
Estoy trabajando para hacer lo mismo: ¿algún consejo / problema que haya encontrado, ya que probablemente ya lo haya implementado?
scsimon
1
@scsimon Lo hice funcionar bien, vea esta pregunta relacionada para la estrategia específica que utilicé para dividir las tablas. Creo que finalmente hice una lista maestra de todas las tablas en todas las bases de datos (grandes) en todo el servidor para dividirlas en los "cubos" diarios, lo que me dio una división mucho más uniforme que dividir la lista de cada base de datos individualmente. Bases de datos más pequeñas Acabo de hacer un DBCC completo cada día, y no formaba parte de la división.
BradC

Respuestas:

6

¿Son estos controles adicionales necesarios / importantes? (Las vistas indexadas son probablemente un poco más preocupantes para mí, no creo que estemos utilizando Service Broker o FILESTREAM todavía).

Puede ejecutar DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS directamente en las vistas indexadas . Verificar las vistas indexadas puede ser problemático en ciertas circunstancias , así que prepárese para investigar cualquier falso positivo que resulte. (Paul Randal también menciona en los comentarios al artículo referenciado que los falsos negativos también son posibles, pero no tengo experiencia directa en eso).

Si es así, ¿hay formas de realizar estas verificaciones adicionales por separado?

No hay soporte para ejecutar Service Broker o FILESTREAMcheques por separado, no.

CHECKALLOCy CHECKCATALOGparece correr muy rápido, incluso en dbs grandes. ¿Alguna razón para no ejecutar estos todos los días?

No que yo sepa.

También podrías considerar correr DBCC CHECKCONSTRAINTS. Esta comprobación se no incluido en DBCC CHECKDB, independientemente de las opciones que puede especificar. También es posible que desee pensar en correr ocasionalmenteCHECKDB , cuando las circunstancias lo permitan.

Paul White 9
fuente
6

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:

Kin Shah
fuente