DBCC CHECKDB (Transact-SQL)

Se aplica a:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Comprueba la integridad física y lógica de todos los objetos de la base de datos especificada mediante la realización de las siguientes operaciones:

• Ejecuta DBCC CHECKALLOC en la base de datos.
• Ejecuta DBCC CHECKTABLE en todas las tablas y vistas de la base de datos.
• Ejecuta DBCC CHECKCATALOG en la base de datos.
• Valida el contenido de cada vista indizada de la base de datos.
• Valida la coherencia de nivel de vínculo entre los metadatos de la tabla y los directorios y archivos del sistema de archivos al almacenar datos varbinary(max) en el sistema de archivos mediante FILESTREAM.
• Valida los datos de Service Broker en la base de datos.

Esto significa que los comandos DBCC CHECKALLOC, DBCC CHECKTABLE o DBCC CHECKCATALOG y el comando DBCC CHECKDB no tienen que ejecutarse por separado. Para obtener información más detallada sobre las comprobaciones que realizan estos comandos, vea sus descripciones.

DBCC CHECKDB se admite en bases de datos que contienen tablas optimizadas para memoria, pero la validación solo se produce en tablas basadas en disco. Sin embargo, como parte de la copia de seguridad y la recuperación de bases de datos, la validación de CHECKSUM se realiza para los archivos de grupos de archivos optimizados para memoria.

Puesto que las opciones de reparación de DBCC no están disponibles para las tablas optimizadas para memoria, debe hacer periódicamente copia de seguridad de las bases de datos y probar dichas copias. Si se producen problemas de integridad de datos en una tabla optimizada para memoria, debe restaurar desde la última copia de seguridad válida conocida.

Convenciones de sintaxis de Transact-SQL

Sintaxis

DBCC CHECKDB
    [ ( database_name | database_id | 0
        [ , NOINDEX
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
            [ , MAXDOP = number_of_processors ]
        }
    ]
]

Nota:

Para ver la sintaxis de Transact-SQL para SQL Server 2014 y versiones anteriores, consulte Versiones anteriores de la documentación.

Argumentos

database_name | database_id | 0

Nombre o id. de la base de datos para la que se van a ejecutar comprobaciones de integridad. Si no se especifica o se especifica 0, se utiliza la base de datos actual. Los nombres de las bases de datos deben cumplir las reglas de los identificadores.

NOINDEX

Especifica que no se deben realizar comprobaciones intensivas de índices no agrupado para las tablas de usuario. Esta opción reduce el tiempo total de ejecució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.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Especifica que DBCC CHECKDB repara los errores encontrados. Utilice las opciones REPAIR solo como último recurso. La base de datos especificada debe estar en modo de usuario único para utilizar una de las siguientes opciones de reparación.

• REPAIR_ALLOW_DATA_LOSS

  Intenta reparar todos los errores indicados. Estas reparaciones pueden ocasionar alguna pérdida de datos.

  Advertencia

  La opción REPAIR_ALLOW_DATA_LOSS es una característica admitida, pero puede que no siempre sea la mejor opción para llevar una base de datos a un estado físicamente coherente. Si se realiza correctamente, la opción REPAIR_ALLOW_DATA_LOSS puede provocar la pérdida de datos. De hecho, puede producir la pérdida de más datos que si un usuario tuviera que restaurar la base de datos desde la última copia de seguridad en buen estado.

  Microsoft siempre recomienda que el usuario haga una restauración de la última copia de seguridad correcta como método principal para corregir los errores notificados por DBCC CHECKDB. La opción REPAIR_ALLOW_DATA_LOSS no es una alternativa para restaurar a partir de una copia de seguridad buena. Es una opción de emergencia como último recurso que solo le recomendamos usar si no es posible restaurar a partir de una copia de seguridad.

  Algunos errores, que solamente pueden repararse mediante la opción REPAIR_ALLOW_DATA_LOSS, pueden implicar desasignar una fila, una página o una serie de páginas para borrar los errores. El usuario ya no puede acceder a los datos desasignados ni puede recuperarlos, y no se puede determinar el contenido exacto de los datos desasignados. Por lo tanto, puede ser que la integridad referencial no sea precisa tras desasignar filas o páginas porque la comprobación y el mantenimiento de las restricciones de la clave externa no forman parte de esta operación de reparación. El usuario debe inspeccionar la integridad referencial de su base de datos (mediante DBCC CHECKCONSTRAINTS) después de usar la opción REPAIR_ALLOW_DATA_LOSS.

  Antes de realizar la reparación, debe crear copias físicas de los archivos que pertenezcan a esta base de datos. Esto incluye el archivo de datos principal (.mdf), los archivos de datos secundarios (.ndf), todos los archivos de registro de transacciones (.ldf) y otros contenedores que forman la base de datos como catálogos de texto completo, carpetas de secuencia de archivos, datos optimizados en memoria, etc.

  Antes de realizar la reparación, plantéese cambiar el estado de la base de datos al modo EMERGENCY, intente extraer tanta información como sea posible de las tablas críticas y guarde esos datos.

• REPAIR_FAST

  La sintaxis se mantiene únicamente por compatibilidad con versiones anteriores. No se realizan acciones de reparación.

• REPAIR_REBUILD

  Realiza reparaciones que no tienen ninguna posibilidad de pérdida de datos. Esta opción puede ser reparaciones rápidas, como la reparación de las filas que faltan en índices no agrupados, y reparaciones que consumen más tiempo, como regenerar un índice.

  Este argumento no repara errores relacionados con datos de FILESTREAM.

Importante

Puesto que se puede registrar y recuperar completamente DBCC CHECKDB junto con cualquiera de las opciones de REPAIR, en Microsoft siempre se recomienda que el usuario use DBCC CHECKDB con las opciones de REPAIR dentro de una transacción (ejecute BEGIN TRANSACTION antes de ejecutar el comando) para que el usuario pueda confirmar si quiere aceptar los resultados de la operación. Después, el usuario puede ejecutar COMMIT TRANSACTION para confirmar todo el trabajo realizado por la operación de reparación. Si el usuario no desea aceptar el resultado de la operación, puede ejecutar ROLLBACK TRANSACTION para deshacer los efectos de las operaciones de reparación.

Para reparar errores, se recomienda restaurar a partir de una copia de seguridad. Las operaciones de reparación no tienen en cuenta ninguna de las restricciones que puede haber en las tablas o entre ellas. Si la tabla especificada está implicada en una o más restricciones, se recomienda ejecutar DBCC CHECKCONSTRAINTS tras una operación de reparación. Si tiene que usar REPAIR, ejecute DBCC CHECKDB sin una opción de reparación para localizar el nivel de reparación que se va a usar. Si se va a usar el nivel REPAIR_ALLOW_DATA_LOSS, se recomienda realizar una copia de seguridad de la base de datos antes de ejecutar DBCC CHECKDB con esta opción.

ALL_ERRORMSGS

Muestra todos los errores notificados por objeto. De forma predeterminada, se muestran todos los mensajes de error. Especificar u omitir esta opción no tiene ningún efecto. Los mensajes de error se ordenan por identificador de objeto, salvo en el caso de los mensajes generados desde la base de datos tempdb.

EXTENDED_LOGICAL_CHECKS

Si el nivel de compatibilidad es 100, introducido en SQL Server 2008 (10.0.x), esta opción realiza comprobaciones de coherencia lógica en una vista indexada, en índices XML y en índices espaciales, en caso de que los haya.

Para más información, consulte Realización de comprobaciones de coherencia lógica en índices más adelante en este artículo.

NO_INFOMSGS

Suprime todos los mensajes de información.

TABLOCK

Hace que DBCC CHECKDB obtenga bloqueos en lugar de usar una instantánea de base de datos interna. Se incluye un bloqueo exclusivo (X) a corto plazo en la base de datos. TABLOCK hace que DBCC CHECKDB se ejecute más rápido en una base de datos con mucha carga, pero disminuirá la simultaneidad disponible en la base de datos mientras DBCC CHECKDB está en ejecución.

Importante

TABLOCK limita las comprobaciones que se llevan a cabo; DBCC CHECKCATALOG no se ejecuta en la base de datos y los datos de Service Broker no se validan.

ESTIMATEONLY

Muestra la cantidad de espacio tempdb para la base de datos que se estima necesario para ejecutar DBCC CHECKDB con todas las demás opciones especificadas. No se realiza la comprobación real de la base de datos.

PHYSICAL_ONLY

Limita la comprobación a la integridad de la estructura física de los encabezados de página y registro y la coherencia de la asignación de la base de datos. Esta comprobación se ha diseñado para proporcionar una pequeña comprobación de sobrecarga de la coherencia física de la base de datos; también detecta páginas rasgadas, errores de suma de comprobación y errores de hardware comunes que pueden comprometer los datos del usuario.

La ejecución completa de DBCC CHECKDB puede tardar mucho más tiempo en completarse que en versiones anteriores. Este comportamiento se produce porque:

• Las comprobaciones lógicas son más exhaustivas.
• Algunas de las estructuras subyacentes que hay que comprobar son más complejas.
• Se han agregado muchas comprobaciones nuevas para incluir las nuevas características.

Por lo tanto, el uso de la opción PHYSICAL_ONLY puede llevar mucho menos tiempo para DBCC CHECKDB en bases de datos grandes y es por esa razón por la que se recomienda para un uso frecuente en sistemas de producción. Aun así, se recomienda realizar una ejecución completa de DBCC CHECKDB periódicamente. La frecuencia de estas ejecuciones depende de factores específicos de cada empresa y de los entornos de producción.

Este argumento siempre implica NO_INFOMSGS y no se permite con ninguna de las opciones de reparación.

Advertencia

La especificación de PHYSICAL_ONLY provoca que DBCC CHECKDB omita todas las comprobaciones de los datos FILESTREAM.

DATA_PURITY

Hace que DBCC CHECKDB compruebe si la base de datos contiene valores de columna que no son válidos o están fuera del intervalo correcto. Por ejemplo, DBCC CHECKDB detecta las columnas cuyos valores de fecha y hora son superiores o inferiores al intervalo de valores válido para el tipo de datos datetime, o bien las columnas del tipo de datos decimal o numérico aproximado con valores de escala o precisión que no son válidos.

Las comprobaciones de integridad de valores de columna están habilitadas de manera predeterminada y no requieren la opción DATA_PURITY. De manera predeterminada, en las bases de datos actualizadas desde versiones anteriores de SQL Server, las comprobaciones de valores de columna no se habilitan hasta que no se ejecuta DBCC CHECKDB WITH DATA_PURITY sin errores en la base de datos. Después, DBCC CHECKDB comprueba la integridad de los valores de columna de manera predeterminada. Para obtener más información sobre cómo la actualización de bases de datos de versiones anteriores de SQL Server podría afectar a CHECKDB, vea la sección Comentarios más adelante en este artículo.

Advertencia

Si se especifica PHYSICAL_ONLY, no se realizan comprobaciones de integridad de columna.

Los errores de validación de los que informe esta opción no se pueden corregir con las opciones de reparación de DBCC. Para obtener información acerca de cómo corregir manualmente estos errores, consulte el artículo 923247 de Knowledge Base: Resolución del error DBCC 2570 en SQL Server 2005 y versiones posteriores.

MAXDOP

Se aplica a: SQL Server 2014 (12.x) Service Pack 2 y versiones posteriores

Invalida la opción de configuración de grado máximo de paralelismo de sp_configure para la instrucción. MAXDOPpuede superar el valor configurado con sp_configure. Si MAXDOP supera el valor configurado con Resource Governor, el motor de base de datos de SQL Server usa el valor MAXDOP de Resource Governor, descrito en ALTER WORKLOAD GROUP (Transact-SQL). Se pueden aplicar todas las reglas semánticas usadas con la opción de configuración Grado máximo de paralelismo cuando se usa la sugerencia de consulta MAXDOP. Para obtener más información, vea Establecer la opción de configuración del servidor Grado máximo de paralelismo.

Advertencia

Si MAXDOP se establece en cero, SQL Server elige el grado máximo de paralelismo que se va a usar.

Comentarios

DBCC CHECKDB no examina los índices deshabilitados. Para más información sobre los índices deshabilitados, vea Deshabilitar índices y restricciones.

Si un tipo definido por el usuario se marca como ordenado por bytes, solo debe existir una serialización del tipo definido por el usuario. La serialización incoherente de los tipos definidos por el usuario ordenados por bytes provoca el error 2537 cuando se ejecuta DBCC CHECKDB. Para más información, vea los requisitos de los tipos definidos por el usuario.

Dado que solo se puede modificar la base de datos Resource en modo de usuario único, el comando DBCC CHECKDB no se puede ejecutar directamente en ella. Aun así, al ejecutar DBCC CHECKDB en la base de datos maestra, se ejecuta un segundo comando CHECKDB internamente en la base de datos Resource. Esto significa que DBCC CHECKDB puede devolver resultados adicionales. El comando devuelve conjuntos de resultados adicionales cuando no se establecen opciones o cuando se establecen las opciones PHYSICAL_ONLY o ESTIMATEONLY.

A partir de SQL Server 2005 (9.x) Service Pack 2, ejecutar DBCC CHECKDB ya no borra la caché del plan de la instancia de SQL Server. En versiones anteriores a SQL Server 2005 (9.x) Service Pack 2, ejecutar DBCC CHECKDB borra la caché del plan. Al borrar la caché del plan, se provoca una recompilación de todos los planes de ejecución posteriores y puede ocasionar una disminución repentina y temporal del rendimiento de las consultas.

Realización de comprobaciones de coherencia lógica en índices

La comprobación de coherencia lógica en índices varía según el nivel de compatibilidad de la base de datos, tal como se indica a continuación:

• Si el nivel de compatibilidad es de al menos 100 (introducido en SQL Server 2008 [10.0.x]):
• A menos que se especifique NOINDEX, DBCC CHECKDB realiza comprobaciones de coherencia física y lógica en una sola tabla y en todos sus índices no agrupados. Sin embargo, en los índices XML, índices espaciales y vistas indizadas solo se realizan comprobaciones de coherencia física de forma predeterminada.
• Si se especifica WITH EXTENDED_LOGICAL_CHECKS, se realizan comprobaciones lógicas en una vista indexada, índices XML e índices espaciales, si los hay. De forma predeterminada, las comprobaciones de coherencia física se realizan antes que las comprobaciones de coherencia lógica. Si también se especifica NOINDEX, solamente se realizarán las comprobaciones lógicas.

Estas comprobaciones de coherencia lógica realizan una comprobación cruzada de la tabla de índices interna del objeto de índice con la tabla de usuario a la que hace referencia. Para buscar las filas periféricas, se crea una consulta interna que lleve a cabo una intersección completa de las tablas internas y del usuario. La ejecución de esta consulta puede afectar de manera significativa al rendimiento y no se puede realizar el seguimiento de su progreso. Por consiguiente, se recomienda especificar únicamente WITH EXTENDED_LOGICAL_CHECKS si cree que existen problemas del índice que no estén relacionados con daños físicos, o si las sumas de comprobación del nivel de página se han desactivado y sospecha que puedan existir daños de hardware de nivel de columna.

• Si el índice es un índice filtrado, DBCC CHECKDB realizará las comprobaciones de coherencia para comprobar que las entradas de índice satisfacen el predicado de filtro.
• Si el nivel de compatibilidad es 90 o menos, a menos que se especifique NOINDEX, DBCC CHECKDB realiza las comprobaciones de coherencia física y lógica en una tabla única o vista indexada y en todos sus índices XML e índices no clúster. Los índices espaciales no se admiten.
• A partir de SQL Server 2016 (13.x), no se ejecutarán de forma predeterminada comprobaciones adicionales en las columnas calculadas persistentes, las columnas UDT y los índices filtrados para evitar evaluaciones de expresiones costosas. Este cambio reduce considerablemente la duración de CHECKDB en bases de datos que contienen estos objetos. A pesar de ello, las comprobaciones de coherencia física de estos objetos siempre se completan. Solo cuando se especifica la opción EXTENDED_LOGICAL_CHECKS, se realizan las evaluaciones de expresiones, además de las comprobaciones lógicas que ya están presentes como parte de la opción EXTENDED_LOGICAL_CHECKS (vista indexada, índices XML e índices espaciales).

Para conocer el nivel de compatibilidad de una base de datos

• Visualización o cambio del nivel de compatibilidad de una base de datos

Instantánea de base de datos interna

DBCC CHECKDB usa una instantánea de la base de datos interna para la coherencia transaccional necesaria para realizar estas comprobaciones. Así se evitan problemas de bloqueo y simultaneidad cuando se ejecutan estos comandos. Para más información, vea Ver el tamaño del archivo disperso de una instantánea de base de datos (Transact-SQL) y la sección "Uso de comandos DBCC en instantáneas internas de la base de datos" de DBCC (Transact-SQL). Si no se puede crear una instantánea o se especifica TABLOCK, DBCC CHECKDB adquiere bloqueos para obtener la coherencia necesaria. En este caso, se requiere un bloqueo exclusivo de base de datos para realizar las comprobaciones de asignación y se requieren bloqueos compartidos de tabla para realizar las comprobaciones de tabla.

DBCC CHECKDB produce un error cuando se ejecuta contra la base de datos master si no se puede crear una instantánea de base de datos interna.

Al ejecutar DBCC CHECKDB en tempdb, no se realiza ninguna comprobación de asignación ni de catálogos, y se deben adquirir bloqueos de uso compartido de las tablas para realizar las comprobaciones de tabla. Esto es debido a que por motivos de rendimiento las instantáneas de base de datos no están disponibles en tempdb. Eso significa que no es posible obtener la coherencia transaccional necesaria.

Cómo crea DBCC CHECKDB una base de datos de instantáneas interna a partir SQL Server 2014

1. DBCC CHECKDB crea una base de datos de instantáneas interna.

2. La base de datos de instantáneas interna se crea mediante archivos físicos. Por ejemplo, para una base de datos con database_id = 10 que tiene tres archivos E:\Data\my_DB.mdf, E:\Data\my_DB.ndf y E:\Data\my_DB.ldf, la base de datos de instantáneas interna se creará con los archivos E:\Data\my_DB.mdf_MSSQL_DBCC11 y E:\Data\my_DB.ndf_MSSQL_DBCC11. El identificador database_id de la instantánea es database_id + 1. Tenga en cuenta también que los nuevos archivos se crean en la misma carpeta mediante la convención de nomenclatura <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>. No se crea ningún archivo disperso para el registro de transacciones.

3. Los nuevos archivos se marcan como archivos dispersos en el nivel del sistema de archivos. El tamaño en disco usado por los nuevos archivos aumentará en función de la cantidad de datos que se actualicen en la base de datos de origen durante el comando DBCC CHECKDB. El tamaño de los nuevos archivos será el mismo que el archivo .mdf o .ndf.

4. Los nuevos archivos se eliminan al final del procesamiento de DBCC CHECKDB. Estos archivos dispersos creados por DBCC CHECKDB tienen establecidos los atributos "Delete on Close (Eliminar al cerrar)".

Advertencia

Si el sistema operativo encuentra un apagado inesperado mientras el comando DBCC CHECKDB está en curso, estos archivos no se limpiarán. Ocuparán espacio y pueden provocar errores en futuras ejecuciones de DBCC CHECKDB. En ese caso, puede eliminar estos nuevos archivos después de confirmar que no hay ningún comando DBCC CHECKDB en ejecución actualmente.

Los nuevos archivos son visibles mediante utilidades de archivos normales, como Explorador de Windows.

Nota

En versiones anteriores a SQL Server 2014 (12.x), se usaron secuencias de archivos con nombre en su lugar para crear los archivos de instantáneas internos. Los flujos de archivo con nombre usan el formato <filename.extension>:MSSQL_DBCC<database_id_of_snapshot>. Las secuencias de archivos con nombre no son visibles mediante utilidades de archivos normales, como Explorador de Windows. Por tanto, en SQL Server 2012 (11.x) o una versión anterior, podría encontrar mensajes de error 7926 y 5030 al ejecutar el comando DBCC CHECKDB para unos archivos de base de datos ubicados en un volumen con formato ReFS. Esto se debe a que no se pueden crear secuencias de archivos en el sistema de archivos resistente (RefS).

Comprobación y reparación de datos FILESTREAM

Cuando FILESTREAM está habilitado para una base de datos y una tabla, puede almacenar opcionalmente los objetos binarios grandes (BLOB) varbinary(max) en el sistema de archivos. Al usar DBCC CHECKDB en una base de datos que almacena BLOB en el sistema de archivos, DBCC comprueba la coherencia de nivel de vínculo entre el sistema de archivos y la base de datos.

Por ejemplo, si una tabla contiene una columna varbinary(max) en la que se usa el atributo FILESTREAM, DBCC CHECKDB comprobará que existe una asignación uno a uno entre los directorios del sistema de archivos y los archivos y filas de tabla, las columnas y los valores de columna. DBCC CHECKDB puede reparar la corrupción si especifica la opción REPAIR_ALLOW_DATA_LOSS. Para reparar el daño producido en FILESTREAM, DBCC eliminará las filas de tabla que sean datos del sistema de archivos que faltan.

Procedimientos recomendados

Se recomienda utilizar la opción PHYSICAL_ONLY si se usa con frecuencia en sistemas de producción. El uso de PHYSICAL_ONLY puede disminuir considerablemente el tiempo de ejecución para DBCC CHECKDB en base de datos grandes. También se recomienda ejecutar DBCC CHECKDB sin opciones de forma periódica. La frecuencia con que se deben realizar estas ejecuciones varía en función de la empresa y su entorno de producción.

Comprobación de objetos en paralelo

De forma predeterminada, DBCC CHECKDB realiza comprobaciones paralelas de los objetos. El grado de paralelismo se determina automáticamente mediante el procesador de consultas. El grado máximo de paralelismo se configura igual que las consultas paralelas. Para restringir el número máximo de procesadores disponibles para las comprobaciones DBCC, use sp_configure. Para obtener más información, vea Establecer la opción de configuración del servidor Grado máximo de paralelismo. La comprobación del paralelismo se puede deshabilitar con el marcador de seguimiento 2528. Para obtener más información, vea Marcas de seguimiento (Transact-SQL).

Nota

Esta característica no está disponible en todas las ediciones de SQL Server. Para más información, consulte la comprobación de coherencia paralela en la sección Capacidad de administración de RDBMS de Ediciones y características admitidas de SQL Server 2022.

Descripción de los mensajes de error de DBCC

Cuando el comando DBCC CHECKDB finaliza, se escribe un mensaje en el registro de errores de SQL Server. Si el comando DBCC se ejecuta correctamente, el mensaje lo indica, así como el tiempo de ejecución del comando. Si el comando DBCC se detiene antes de finalizar la comprobación debido a un error, el mensaje indica que el comando se ha cancelado, un valor de estado y el tiempo de ejecución del comando. En la tabla siguiente se muestran y describen los valores de estado que pueden aparecer en el mensaje.

State	Descripción
0	Se ha generado el error número 8930. Esto indica que se interrumpió la ejecución del comando DBCC a causa de daños en los metadatos.
1	Se ha generado el error número 8967. Error DBCC interno.
2	Error durante una reparación de base de datos en modo de emergencia.
3	Esto indica que se interrumpió la ejecución del comando DBCC a causa de daños en los metadatos.
4	Se ha detectado una infracción de acceso o aserción.
5	Error desconocido que cancela el comando DBCC.

Nota

SQL Server registra la fecha y hora en que se ha ejecutado una comprobación de coherencia para una base de datos sin errores (o "limpia"). Esto se conoce como last known clean check. Cuando se inicia una base de datos por primera vez, esta fecha se escribe en el registro de eventos (EventID-17573) y en el registro de errores en el formato siguiente:

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Informe de errores

Un archivo de volcado (SQLDUMP<nnnn>.txt) se crea en el directorio LOG de SQL Server cada vez que DBCC CHECKDB detecta un error relacionado con datos dañados. Si las características de recopilación de datos de Uso de la característica e Informes de errores están habilitadas para la instancia de SQL Server, el archivo se reenvía automáticamente a Microsoft. Los datos recopilados se utilizan para mejorar la funcionalidad de SQL Server. El archivo de volcado contiene los resultados del comando DBCC CHECKDB y los resultados del diagnóstico adicional. El acceso está limitado a la cuenta de servicio de SQL Server y a los miembros del rol sysadmin. De forma predeterminada, el rol sysadmin contiene todos los miembros del grupo BUILTIN\Administrators de Windows y el grupo de administradores local. El comando DBCC no producirá error en caso de que se produzca un error en el proceso de recopilación de datos.

Resolución de errores

Si DBCC CHECKDB informa de errores, se recomienda restaurar la base de datos a partir de una copia de seguridad en lugar de ejecutar REPAIR con una de sus opciones. Si no hay ninguna copia de seguridad, al ejecutar REPAIR se corrigen los errores notificados. La opción de reparación que se debe utilizar se especifica al final de la lista de errores notificados. No obstante, la corrección de errores mediante la opción REPAIR_ALLOW_DATA_LOSS puede requerir eliminar algunas páginas y, por tanto, también algunos datos.

En algunas circunstancias, es posible que la base de datos contenga valores que no son válidos o que no están comprendidos en el intervalo correcto de acuerdo con el tipo de datos de la columna. DBCC CHECKDB puede detectar valores de columna que no son válidos para todos los tipos de datos de columna. Por tanto, al ejecutar DBCC CHECKDB con la opción DATA_PURITY en bases de datos que se han actualizado desde versiones anteriores de SQL Server, pueden desvelarse errores de valores de columna que ya existían. Dado que SQL Server no puede reparar estos errores de forma automática, será necesario actualizar el valor de la columna de forma manual. Si CHECKDB detecta un error de este tipo, CHECKDB devuelve una advertencia, el número de error 2570 e información para identificar la fila afectada y corregir el error manualmente.

La reparación se puede realizar en una transacción de usuario para permitirle revertir los cambios realizados. Si se revierten las reparaciones, la base de datos aún contendrá errores por lo que se debe restaurar a partir de una copia de seguridad. Una vez finalizadas las reparaciones, realice una copia de seguridad de la base de datos.

Resolución de errores en modo de emergencia de base de datos

Cuando se establece una base de datos en modo de emergencia mediante la instrucción ALTER DATABASE, DBCC CHECKDB puede realizar algunas reparaciones especiales en la base de datos si se especifica la opción REPAIR_ALLOW_DATA_LOSS. Estas reparaciones pueden permitir que bases de datos que normalmente no se pueden recuperar vuelvan a estar en línea con un estado físicamente coherente. Estas reparaciones solo deben usarse como último recurso y solo cuando no se puede restaurar la base de datos a partir de una copia de seguridad. Cuando se establece la base de datos en modo de emergencia, se marca como READ_ONLY, se deshabilita el registro y se limita el acceso a los miembros del rol fijo de servidor sysadmin.

Nota

No se puede ejecutar el comando DBCC CHECKDB en modo de emergencia dentro de una transacción de usuario y revertir la transacción tras la ejecución.

Cuando la base de datos está en modo de emergencia y se ejecuta DBCC CHECKDB con la cláusula REPAIR_ALLOW_DATA_LOSS, se realizan las siguientes acciones:

• DBCC CHECKDB usa páginas marcadas como inaccesibles debido a errores de suma de comprobación o de E/S como si los errores no se hubieran producido. De esta manera aumentan las posibilidades de recuperación de datos de la base de datos.
• DBCC CHECKDB intenta recuperar la base de datos mediante las técnicas habituales de recuperación basadas en el registro.
• Si la recuperación de la base de datos no puede realizarse debido a daños en el registro de transacciones, dicho registro de transacciones volverá a generarse. Volver a generar el registro de transacciones puede provocar la pérdida de coherencia transaccional.

Advertencia

La opción REPAIR_ALLOW_DATA_LOSS es una característica compatible con SQL Server. No obstante, puede que no siempre sea la mejor opción para llevar una base de datos a un estado físicamente coherente. Si se realiza correctamente, la opción REPAIR_ALLOW_DATA_LOSS puede provocar la pérdida de datos. De hecho, puede producir la pérdida de más datos que si un usuario tuviera que restaurar la base de datos desde la última copia de seguridad en buen estado. Microsoft siempre recomienda que el usuario haga una restauración de la última copia de seguridad correcta como método principal para corregir los errores notificados por DBCC CHECKDB. La opción REPAIR_ALLOW_DATA_LOSSno es una alternativa para restaurar a partir de una copia de seguridad buena. Es una opción de emergencia como último recurso que solo le recomendamos usar si no es posible restaurar a partir de una copia de seguridad.

Después de volver a generar el registro, no hay ninguna garantía ACID completa.

Después de volver a generar el registro, DBCC CHECKDB se ejecutará automáticamente, informará de los problemas de coherencia física y los corregirá.

Las restricciones reguladas por la lógica empresarial y por la coherencia de datos lógicos se deben validar manualmente.

El tamaño del registro de transacciones conservará su tamaño predeterminado y debe ajustarse manualmente a su tamaño reciente.

Si el comando DBCC CHECKDB se ejecuta correctamente, la base de datos está en un estado físicamente coherente y se establece su estado en ONLINE. No obstante, la base de datos puede contener una o más incoherencias transaccionales. Es recomendable ejecutar DBCC CHECKCONSTRAINTS para identificar defectos de la lógica de negocios y realizar inmediatamente una copia de seguridad de la base de datos. Si el comando DBCC CHECKDB produce un error, la base de datos no se puede reparar.

Ejecución de DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS en bases de datos replicadas

La ejecución del comando DBCC CHECKDB con la opción REPAIR_ALLOW_DATA_LOSS puede afectar a las bases de datos de usuario (bases de datos de publicaciones y suscripciones) y a la base de datos de distribución que usa la replicación. Las bases de datos de publicaciones y suscripciones incluyen tablas publicadas y tablas de metadatos de replicación. Debe tener en cuenta los siguientes problemas potenciales en estas bases de datos:

• Tablas publicadas. Puede que no se repliquen las acciones realizadas por el proceso CHECKDB para reparar datos de usuario dañados:
• La replicación de mezcla utiliza desencadenadores para realizar el seguimiento de los cambios en tablas publicadas. Si el proceso CHECKDB inserta, actualiza o elimina filas, no se activan los desencadenadores, por lo que el cambio no se replica.
• La replicación transaccional utiliza el registro de transacciones para realizar el seguimiento de los cambios en tablas publicadas. Posteriormente, el Agente de registro del LOG mueve estos cambios a la base de datos de distribución. Es posible que el Agente de registro del LOG no pueda replicar algunas reparaciones de DBCC, aunque se hayan registrado. Por ejemplo, si el proceso CHECKDB cancela la asignación de una página de datos, el Agente de registro del LOG no convierte esta desasignación en una instrucción DELETE; por tanto, el cambio no se replica.
• Tablas de metadatos de replicación. Las acciones que realiza el proceso CHECKDB para reparar tablas de metadatos de replicación dañadas requieren que se quite y se vuelva a configurar la replicación.

Si debe ejecutar el comando DBCC CHECKDB con la opción REPAIR_ALLOW_DATA_LOSS en una base de datos de usuario o en una base de datos de distribución:

1. Ponga el sistema en modo inactivo: Detenga la actividad en la base de datos y en todas las demás bases de datos de la topología de replicación e intente sincronizar todos los nodos. Para más información, vea Poner en modo inactivo una topología de replicación (programación de la replicación con Transact-SQL).
2. Ejecute DBCC CHECKDB.
3. Si el informe de DBCC CHECKDB incluye reparaciones de tablas de la base de datos de distribución o de tablas de metadatos de replicación en una base de datos de distribución, quite la replicación y vuelva a configurarla. Para obtener más información, vea Deshabilitar la publicación y distribución.
4. Si el informe de DBCC CHECKDB incluye reparaciones de tablas replicadas, lleve a cabo la validación de datos para determinar dónde se encuentran las diferencias entre los datos de las bases de datos de publicaciones y de suscripciones.

Conjuntos de resultados

DBCC CHECKDB devuelve el siguiente conjunto de resultados. Los valores pueden variar, excepto cuando se especifican las opciones ESTIMATEONLY, PHYSICAL_ONLY o NO_INFOMSGS:

 DBCC results for 'model'.
    
 Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
    
 Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
    
 Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
    
 Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
    
 Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
    
 Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
    
 Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.
    
 DBCC results for 'sys.sysrowsetcolumns'.
    
 There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.
    
 DBCC results for 'sys.sysrowsets'.
    
 There are 97 rows in 1 pages for object 'sys.sysrowsets'.
    
 DBCC results for 'sysallocunits'.
    
 There are 195 rows in 3 pages for object 'sysallocunits'.
    
 There are 0 rows in 0 pages for object "sys.sysasymkeys".
    
 DBCC results for 'sys.syssqlguides'.
    
 There are 0 rows in 0 pages for object "sys.syssqlguides".
    
 DBCC results for 'sys.queue_messages_1977058079'.
    
 There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".
    
 DBCC results for 'sys.queue_messages_2009058193'.
    
 There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".
    
 DBCC results for 'sys.queue_messages_2041058307'.
    
 There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".
    
 CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.
    
 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB devuelve el siguiente conjunto de resultados (mensaje) cuando se especifica NO_INFOMSGS:

 The command(s) completed successfully.

DBCC CHECKDB devuelve el siguiente conjunto de resultados cuando se especifica PHYSICAL_ONLY:

 DBCC results for 'model'.
    
 CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.
    
 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB devuelve el siguiente conjunto de resultados cuando se especifica ESTIMATEONLY.

 Estimated TEMPDB space needed for CHECKALLOC (KB)
    
 -------------------------------------------------
    
 13
    
 (1 row(s) affected)
    
 Estimated TEMPDB space needed for CHECKTABLES (KB)
    
 --------------------------------------------------
    
 57
    
 (1 row(s) affected)
    
 DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Permisos

Debe pertenecer al rol fijo de servidor sysadmin o al rol fijo de base de datos db_owner.

Ejemplos

A. Comprobación de la base de datos actual y otra base de datos

En el ejemplo siguiente se ejecuta DBCC CHECKDB para la base de datos actual y para la base de datos AdventureWorks2022.

-- Check the current database.
DBCC CHECKDB;
GO
-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO

B. Comprobación de la base de datos actual, suprimiendo los mensajes informativos

En el ejemplo siguiente se comprueba la base de datos actual y se suprimen todos los mensajes informativos.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Consulte también

• DBCC (Transact-SQL)
• Ver el tamaño del archivo disperso de una instantánea de base de datos (Transact-SQL)
• sp_helpdb (Transact-SQL)
• Tablas del sistema (Transact-SQL)