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.
- REPAIR_ALLOW_DATA_LOSS
- 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.
Estado | Descripción |
---|---|
0 |
Se ha generado el error número 8930. Indica un daño en los metadatos que provoca la cancelación del comando DBCC. |
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 |
Indica un daño en los metadatos que provoca la cancelación del comando DBCC. |
4 |
Se ha detectado una infracción de acceso o aserción. |
5 |
Error desconocido que cancela el comando DBCC. |
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
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
Versión | Historial |
---|---|
17 de noviembre de 2008 |
|
12 de diciembre de 2006 |
|
14 de abril de 2006 |
|
5 de diciembre de 2005 |
|