DBCC CHECKTABLE (Transact-SQL)

Actualizado: 17 de noviembre de 2008

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 ]
          [ , NO_INFOMSGS ]
          [ , TABLOCK ] 
          [ , ESTIMATEONLY ] 
          [ , { PHYSICAL_ONLY | DATA_PURITY } ] 
        }
    ]

Argumentos

• table_name | view_name
  Es la tabla o la vista indizada para la que se ejecutan las comprobaciones de integridad. Los nombres de tablas y vistas se deben ajustar a las reglas de los identificadores.

• NOINDEX
  Especifica que no deben realizarse comprobaciones intensivas de índices sin agrupar en tablas de usuario. Esto reduce la duración global de la 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.

• index_id
  Es el número de identificación (identificador) del índice para el que se van a ejecutar las comprobaciones de integridad. Si se especifica index_id, DBCC CHECKTABLE ejecuta las comprobaciones de integridad sólo en ese índice, junto con el índice agrupado o el montón.

• 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 la pérdida de datos.
  • REPAIR_FAST
    La sintaxis sólo se mantiene por razones de compatibilidad con versiones anteriores. No se realizan acciones de reparación.
  • REPAIR_REBUILD
    Lleva a cabo acciones de reparación menores rápidas, como la reparación de claves adicionales en índices sin agrupar, y reparaciones lentas como la regeneración de índices. Estas reparaciones se pueden realizar sin el riesgo de perder datos.

  [!NOTA] Utilice las opciones REPAIR sólo como último recurso. 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 debe utilizar REPAIR, ejecute DBCC CHECKDB sin una opción de reparación para localizar el nivel de reparación que se va a utilizar. Si va a utilizar 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 un número ilimitado de errores. En SQL Server 2005 Service Pack 3 (SP3), se muestran todos los mensajes de error de forma predeterminada. Especificar u omitir esta opción no tiene ningún efecto. En las versiones anteriores de SQL Server, si no se especifica ALL_ERRORMSGS, sólo se muestran los primeros 200 mensajes de error de cada objeto.

• NO_INFOMSGS
  Suprime todos los mensajes de información.

• TABLOCK
  Hace que DBCC CHECKTABLE reciba un bloqueo de tabla compartido en vez de utilizar 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á en ejecución.

• ESTIMATEONLY
  Muestra la cantidad de espacio calculado de la base de datos 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 los á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. En SQL Server 2005, la 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 características nuevas de SQL Server 2005.

  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 cuando se usa con frecuencia en sistemas de producción. Aun así, se recomienda realizar periódicamente una ejecución completa DBCC CHECKTABLE. 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 la tabla contiene valores de columna que 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.

  Para las bases de datos creadas en SQL Server 2005, 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; sin embargo, la comprobación de los valores de columnas de la tabla no se habilitan 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 columnas de forma predeterminada.

  Los errores de validación que notifique 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, vea el artículo 923247 de Knowledge Base sobre la solución del error DBCC 2570 en SQL Server 2005.

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

Conjuntos de resultados

DBCC CHECKTABLE devuelve el siguiente conjunto de resultados. Si se especifica sólo el nombre de tabla o alguna de las opciones se devuelve el mismo resultado.

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.

Notas

DBCC CHECKTABLE realiza comprobaciones de coherencia en una sola tabla o vista indizada, y en todos sus índices sin agrupar y XML, a menos que se especifique la opción NOINDEX. Para llevar a cabo una operación DBCC CHECKTABLE en todas las tablas de la base de datos, utilice DBCC CHECKDB.

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 sin agrupar y viceversa.
• Todas las filas de un índice o tabla con particiones están en la partición correcta.

Instantánea de base de datos interna

DBCC CHECKTABLE utiliza una instantánea de base de datos interna para proporcionar la coherencia transaccional que debe tener para realizar estas comprobaciones. Para obtener más información, vea Descripción del tamaño de los archivos dispersos en instantáneas de bases de datos y el tema sobre el uso de instantáneas de base de datos interna de DBCC en DBCC (Transact-SQL).

Si no se puede crear una instantánea, o se ha especificado TABLOCK, DBCC CHECKTABLE adquiere un bloqueo de tabla compartido para lograr la coherencia requerida.

[!NOTA] Si DBCC CHECKTABLE se ejecuta contra tempdb, debe adquirir un bloqueo de tabla compartido. Esto se debe a que, por motivos de rendimiento, las instantáneas de base de datos no están disponibles en tempdb. Esto significa que no se puede lograr la coherencia transaccional requerida.

Comprobar 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 que están disponibles para la comprobación DBCC, use sp_configure. Para obtener más información, vea max degree of parallelism (opción).

La comprobación en paralelo puede deshabilitarse utilizando el indicador de traza 2528. Para obtener más información, vea Marcas de traza (Transact-SQL).

[!NOTA] Durante una operación DBCC CHECKTABLE, los bytes almacenados en una columna de tipo definido por el usuario ordenada por bytes deben ser iguales a la serialización calculada del valor del tipo definido por el usuario. Si no es así, la rutina DBCC CHECKTABLE indicará un error de coherencia.

Descripción de los mensajes de error de DBCC

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

Informes de errores

En SQL Server 2005 con el Service Pack 1 (SP1), se crea un archivo de volcado pequeño (SQLDUMPnnnn.txt) en el directorio LOG de SQL Server siempre que DBCC CHECKTABLE detecta un error relacionado con datos dañados. Si la recopilación de datos de uso de características y la creación 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. Para obtener más información, vea Configuración de informes de errores y uso.

El archivo de volcado contiene los resultados del comando DBCC CHECKTABLE y salida de 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 de la función sysadmin. De forma predeterminada, la función 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.

Resolver errores

Si DBCC CHECKTABLE notifica errores, se recomienda restaurar la base de datos a partir 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 deshacer los cambios que se han realizado. Si se deshacen 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.

Permisos

El usuario debe poseer la tabla o ser miembro de las funciones fijas de servidor sysadmin o db_owner, o de la función fija de base de datos db_ddladmin.

Ejemplos

A. Comprobar una tabla específica

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

USE AdventureWorks;
GO
DBCC CHECKTABLE ("HumanResources.Employee");
GO

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

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

USE AdventureWorks;
GO
DBCC CHECKTABLE ("HumanResources.Employee") WITH PHYSICAL_ONLY;
GO

C. Comprobar un índice específico

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

USE AdventureWorks;
GO
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);

Vea también

Referencia

DBCC (Transact-SQL)

Otros recursos

Arquitectura de tablas e índices
Solucionar problemas de errores DBCC en vistas indizadas

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios