DBCC CHECKDB Not Run Recently

Cuando SQL Server escribe datos en sus unidades, simplemente asume que todo está bien hasta que necesita leer los datos de nuevo.

Desgraciadamente, en caso de corrupción del almacenamiento, éste no es tan amable como para alertar a SQL Server. Y a veces, se sabe que SQL Server se corrompe a sí mismo.

Necesitamos comprobar periódicamente para asegurarnos de que los datos en el disco todavía tienen sentido, y ahí es donde entra DBCC CHECKDB. Comprueba tanto los errores de asignación como los de consistencia. Además, si hay algún problema, los mensajes de error volverán con información sobre dónde existen los errores, la gravedad del error, así como la opción de reparación sugerida.

Es esencial ejecutar CHECKDB de forma regular para encontrar errores si existen, porque si hay corrupción, tenemos que arreglarlo antes de que nuestras últimas copias de seguridad buenas desaparezcan.

Para encontrar el problema, comprobamos cada base de datos para asegurarnos de que DBCC CHECKDB ha completado una comprobación con éxito en las últimas dos semanas.

¿No te lo crees?

«Pero yo ejecuto CHECKDB todo el tiempo», podría decir – bueno, vamos a averiguarlo:

Eso es. Pero la salida es una pesadilla. Son unas 80 líneas de cosas que probablemente nunca te importarán. Alrededor de la línea 50 es lo que estás buscando.

Hola, soy una tontería.

¡Y esto es probablemente lo que verás! Una fecha de 1900-01-01 etc. Eso significa que nunca. Si ejecuta DBCC CHECKDB en la base de datos, tal vez así:

Y luego vuelve a ejecutar el comando DBCC DBINFO, nuestra fecha se actualiza a la actual:

Mira cómo nos estamos divirtiendo

Si la fecha no se actualiza, eso significa una de dos cosas: SQL Server no puede escribir en la base de datos (como si fuera de sólo lectura), o está encontrando errores (hoowee, no es bueno.)

Para solucionar el problema

Decida si desea utilizar los planes de mantenimiento incorporados, o una herramienta gratuita como los scripts CHECKDB gratuitos de Ola Hallengren. Un par de consideraciones:

• Los planes de mantenimiento tienen una interfaz gráfica, en caso de que no sepas T-SQL.
• Los scripts gratuitos de Ola Hallengren se encargan de las opciones de ajuste, como la ejecución automática de las comprobaciones de pureza de datos (lo cual es bueno).

Cómo configurar el mantenimiento regular para comprobar si hay corrupción

Opción 1: Utilizar un plan de mantenimiento para ejecutar DBCC CHECKDB

Si está utilizando planes de mantenimiento, puede editar los planes de mantenimiento en SQL Server Management Studio en Gestión, Planes de mantenimiento. Su servidor puede tener varios planes de mantenimiento que ejecutan CHECKDB para diferentes tipos de bases de datos, como uno para las bases de datos del sistema y otro para las bases de datos de usuario.

Despliegue el nodo Gestión en SSMS, haga clic con el botón derecho en Planes de mantenimiento y seleccione Nuevo plan.

Desde la ventana de la caja de herramientas, que a veces se esconde a la izquierda, arrastre la Tarea de Comprobación de la Integridad de la Base de Datos a la pestaña del Plan de Mantenimiento.

Cuando haga doble clic en el cuadro de Tarea de Comprobación de la Integridad de la Base de Datos en la pestaña del Plan de Mantenimiento, podrá elegir qué bases de datos quiere que se comprueben durante el proceso.

A partir de ahí, lo único que queda es programarlo, que es igual que programar un Trabajo de Agente.

Después de guardar y cerrar el plan de mantenimiento, asegúrese de encontrar el trabajo relacionado en el Agente de SQL Server y configure las propiedades de Notificación para avisar a un operador si falla.

Opción 2: Configurar trabajos de SQL Agent para ejecutar DBCC CHECKDB utilizando los scripts gratuitos de Ola Hallengren

Si está implementando comprobaciones de integridad por primera vez, considere utilizar los scripts de mantenimiento gratuitos de Ola Hallengren. No son tan fáciles como los planes de mantenimiento, pero son mucho más flexibles. También incluyen la posibilidad de dividir las operaciones de DBCC en trozos más pequeños para las bases de datos grandes. En bases de datos muy grandes CHECKDB puede tomar una cantidad significativa de tiempo y recursos – la opción WITH PHYSICAL_ONLY es más rápida, pero omite las comprobaciones lógicas.

Una vez que los trabajos del Agente están en su lugar, puede programarlos para que se ejecuten de forma tan simple como los Planes de Mantenimiento, o puede afinarlos con las opciones adicionales documentadas aquí.