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

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 que empieza con "instantánea de base de datos interna..." solo aparece si DBCC CHECKDB se ejecutó en línea, caso en el que la base de datos no está en modo SINGLE_USER. Esto se debe a que para una DBCC CHECKDB en línea, 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 DBCC CHECKTABLE y DBCC CHECKFILEGROUP, salvo que se indique lo contrario.

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 alguna de estas comprobaciones falla (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 toda la ruta de E/S (máquina local, controladores de dispositivo, NIC de almacenamiento, SAN, almacenamiento back-end y caché) y memoria (RAM) 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 investigar la causa principal, consulte 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 el Service Pack para asegurarse de que no se encuentre con ningún problema conocido. Compruebe la documentación de actualización acumulativa o Service Pack para ver cualquier problema conocido corregido relacionado 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; consulte 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 un problema del controlador del dispositivo o de otra ruta de E/S). Trabaje con los responsables de la ruta 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 de la ruta de E/S y en el sistema.

  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 la opción Permitir pérdida de datos, ya que podría dejar la base de datos en un estado lógicamente incoherente. El resultado de DBCC CHECKDB realiza una recomendación sobre el nivel de reparación mínimo que se va a usar. Es una práctica habitual ejecutar 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, otros vínculos rotos pueden quedar al descubierto. 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 procedentes 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 el uso de este nivel de reparación para resolverse. Esto significa que no todas las reparaciones por CHECKDB con REPAIR_ALLOW_DATA_LOSS provocan pérdida de datos. Reparar debe ejecutarse para determinar si la resolución de un error produce una pérdida de datos. Una técnica para ayudar a determinar con más precisión cuál es el nivel de reparación de cada tabla consiste en 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 de DBCC CHECKDB. Es posible que los datos no sean coherentes lógicamente después de la reparación. Por ejemplo, la reparación (especialmente la opción REPAIR_ALLOW_DATA_LOSS) podría quitar páginas de datos completas que contienen datos incoherentes. En tales casos, una tabla con una relación de clave foránea con otra tabla puede acabar con filas que no tienen filas de clave primaria correspondientes en la tabla padre.

  6. Intente generar el 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 BCP o SSIS Export/Import Wizard 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). Estos son algunos ejemplos:

Investigar 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. La mayoría de los sistemas proporcionan diagnósticos integrados de BIOS/UEFI para el almacenamiento (unidades de disco duro), memoria, CPU, placas base, matrices RAID y varios otros componentes.
  • Trabaje con el proveedor de hardware o el fabricante del dispositivo para asegurarse de que:
    • Los dispositivos de hardware y la configuración cumplen los requisitos de entrada y salida del 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 en las que se han detectado 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 en 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 errores de aserción. Trabajar con 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 consistencia 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 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 ser escritas 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 CHECKDB) seguida de copias de seguridad del registro de transacciones que abarcan el tiempo en que se generó el error. Si puede "reproducir" 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 deberse a que la aplicación inserta o actualiza datos no válidos en tablas de SQL Server. Para obtener más información sobre cómo solucionar errores de Data Purity, 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 chkdsk encuentra errores de disco.

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, 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 sistema de notificación de errores de Watson.

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

Para averiguar la última vez que se ejecutó DBCC CHECKDB sin errores detectados para una base de datos (la última comprobación CHECKDB correcta conocida), compruebe el ERRORLOG de SQL Server. Busque un mensaje como el siguiente para una base de datos de usuario o 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):

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

  • Last updated on