DBCC CHECKTABLE (Transact-SQL)

Se aplica a:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Comprueba la integridad de todas las páginas y estructuras que constituyen la tabla o la vista indizada.

Convenciones de sintaxis de Transact-SQL

Sintaxis

DBCC CHECKTABLE
(
    table_name | view_name
    [ , { NOINDEX | index_id }
     | , { 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 ]
        }
    ]

Argumentos

table_name | view_name

La tabla o la vista indizada para la que se ejecutan las comprobaciones de integridad. Los nombres de tablas y vistas 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. Esto reduce el tiempo total de ejecución. NOINDEX no afecta a las tablas del sistema porque las comprobaciones de integridad siempre se ejecutan en todos los índices de las tablas del sistema.

id_de_índice

El número de identificación (id.) del índice para el que se van a ejecutar las comprobaciones de integridad. Si se especifica id_de_índice, DBCC CHECKTABLE ejecuta las comprobaciones de integridad solo en ese índice, junto con el índice de montón o el índice agrupado.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Especifica que DBCC CHECKTABLE repare los errores que encuentre. Para utilizar una opción de reparación, la base de datos debe estar en modo de usuario único.

• REPAIR_ALLOW_DATA_LOSS

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

• REPAIR_FAST

  La sintaxis solo se mantiene por razones de 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. Pueden 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.

ALL_ERRORMSGS

Muestra un número ilimitado de errores. De forma predeterminada, se muestran todos los mensajes de error. Especificar u omitir esta opción no tiene ningún efecto.

EXTENDED_LOGICAL_CHECKS

Si el nivel de compatibilidad es 100, introducido en SQL Server 2008 (10.0.x) o superior, 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 Realizar comprobaciones de coherencia lógica en índices en la sección Observaciones, más adelante en este artículo.

NO_INFOMSGS

Suprime todos los mensajes de información.

TABLOCK

Hace que DBCC CHECKTABLE reciba un bloqueo de tabla compartido en vez de usar una instantánea de base de datos interna. TABLOCK hará que DBCC CHECKTABLE se ejecute más rápido en una tabla con mucha carga, pero disminuirá la simultaneidad disponible sobre la tabla mientras DBCC CHECKTABLE está ejecutándose.

ESTIMATEONLY

Muestra la cantidad de espacio calculado de tempdb necesario para ejecutar DBCC CHECKTABLE con todas las otras opciones especificadas.

PHYSICAL_ONLY

Limita la comprobación de la integridad a la estructura física de la página, los encabezados de registro y la estructura física de árboles b. Se ha diseñado para proporcionar una pequeña comprobación de sobrecarga de la coherencia física de la tabla; esta comprobación también puede detectar páginas rasgadas y errores de hardware comunes que pueden comprometer los datos. Una ejecución completa de DBCC CHECKTABLE puede tardar mucho más tiempo que en versiones anteriores. Este comportamiento se debe a las razones siguientes:

• 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 tanto, el uso de la opción PHYSICAL_ONLY puede llevar mucho menos tiempo para DBCC CHECKTABLE en tablas grandes y, por ello, se recomienda para su uso frecuente en sistemas de producción. Aun así, se recomienda realizar una ejecución completa de DBCC CHECKTABLE periódicamente. La frecuencia de estas ejecuciones depende de factores específicos de cada empresa y de los entornos de producción. PHYSICAL_ONLY siempre implica NO_INFOMSGS y no se permite con ninguna de las opciones de reparación.

DATA_PURITY

Hace que DBCC CHECKTABLE compruebe si los valores de la tabla para la columna no son válidos o están fuera del intervalo correcto. Por ejemplo, DBCC CHECKTABLE 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. En las bases de datos actualizadas desde versiones anteriores de SQL Server, puede usar DBCC CHECKTABLE WITH DATA_PURITY para buscar y corregir errores en una tabla concreta; pero la comprobación de los valores de columnas de la tabla no se habilita de forma predeterminada hasta que se ejecute DBCC CHECKDB WITH DATA_PURITY sin errores en la base de datos. Después, DBCC CHECKDB y DBCC CHECKTABLE comprueban la integridad de los valores de columna de manera predeterminada.

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.

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

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. MAXDOP puede superar el valor configurado con sp_configure. Si MAXDOP supera el valor configurado con Resource Governor, el motor de base de datos usa el valor MAXDOP de Resource Governor, descrito en ALTER WORKLOAD GROUP (Transact-SQL). Se pueden aplicar todas las reglas semánticas utilizadas con la opción de configuración max degree of parallelism cuando se utiliza 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.

Comentarios

En la tabla especificada, DBCC CHECKTABLE comprueba lo siguiente:

• Las páginas de índice, consecutivas, de objetos grandes (LOB) y de datos de desbordamiento de fila están vinculadas correctamente.
• Los índices se encuentran en el orden correcto.
• Los punteros son coherentes.
• Los datos de cada página son razonables, incluidas las columnas calculadas.
• Los desplazamientos de página son razonables.
• Cada fila de la tabla base tiene una fila correspondiente en cada índice no agrupado y viceversa.
• Todas las filas de un índice o tabla con particiones están en la partición correcta.
• Coherencia de nivel de vínculo entre la tabla y el sistema de archivos cuando se almacenan datos varbinary(max) en el sistema de archivos mediante FILESTREAM.

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 100 (SQL Server 2008 [10.0.x]) o superior:

  • A menos que se especifique NOINDEX, DBCC CHECKTABLE 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 mucho 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 CHECKTABLE realizará las comprobaciones de coherencia para comprobar que las entradas de índice satisfacen el predicado de filtro.

• 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 CHECKTABLE en bases de datos que contienen estos objetos. Aun así, 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 ya presentes (vista indexada, índices XML e índices espaciales) como parte de la opción EXTENDED_LOGICAL_CHECKS.

• Si el nivel de compatibilidad es 90 (SQL Server 2005 [9.x]) o menos, a menos que se especifique NOINDEX, DBCC CHECKTABLE 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.

Para conocer el nivel de compatibilidad de una base de datos

• Ver o cambiar el nivel de compatibilidad de una base de datos

Instantánea de base de datos interna

DBCC CHECKTABLE usa una instantánea de base de datos interna para proporcionar la coherencia transaccional que debe tener para realizar estas comprobaciones. Para más información, consulte 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 CHECKTABLE adquiere un bloqueo de tabla compartido para obtener la coherencia necesaria.

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 CHECKTABLE en una tabla que almacena objetos 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 CHECKTABLE 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 CHECKTABLE puede reparar la corrupción si especifica la opción REPAIR_ALLOW_DATA_LOSS. Para reparar el daño de FILESTREAM, DBCC quitará todas las filas de tabla a las que les falten datos del sistema de archivos, así como todos los directorios y archivos no asignados a una fila de tabla, columna o valor de columna.

Comprobación de objetos en paralelo

De forma predeterminada, DBCC CHECKTABLE realiza comprobaciones paralelas de los objetos. El grado de paralelismo se determina automáticamente mediante el procesador de consultas. El grado de paralelismo máximo se configura de la misma forma que el de 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).

Descripción de los mensajes de error de DBCC

Cuando el comando DBCC CHECKTABLE 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.

Informe de errores

Un archivo de minivolcado de memoria (SQLDUMP<nnnn>.txt) se crea en el directorio LOG de SQL Server cada vez que DBCC CHECKTABLE 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 CHECKTABLE y los resultados del diagnóstico adicional. El archivo tiene listas de control de acceso discrecional (DACL) restringidas. 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\Administradores 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 CHECKTABLE informa de errores, se recomienda restaurar la base de datos de la copia de seguridad de base de datos en vez de ejecutar REPAIR con una de las opciones de REPAIR. Si no existe una copia de seguridad, la ejecución de REPAIR puede corregir los errores indicados. La opción REPAIR que se debe utilizar se especifica al final de la lista de errores indicados. No obstante, la corrección de errores mediante la opción REPAIR_ALLOW_DATA_LOSS puede eliminar algunas páginas, y por tanto, también algunos datos.

La reparación se puede realizar en una transacción de usuario para permitirle revertir los cambios que se han realizado. 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 todas las reparaciones, realice una copia de seguridad de la base de datos.

Conjuntos de resultados

DBCC CHECKTABLE devuelve el siguiente conjunto de resultados. Si se especifica solo el nombre de tabla o alguna de las opciones se devuelve el mismo conjunto de resultados.

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Si se especifica la opción ESTIMATEONLY, DBCC CHECKTABLE devuelve el siguiente conjunto de resultados:

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

Permisos

El usuario debe ser propietario de la tabla, o bien un miembro del rol fijo de servidor sysadmin o de los roles fijos de base de datos db_owner o db_ddladmin.

Ejemplos

A. Comprobación de una tabla específica

En el ejemplo siguiente se comprueba la integridad de la página de datos de la tabla HumanResources.Employee de la base de datos AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. Ejecución de una comprobación de carga baja de la tabla

En el ejemplo siguiente se realiza una comprobación de carga baja de la tabla Employee en la base de datos AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO

C. Comprobación de un índice específico

En el siguiente ejemplo se comprueba un índice específico, obtenido mediante un acceso a sys.indexes.

DECLARE @indid int;
SET @indid = (SELECT index_id
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ('Production.Product',@indid);

Consulte también

• DBCC (Transact-SQL)
• DBCC CHECKDB (Transact-SQL)