Por: Brady Upton | Actualizado: 2016-07-26 | Comentarios (2) | Relacionado: Más > Comandos de la consola de base de datos DBCCs

Problema

La corrupción de la base de datos de SQL Server puede ser un problema y puede causar graves daños a una base de datos. Si usted es un DBA experimentado, entonces usted probablemente tiene salvaguardias para detectar esto, pero a lo largo de los años he visto cientos de servidores SQL sin métodos de detección en absoluto y esto es un problema. Hay algunas maneras de detectar la corrupción de la base de datos, pero este consejo se centrará más en DBCC CHECKDB.

Solución

Usted puede o no puede haber oído hablar deDBCC (comandos de la consola de base de datos) declaraciones. Estas sentencias se utilizan para realizar diferentes operaciones en su base de datos y se pueden dividir en cuatro categorías:Mantenimiento, Miscelánea, Informativa y Validación. Yo utilizo algunas de las sentencias DBCC a diario, pero ninguna más que DBCC CHECKDB.

Qué es DBCC CHECKDB de SQL Server

DBCC CHECKDB, de la biblioteca MSDN de Microsoft, comprueba la integridad lógica y física de todos los objetos de la base de datos especificada realizando las siguientes operaciones:

  • Ejecuta DBCC CHECKALLOC en la base de datos – Comprueba la coherencia de las estructuras de asignación de espacio en disco para una base de datos especificada.
  • Ejecuta DBCC CHECKTABLE en cada tabla y vista de la base de datos – Comprueba la integridad de todas las páginas y estructuras que componen la tabla o vista indexada.
  • Ejecuta DBCC CHECKCATALOG en la base de datos – Comprueba la consistencia del catálogo dentro de la base de datos.
  • Valida el contenido de cada vista indexada 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 cuando se almacenan datos varbinarios (máximos) en el sistema de archivos utilizandoFILESTREAM.
  • Valida los datos del Service Broker en la base de datos

Si alguna vez ha ejecutado DBCC CHECKDB sabe que tarda un poco en las bases de datos grandes.Ahora que conoce todos los pasos que se ejecutan, puede ver por qué tarda en completarse.

¿Cómo puede ayudarme SQL Server DBCC CHECKDB?

La corrupción de datos es mala. Puede causar todo tipo de problemas dentro de la base de datos que pueden incluir resultados de datos incorrectos, sentencias SQL fallidas y, en algunos casos, puede hacer caer toda la instancia SQL. DBCC CHECKDB le advierte de la corrupción para que pueda solucionarlo antes (con suerte) de que sea demasiado grave.

¿Cómo se utiliza DBCC CHECKDB de SQL Server?

DBCC CHECKDB es bastante sencillo. Hay algunas opciones que puede utilizar con la declaración y vamos a ir sobre algunos de ellos en la siguiente sección, pero la sintaxis básica se parece a esto:

DBCC CHECKDB ('DatabaseName') 

Muy simple.

Automatizar SQL Server DBCC CHECKDB

Obviamente, usted no quiere entrar cada mañana y ejecutar esta declaración en cada base de datos, por lo que puede automatizar este proceso utilizando algunos métodos diferentes:

  • Planes de mantenimiento de SQL Server – Los planes de mantenimiento son parte de SQL Server fuera de la caja (a menos que esté ejecutando ExpressEdition). No me gusta usar los planes de mantenimiento en su mayoría, pero no me importa usarlos para este tipo de tareas. En la caja de herramientas del Plan de Mantenimiento tendrá que utilizar la tarea de Comprobar la integridad de la base de datos. La única opción configurable es incluir los índices, por lo que no es realmente fácil de usar, pero en algunos casos esto es todo lo que necesitas. De nuevo, hablaremos de otras opciones en la siguiente sección.
  • Scripts personalizados – Los scripts personalizados son normalmente lo que uso y ofrecen la mejor flexibilidad en cuanto a la adición de las opciones que desee. Mis go-toscripts ya están creados y son de uso gratuito deOla Hallengren. Él ha hecho un trabajo maravilloso al crearlos y compartirlos con el mundo. GraciasOla!
    • Comprueba los scripts en MSSQLTips.com:
    • Realizar mantenimiento con bases de datos de SQL Server en modo de recuperación completa
    • Planes de mantenimiento de bases de datos de SQL Server y gestión de archivos de copia de seguridad
    • Realizar mantenimiento de SQL Server sin ventana de mantenimiento

Opciones de DBCC CHECKDB de SQL Server

Hay unas cuantas opciones para usar con DBCC CHECKDB y aquí repasaré algunas de las más populares:

  • NOINDEX – Especifica que no se deben realizar comprobaciones intensivas de los índices no agrupados para las tablas de usuario. Esto disminuye el tiempo de sobrealineación. NOINDEX no afecta a las tablas del sistema porque las comprobaciones de integridad siempre se realizan en los índices de las tablas del sistema.
  • NO_INFOMSGS – Suprime todos los mensajes de información.
  • PHYSICAL_ONLY – Limita la comprobación a la integridad de la estructura física de las cabeceras de páginas y registros y a la consistencia de la asignación de la base de datos. Esta comprobación está diseñada para proporcionar una pequeña sobrecarga de comprobación de la consistencia física de la base de datos, pero también puede detectar páginas rotas, fallos de suma de comprobación y fallos de hardware comunes que pueden comprometer los datos de un usuario.
  • TABLOCK – Hace que DBCC CHECKDB obtenga bloqueos en lugar de utilizar una instantánea interna de la base de datos. Esto incluye un bloqueo (X) exclusivo a corto plazo en la base de datos. TABLOCK hará que DBCC CHECKDB se ejecute más rápidamente en una base de datos con mucha carga, pero disminuye la concurrencia disponible en la base de datos mientras se ejecuta DBCC CHECKDB.
  • DATA_PURITY – Hace que DBCC CHECKDB compruebe la base de datos en busca de valores de columna que no sean válidos o estén fuera de rango. Por ejemplo, DBCC CHECKDBdetecta columnas con valores de fecha y hora que son mayores o menores que el rango aceptable para el tipo de datos datetime; o columnas de tipo decimal o numérico aproximado con valores de escala o precisión que no son válidos.

Vamos a repasar algunas de las opciones de REPARACIÓN en una sección diferente más adelante.

¿Con qué frecuencia debo comprobar la corrupción de SQL Server?

Cada minuto de cada día. Es una broma.

Si usted tiene una ventana de mantenimiento diario, sería bueno para comprobar la corrupción de datosdiariamente. Cuanto más rápido se pueda detectar, menos daño puede hacer. Me he dado cuenta de que mucha gente ejecuta esto en el fin de semana, especialmente con las bases de datos más grandes. No hay nada bueno o malo en esto, sólo asegúrese de tenerlo programado periódicamente.

¿Tengo que ejecutar DBCC CHECKDB en mi entorno de producción?

No, bueno sí. Más o menos.

Para comprobar la corrupción de los datos no sirve de nada ejecutar DBCC CHECKDB en su entorno de prueba… A MENOS que restaure una copia de su entorno de producción para probarlo y luego lo ejecute. BRILLANTE!

Tal vez se pregunte si algunas opciones de HA son adecuadas como AlwaysOn, LogShipping, etc.? No, tiene que comprobar su entorno de producción *live*.

Ahora que DBCC CHECKDB está configurado y ejecutado, ¿qué busco?

¡Felicidades! Usted tiene DBCC CHECKDB automatizado y en ejecución, pero ¿ahora qué? Si tiene configurado un trabajo de agente de SQL Server, asegúrese de configurar el correo de la base de datos, un operador y una notificación en el trabajo. Si el trabajo tiene éxito, sigue con tu hermoso día. Si el trabajo falla, entonces tenemos algo de trabajo que hacer.

Puede ver un error como este:

El recuento de páginas In-row data USED para el objeto «tablename», index ID 2, partitionID 608313809829888, alloc unit ID 608313809829888 (type In-row data) es incorrecto.Ejecute DBCC UPDATEUSAGE. (Error 2508) El In-row data RSVD pagecount para el objeto «tablename», index ID 2, par… El paso falló.

o esto:

Objeto ID 2088535921, índice ID 0, partición ID 72345201021503994, asignación unitID 72345201051571606 (tipo In-row data): No se ha podido procesar la página (1:94299). Msg 8939, Nivel 16, Estado 98, Línea 1 Error de tabla: ID de objeto 2088535921, ID de índice 0, ID de partición 72345201021503994, unitID de asignación 72345201051571606 (tipo de datos en fila), página (1:94299). La prueba (IS_OFF (BUF_IOERR,pBUF->bstat)) falló. CHECKDB encontró 0 errores de asignación y 2 errores de consistencia en la tabla ‘tablename’ (ID de objeto 2088535921). CHECKDB encontró 0 errores de asignación y 2 errores de consistencia en la base de datos ‘tablename’. repair_allow_data_lossis el nivel mínimo de reparación para los errores encontrados por DBCC CHECKDB (Database).

En primer lugar, no se asuste. En segundo lugar, compruebe las copias de seguridad. Los errores de DBCC CHECKDB suelen indicar lo que hay que hacer.

Para el primer error, un DBCC UPDATEUSAGE corregirá las inexactitudes del recuento de páginas y filas en las vistas del catálogo. Bastante inofensivo.

El segundo error informa de la corrupción de los datos. El error menciona el uso de repair_allow_data_loss como nivel mínimo de reparación. Esto significa que puede ejecutar la sentencia con este argumento, pero puede perder datos. Por eso siempre recomiendo restaurar a una copia de seguridad si se puede. Necesita asegurarse de que la copia de seguridad no contiene datos corruptos y quiere asegurarse de que no hay pérdida de datos.

Cómo reparar una base de datos de SQL Server

Si no tiene una copia de seguridad, es posible que tengamos que usar DBCC CHECKDB con una opción de reparación.Aquí están las opciones de reparación que están disponibles para usar. Estas pueden o no funcionar y deben usarse como último recurso:

  • REPAIR_ALLOW_DATA_LOSS – Intenta reparar todos los errores reportados.Estas reparaciones pueden causar alguna pérdida de datos.
  • REPAIR_REBUILD – Realiza reparaciones que no tienen posibilidad de pérdida de datos. Esto puede incluir reparaciones rápidas, como la reparación de las filas que faltan en los índices no agrupados, y reparaciones que requieren más tiempo, como la reconstrucción de un índice.

Como dije antes, es muy importante tener copias de seguridad actualizadas para recuperarse de la corrupción. La corrupción no importa la cantidad de datos que tengas, la versión de SQL que estés ejecutando o lo elegante que sea tu centro de datos.

Me siento bastante bien con esto, pero ¿qué más puedo usar para proteger mis instancias de SQL?

DBCC CHECKDB debería ejecutarse en todas las instancias de SQL que tenga, pero hay un par de otras formas que pueden ayudar a detectar/prevenir la corrupción de datos.

  • Alertas del agente de SQL Server – Brian Kelley escribió un buen consejo sobre este tema aquí.
  • Verificación de páginas – Asegúrese de que sus bases de datos están usando la verificación de páginas CHECKSUM. Si usted todavía está ejecutando SQL 2005 o por debajo de esto no está disponible, pero después de actualizar asegúrese de cambiar esta configuración. Para ver la configuración de verificación de páginas, utilice la siguiente sentencia:
select name, page_verify_option_desc from sys.databases 
Siguientes pasos
  • Asegúrese de revisar la biblioteca deMSDN para obtener más detalles en profundidad sobre DBCC CHECKDB
  • MSSQLTips.com tiene una buena colección de consejos sobreComprobaciones de consistencia de bases de datos que pueden ser útiles también.

Última actualización: 2016-07-26

Acerca del autor
Brady Upton es un administrador de bases de datos y superestrella de SharePoint en Nashville, TN.
Ver todos mis consejos
Recursos relacionados

  • Más consejos de DBA de SQL Server…

Deja una respuesta

Tu dirección de correo electrónico no será publicada.