Solución de errores de coherencia de base de datos notificados por DBCC CHECKDB

  • Artículo

En este artículo se explica cómo solucionar los errores notificados por el DBCC CHECKDB comando.

Versión del producto original: SQL Server
Número de KB original: 2015748

Síntomas

Cuando se ejecuta DBCC CHECKDB (u otros comandos similares como DBCC CHECKTABLE), se escribe un mensaje como el siguiente en el registro de errores SQL Server:

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

Este mensaje muestra cuántos errores de coherencia de base de datos se encontraron y cuántos se repararon, si se usó una opción de reparación. Este mensaje también se escribe en el registro de eventos de la aplicación Windows como un mensaje de nivel de información con EventID=8957. Incluso si se notifican errores, este mensaje es un mensaje de nivel de información.

La información del mensaje que comienza por "instantánea de base de datos interna..." solo aparece si DBCC CHECKDB se ejecutó en línea, en el que la base de datos no está en el SINGLE_USER modo . Esto se debe a que para una instantánea de base de datos interna en línea DBCC CHECKDBse usa para presentar un conjunto coherente de datos que se van a comprobar.

En este artículo no se describe cómo solucionar cada error específico notificado por DBCC CHECKDB , sino el enfoque general si se notifican errores. Cualquier referencia a CHECKDB en este artículo también se aplica a DBCC CHECKTABLE y DBCC CHECKFILEGROUP a menos que se indique.

Causa

El DBCC CHECKDB comando comprueba la coherencia física y lógica de las páginas de base de datos, las filas, las páginas de asignación, las relaciones de índice, la integridad referencial de la tabla del sistema y otras comprobaciones de estructura. Si se produce un error en cualquiera de estas comprobaciones (en función de las opciones elegidas), se notifican errores.

La causa de estos problemas puede ir desde daños en el sistema de archivos, problemas subyacentes del sistema de hardware, problemas de controladores, páginas dañadas en memoria o caché de almacenamiento, o problemas con el SQL Server. Para obtener información sobre cómo identificar la causa principal de los errores notificados, consulte Investigación de la causa principal.

Solución

  1. Resuelva cualquier problema relacionado con el hardware subyacente en el sistema antes de continuar con la restauración de una copia de seguridad o la reparación de la base de datos. Aplique cualquier controlador de dispositivo, firmware, BIOS y actualizaciones del sistema operativo que sean relevantes para la ruta de acceso de E/S. Trabaje con el administrador de la ruta de acceso de E/S completa (máquina local, controladores de dispositivo, NIC de almacenamiento, SAN, almacenamiento back-end y caché) para aislar y resolver cualquier problema. Entre los ejemplos se incluyen la actualización de controladores de dispositivo y la comprobación de la configuración de toda la ruta de acceso de E/S. Para obtener más información sobre cómo comprobar la causa principal, consulte Investigación de la causa raíz.

  2. Si DBCC CHECKDB notifica errores de coherencia permanentes, la mejor solución sería restaurar los datos de una copia de seguridad correcta conocida. Para obtener más información, consulte Restauración y recuperación.

  3. Aplique la última SQL Server actualización acumulativa o Service Pack para asegurarse de que no tiene problemas conocidos. Consulte la documentación de Actualización acumulativa o Service Pack para ver si hay problemas conocidos corregidos relacionados con daños en la base de datos (errores de coherencia) y aplique las correcciones pertinentes. Una ubicación central donde puede buscar todas las correcciones para una versión determinada si la corrección detallada enumera SQL Server 2022, 2019, 2017.

  4. Si los DBCC CHECKDB errores son intermitentes, es decir, si aparecen en una ejecución y desaparecen en la siguiente, es posible que tenga problemas de caché de disco (ya sea controlador de dispositivo u otro problema de ruta de acceso de E/S). Trabaje con los mantenedores de la ruta de acceso de E/S para aislar y resolver cualquier problema. Entre los ejemplos se incluyen la actualización de controladores de dispositivo, la comprobación de la configuración de toda la ruta de acceso de E/S y la actualización de firmware y BIOS en los dispositivos y el sistema de la ruta de acceso de E/S.

  5. Si no es posible restaurar desde una copia de seguridad, CHECKDB tiene una característica para reparar los errores que puede usar. Hay dos niveles de reparación:

    • REPAIR_REBUILD : realiza reparaciones que no tienen posibilidad de pérdida de datos.
    • REPAIR_ALLOW_DATA_LOSS - realiza reparaciones que tienen la posibilidad de pérdida de datos.

    Para obtener más información, consulte la documentación de DBCC CHECKDB.

    Debe tener cuidado al elegir reparar con permitir la pérdida de datos, ya que puede dejar la base de datos en un estado lógicamente incoherente. La DBCC CHECKDB salida hace una recomendación sobre el nivel mínimo de reparación que se va a usar. Es una práctica habitual ejecutar con CHECKDBREPAIR_ALLOW_DATA_LOSS varias veces hasta que no se notifican más errores. Esto se debe a que, cuando la reparación corrige un conjunto de errores, se pueden descubrir otros vínculos rotos. Sin embargo, pueden aparecer nuevos errores si no se ha resuelto la causa subyacente. Por lo tanto, si problemas de nivel de sistema como hardware o sistema de archivos están causando daños en los datos, estos problemas deben solucionarse primero, antes de la restauración de una copia de seguridad o reparación. Los ingenieros de soporte técnico de Microsoft no pueden ayudar con la recuperación física de datos dañados si la reparación no corrige los errores de coherencia o si la copia de seguridad de la base de datos está dañada.

    Al ejecutar DBCC CHECKDB, se proporciona una recomendación para indicar la opción de reparación mínima necesaria para reparar todos los errores. Estos mensajes son similares a la salida siguiente:

    CHECKDB encontró 0 errores de asignación y 15 errores de coherencia en la base de datos "mydb".
    REPAIR_ALLOW_DATA_LOSS es el nivel mínimo de reparación para los errores detectados por DBCC CHECKDB (mydb).

    La recomendación de reparación es el nivel mínimo de reparación para intentar resolver todos los errores de CHECKDB. El nivel mínimo de reparación no significa que esta opción de reparación corrigió todos los errores. Algunos errores simplemente no se pueden corregir. También es posible que tenga que ejecutar el proceso de reparación más de una vez. No todos los errores notificados requieren que se resuelva el uso de este nivel de reparación. Esto significa que no todas las reparaciones por CHECKDB con REPAIR_ALLOW_DATA_LOSS el resultado en la pérdida de datos. La reparación debe ejecutarse para determinar si la resolución de un error da lugar a la pérdida de datos. Una técnica para ayudar a restringir el nivel de reparación de cada tabla es usar DBCC CHECKTABLE para cualquier tabla que informe de un error. Esto muestra el nivel mínimo de reparación de una tabla determinada.

    Advertencia

    Debe realizar la validación manual de datos una vez CHECKDB completada la reparación o exportación o importación de datos. Para obtener más información, vea Argumentos DBCC CHECKDB. Es posible que los datos no sean coherentes lógicamente después de la reparación. Por ejemplo, la reparación (especialmente REPAIR_ALLOW_DATA_LOSS la opción) podría quitar páginas de datos completas que contienen datos incoherentes. En tales casos, una tabla con una relación de clave externa con otra tabla puede terminar con filas que no tienen las filas de clave principal correspondientes en la tabla primaria.

  6. Intente crear scripts del esquema de base de datos. Use el script para crear una base de datos y, a continuación, use una herramienta como BCP o el Asistente para exportación e importación de SSIS para exportar tantos datos como sea posible desde la base de datos dañada a la nueva base de datos. Es probable que se produzca un error al exportar datos de una tabla dañada. En tales casos, omita esta tabla, vaya a la siguiente y guarde lo que pueda.

  7. Revise los artículos siguientes para ver los errores específicos generados por DBCC CHECKDB y siga los pasos proporcionados (si los hubiera). Estos son algunos ejemplos:

Investigación de la causa principal de los errores de coherencia de la base de datos

Para identificar la causa principal de los errores de coherencia de la base de datos, tenga en cuenta estos métodos:

  • Compruebe el registro de eventos del sistema windows para ver si hay errores relacionados con el nivel del sistema, controladores o discos y trabaje con el fabricante de hardware para resolverlos.
  • Ejecute los diagnósticos proporcionados por los fabricantes de hardware para el equipo o el sistema de disco.
  • Trabaje con el proveedor de hardware o el fabricante del dispositivo para asegurarse de que:
  • Considere la posibilidad de usar una utilidad como SQLIOSim en la unidad donde residen las bases de datos que han notificado los errores de coherencia. SQLIOSim es una herramienta independiente del motor de SQL Server para probar la integridad de E/S del sistema de disco. SQLIOSim se incluye con SQL Server y no requiere una descarga independiente. Se puede encontrar en la carpeta \MSSQL\Binn .
  • Consulte la documentación de Actualización acumulativa o Service Pack para ver si hay problemas conocidos corregidos relacionados con daños en la base de datos (errores de coherencia) y aplique las correcciones pertinentes. Una ubicación central donde puede buscar todas las correcciones para una versión determinada si la corrección detallada enumera SQL Server 2022, 2019, 2017.
  • Compruebe si hay otros errores notificados por SQL Server como infracciones de acceso o aserciones. La actividad en bases de datos dañadas suele dar lugar a excepciones de infracción de acceso o a errores de aserción.
  • Asegúrese de que las bases de datos usan la PAGE_VERIFY CHECKSUM opción . Si se notifican errores de suma de comprobación, se trata de una indicación de que los errores de coherencia se han producido después de que SQL Server haya escrito páginas en el disco. Por lo tanto, el subsistema de E/S debe comprobarse exhaustivamente. Para obtener más información sobre los errores de suma de comprobación, consulte Solución de problemas de Msg 824 en SQL Server.
  • Busque errores del mensaje 832 en ERRORLOG. Estos errores podrían indicar que las páginas podrían estar dañadas mientras están en caché antes de escribirse en el disco. Para obtener más información, vea Cómo solucionar problemas de Msg 832 en SQL Server.
  • En otro sistema, intente restaurar una copia de seguridad de base de datos que sabe que está "limpia" (sin errores de ) seguida de copias de seguridad del CHECKDBregistro de transacciones que abarcan el tiempo en que se generó el error. Si puede "volver a crear" este problema restaurando una copia de seguridad de base de datos "limpia" y una copia de seguridad del registro de transacciones, póngase en contacto con el soporte técnico de Microsoft para obtener ayuda.
  • Los errores de pureza de datos pueden ser un problema con la aplicación que inserta o actualiza datos no válidos en tablas de SQL Server. Para obtener más información sobre la solución de problemas de errores de pureza de datos, consulte Solución de problemas del error 2570 de DBCC en SQL Server 2005.
  • Compruebe la integridad del sistema de archivos mediante el comando chkdsk .

Más información

Para obtener más información sobre la sintaxis de DBCC CHECKDB y la información o las opciones sobre cómo ejecutar el comando, vea DBCC CHECKDB (Transact-SQL).

Si se encuentra algún error mediante CHECKDB, se notifican otros mensajes similares al mensaje siguiente en ERRORLOG con el fin de informar de errores:

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

La información de error se ha enviado a informes de errores de Watson.

Los archivos utilizados para la generación de informes de errores incluyen un archivo sqldump<nnn>.txt . Este archivo puede ser útil con fines históricos, ya que contiene una lista de los errores encontrados en CHECKDB un formato XML.

Para averiguar cuándo se ejecutó la última vez DBCC CHECKDB sin errores detectados para una base de datos (la última limpieza CHECKDBconocida), compruebe el SQL Server ERRORLOG para un mensaje como el siguiente en una base de datos de usuario o sistema (este mensaje se escribe como un mensaje de nivel de información en el registro de eventos de la aplicación Windows con EventID = 17573 también):

Fecha y hora spid7s CHECKDB para la base de datos "master" finalizó sin errores en Date/Time22:11:11.417 (hora local). Solo se trata de un mensaje informativo; no se requiere ninguna acción del usuario