Si te encuentras con alguna parte que no entiendes puedes dejarlo en la sección de comentarios y te responderemos lo más rápido posible.
Solución:
DBCC CHECKDB es vital para que las bases de datos de SQL Server estén 100% seguras de que no hay daños. Sin embargo, debido a que las bases de datos están aumentando enormemente en tamaño, es muy difícil encontrar una ventana de mantenimiento cuando afirma estar disponible las 24 horas del día, los 7 días de la semana. 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 PAGE_VERIFY = CHECKSUM lo que puede ayudarlo a detectar de manera proactiva la corrupción física en las páginas de la base de datos, agregando así 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.
También, respaldo (completo o diferencial) con CHECKSUM garantizará la detección de 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 y reportarlo. (Asegúrese de configurar también Alertas importantes relacionadas con daños).
Dicho esto, todavía corrupción lógica, errores inducidos por el escribiente – 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 Errores de SQL Server, etc.son indetectables con los métodos anteriores y, por lo tanto, CHECKDB entra en escena.
DBCC CHECKDB realiza comprobaciones más exhaustivas que incluyen la comprobación de los encabezados de las páginas en busca de posibles daños que no sean detectables por ningún otro medio.
¿Algún guión existente por ahí?
En lugar de reinventar la rueda, te recomiendo encarecidamente que eches un vistazo a Solución de comprobación de integridad de SQL Server de Ola
Ejecución eficiente de DBCC CHECKDB:
Solo necesita ser creativo cuando está limitado en la ventana de mantenimiento y tiene grandes bases de datos o un gran número de bases de datos para ejecutar CHECKDB.
Después de asistir a la capacitación de SQLSkills, lo que he implementado en mi entorno es:
- priorice qué tablas son críticas para verificar.
- separe las tablas en grupos con diferentes prioridades y luego ejecute
DBCC CHECKTABLEjunto con correrDBCC 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 enormemente 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 se eliminará su CHECKDB una vez que haya pasado la ventana de mantenimiento
- Agregue el tiempo que tardó en ejecutarse por tabla
DBCC CHECKTABLE,DBCC CHECKALLOCyDBCC CHECKCATALOG. Para que puedas tener una idea de cuánto dura por lo general tomando sus cheques para correr. - Incluso puedes correr con
NOINDEXopción, ya que acelerará la operación, ya que no verifica los índices no agrupados en las tablas de usuario. Esto tiene alguna ventaja, ya que no es tan crítico como la corrupción de datos, ya que no se pierden datos y puede eliminar y volver a crear el índice si es necesario.
Obviamente, la edición Enterprise puede aprovechar la ejecución paralela de declaraciones DBCC, pero tenga cuidado con la configuración de MAXDOP, ya que podría terminar ocupando toda su CPU. El gobernador de recursos puede limitar esto con fuerza.
Nota: Si tiene una columna SPARSE, entonces su CHECKDB será muy lento como se describe aquí.
Finalmente, es cómo prevenir la corrupción de la base de datos utilizando todas las herramientas disponibles + su fe en el sistema de hardware del servidor de su base de datos y lo más importante, el valor de sus datos.
Algunas excelentes referencias:
- ¿Es CHECKDB una necesidad?
- Comprobaciones DBCC y bases de datos a escala de terabytes
- Semana SQLU VLDB – Comprobaciones de integridad
- Las mejoras para el comando DBCC CHECKDB pueden resultar en un rendimiento más rápido cuando usa la opción PHYSICAL_ONLY
- Comprobación de la base de datos de SQL Server 2008
¿Son estos controles adicionales necesarios / importantes? (Las vistas indexadas son probablemente un poco más preocupantes para mí, no creo que estemos usando Service Broker o FILESTREAM todavía).
Tu puedes correr DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKSdirectamente en las vistas indexadas. La comprobación de vistas indexadas puede resultar problemática en determinadas circunstancias, así que esté preparado para investigar cualquier false positivos que resultan. (Paul Randal también menciona en los comentarios al artículo de referencia que false los negativos también son posibles, pero no tengo experiencia directa de eso).
Si es así, ¿existen formas de realizar estas comprobaciones adicionales por separado?
No hay soporte para ejecutar Service Broker o FILESTREAM cheques por separado, no.
CHECKALLOCyCHECKCATALOGparece funcionar muy rápido, incluso en grandes bases de datos. ¿Alguna razón para no ejecutarlos todos los días?
No que yo sepa.
También podrías considerar correr DBCC CHECKCONSTRAINTS. Este cheque es no incluido en DBCC CHECKDB, independientemente de las opciones que pueda especificar. Es posible que también desee pensar en de vez en cuando corriendo CHECKDB, cuando las circunstancias lo permitan.
valoraciones y comentarios
Nos puedes añadir valor a nuestra información dando tu experiencia en las interpretaciones.