Compartir a través de

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 de 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 aplicación de 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 a partir de "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 modo SINGLE_USER . Esto se debe a que para una instantánea de base de datos en línea DBCC CHECKDB, se usa una instantánea de base de datos interna para presentar un conjunto coherente de datos que se va 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 y DBCC CHECKFILEGROUP a DBCC CHECKTABLE 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 alguna de estas comprobaciones (en función de las opciones elegidas), se notifican errores.

La causa de estos problemas puede variar 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 SQL Server. Para obtener información sobre cómo identificar la causa principal de los errores notificados, vea Investigar la causa principal.

Solución

  1. Resuelva los problemas relacionados con el hardware subyacentes 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 los problemas. 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, vea Investigar la causa principal.

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

  3. Aplique la actualización acumulativa de SQL Server más reciente o Service Pack para asegurarse de que no se está ejecutando ningún problema conocido. Compruebe la documentación de actualización acumulativa o Service Pack para ver los 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 de una versión determinada si las listas de correcciones detalladas para 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 el 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 los problemas. Entre los ejemplos se incluyen la actualización de controladores de dispositivo, la comprobación de la configuración de toda la ruta de E/S y la actualización del firmware y el 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 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 precaución al tomar la decisión de reparar con permitir la pérdida de datos, ya que podría dejar la base de datos en un estado lógicamente incoherente. La DBCC CHECKDB salida realiza una recomendación sobre el nivel de reparación mínimo que se va a usar. Es una práctica habitual ejecutarse CHECKDB con REPAIR_ALLOW_DATA_LOSS varias veces hasta que no se notifiquen más errores. Esto se debe a que cuando la reparación corrige un conjunto de errores, es posible que se desencadenen otros vínculos rotos. Sin embargo, los nuevos errores pueden aparecer 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 se asemejan 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 de reparación mínimo para los errores encontrados 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 de reparación mínimo no significa que esta opción de reparación corrija 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 de la pérdida de datos. La reparación debe ejecutarse para determinar si la resolución de un error produce una pérdida de datos. Una técnica para ayudar a reducir el nivel de reparación es para cada tabla que se va a 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 después CHECKDB de que se complete la reparación o exportación de datos o la importación. 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 acabar con filas que no tienen filas de clave principal correspondientes en la tabla primaria.

  6. Intente crear un script del esquema de la base de datos. Use el script para crear una nueva base de datos y, a continuación, use una herramienta como el Asistente para exportación e importación de BCP o 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 puede.

  7. Revise los artículos siguientes para ver errores específicos generados por DBCC CHECKDB y siga los pasos proporcionados (si los hay). A continuación, encontrará 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 de Windows para ver los errores relacionados con el sistema, el controlador o el disco y trabaje con el fabricante del 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:
    • Los dispositivos de hardware y la configuración se confirman en los requisitos de entrada y salida de Motor de base de datos de Microsoft SQL Server.
    • Los controladores de dispositivo y otros componentes de software complementarios de todos los dispositivos de la ruta de acceso de E/S están actualizados.
  • 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 .
  • Compruebe la documentación de actualización acumulativa o Service Pack para ver los 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 de una versión determinada si las listas de correcciones detalladas para SQL Server 2022, 2019, 2017.
  • Compruebe si hay otros errores notificados por SQL Server, como infracciones de acceso o aserciones. La actividad contra bases de datos dañadas suele dar lugar a excepciones de infracción de acceso o errores de aserción.
  • Asegúrese de que las bases de datos usen la PAGE_VERIFY CHECKSUM opción . Si se notifican errores de suma de comprobación, se trata de una indicación de que se han producido errores de coherencia después de que SQL Server escribió 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, vea Solución de problemas de msg 824 en SQL Server.
  • Busque los errores 832 del mensaje en errorLOG. Estos errores podrían indicar que las páginas podrían estar dañadas mientras están en caché antes de escribirlas en el disco. Para obtener más información, vea Solución de problemas de msg 832 en SQL Server.
  • En otro sistema, intente restaurar una copia de seguridad de base de datos que sepa que es "limpia" (sin errores de ) seguida de copias de CHECKDBseguridad del registro 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 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 inserción o actualización de datos no válidos en tablas de SQL Server. Para obtener más información sobre cómo solucionar errores de pureza de datos, vea Solución de problemas del error DBCC 2570 en SQL Server 2005.
  • Compruebe la integridad del sistema de archivos mediante el comando chkdsk . No ejecute chkdsk mientras se ejecuta SQL Server. Podría notificar errores transitorios de archivo si SQL Server está escribiendo en los archivos que se están comprobando. Además, los modificadores como /r o /f pueden mover bytes de archivo a una ubicación diferente en el disco, y este movimiento podría provocar daños si SQL Server también está escribiendo o leyendo desde estos archivos. Por lo tanto, asegúrese de detener SQL Server antes de ejecutar el chkdsk comando. Además, tenga cuidado con las opciones de reparación como /r y /f. Asegúrese de que tiene una copia de seguridad de las bases de datos antes de ejecutar una reparación, ya que estas opciones pueden dañar los archivos, si encuentra errores de disco en chkdsk.

Más información

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

Si se detectan errores mediante CHECKDB, se notifican otros mensajes similares al siguiente en errorLOG para los fines de los informes 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 al informe de errores de Watson.

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

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

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