DBCC CHECKDB (Transact-SQL)

• 14/12/2017
• 22 minutos para leer
• • p
  • M
  • m
  • M
  • P
  • +3

Se aplica a: SQL Server (todas las versiones compatibles) Azure SQL Database

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

• Ejecuta DBCC CHECKALLOC en la base de datos.
• Ejecuta DBCC CHECKTABLE en cada tabla y vista de la base de datos.
• Ejecuta DBCC CHECKCATALOG en la base de datos.
• Valida el contenido de cada vista indexada de la base de datos.
• Valida la coherencia a nivel de enlace entre los metadatos de la tabla y los directorios y archivos del sistema de archivos cuando se almacenan datos varbinary(max) en el sistema de archivos utilizando FILESTREAM.
• Valida los datos del Service Broker en la base de datos.

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

Convenciones de sintaxis de Transact-SQL

Sintaxis

DBCC CHECKDB ) ] } ] ] 

Argumentos

nombre_de_la_base_de_datos | 0
Es el nombre o el ID de la base de datos para la que se ejecutan las comprobaciones de integridad. Si no se especifica, o si se especifica 0, se utiliza la base de datos actual. Los nombres de las bases de datos deben cumplir con las reglas de los identificadores.

NOINDEX
Especifica que no se deben realizar comprobaciones intensivas de los índices no agrupados de las tablas de usuario. Esto disminuye el tiempo de ejecución global. NOINDEX no afecta a las tablas del sistema porque las comprobaciones de integridad se realizan siempre en los índices de las tablas del sistema.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Especifica que DBCC CHECKDB repare los errores encontrados. Utilice las opciones REPAIR sólo como último recurso. La base de datos especificada debe estar en modo monopuesto para utilizar una de las siguientes opciones de reparación.

REPAIR_ALLOW_DATA_LOSS
Intenta reparar todos los errores reportados. Estas reparaciones pueden causar alguna pérdida de datos.

REPAIR_FAST
Mantiene la sintaxis sólo por compatibilidad con versiones anteriores. No se realizan acciones de reparación.

REPAIR_REBUILD
Realiza reparaciones que no tienen posibilidad de pérdida de datos. Esto puede incluir reparaciones rápidas, como la reparación de filas perdidas en índices no agrupados, y reparaciones que requieren más tiempo, como la reconstrucción de un índice.
Este argumento no repara los errores que implican datos FILESTREAM.

ALL_ERRORMSGS
Muestra todos los errores notificados por objeto. Todos los mensajes de error se muestran por defecto. Especificar u omitir esta opción no tiene ningún efecto. Los mensajes de error se ordenan por ID de objeto, excepto los mensajes generados desde la base de datos tempdb.

EXTENDED_LOGICAL_CHECKS
Si el nivel de compatibilidad es 100 («SQL Server 2008») o superior, realiza comprobaciones de consistencia lógica en una vista indexada, índices XML e índices espaciales, cuando están presentes.
Para obtener más información, consulte Realización de comprobaciones de consistencia lógica en índices, en la sección Observaciones más adelante en este tema.

NO_INFOMSGS
Suprime todos los mensajes informativos.

TABLOCK
Hace que DBCC CHECKDB obtenga bloqueos en lugar de utilizar una instantánea interna de la base de datos. Esto incluye un bloqueo exclusivo a corto plazo (X) en la base de datos. TABLOCK hará que DBCC CHECKDB se ejecute más rápidamente en una base de datos con mucha carga, pero disminuye la concurrencia disponible en la base de datos mientras DBCC CHECKDB se está ejecutando.

ESTIMATEONLY
Muestra la cantidad estimada de espacio tempdb que se necesita 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 las cabeceras de páginas y registros y a la consistencia de la asignación de la base de datos. Esta comprobación está diseñada para proporcionar una pequeña sobrecarga de comprobación de la consistencia física de la base de datos, pero también puede detectar páginas rotas, fallos de suma de comprobación y fallos de hardware comunes que pueden comprometer los datos de un usuario.
Una ejecución completa de DBCC CHECKDB puede tardar considerablemente más en completarse que las versiones anteriores. Este comportamiento se produce porque:

• Las comprobaciones lógicas son más exhaustivas.
• Algunas de las estructuras subyacentes que deben comprobarse son más complejas.
• Se han introducido muchas comprobaciones nuevas para incluir las nuevas características.
  Por lo tanto, el uso de la opción PHYSICAL_ONLY puede provocar un tiempo de ejecución mucho más corto para DBCC CHECKDB en bases de datos grandes y se recomienda para el uso frecuente en sistemas de producción. Seguimos recomendando que se realice 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.

DATA_PURITY
Hace que DBCC CHECKDB compruebe la base de datos en busca de valores de columna que no sean válidos o estén fuera de rango. Por ejemplo, DBCC CHECKDB detecta columnas con valores de fecha y hora que son mayores o menores que el rango aceptable para el tipo de datos datetime; o columnas de tipo 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 activadas por defecto y no requieren la opción DATA_PURITY. En el caso de las bases de datos actualizadas desde versiones anteriores de SQL Server, las comprobaciones de valores de columna no se habilitan de forma predeterminada hasta que DBCC CHECKDB WITH DATA_PURITY se haya ejecutado sin errores en la base de datos. Después de esto, DBCC CHECKDB comprueba la integridad de los valores de columna por defecto. Para obtener más información sobre cómo CHECKDB puede verse afectado por la actualización de la base de datos desde versiones anteriores de SQL Server, consulte la sección Observaciones más adelante en este tema.

Los errores de validación notificados por esta opción no pueden solucionarse mediante las opciones de reparación de DBCC. Para obtener información sobre la corrección manual de estos errores, consulte el artículo de la Base de conocimientos 923247: Solución de problemas del error 2570 de DBCC en SQL Server 2005 y versiones posteriores.

MAXDOP
Se aplica a: SQL Server ( SQL Server 2014 (12.x) SP2 y posteriores).

Anula la opción de configuración del grado máximo de paralelismo de sp_configure para la sentencia. El MAXDOP puede exceder el valor configurado con sp_configure. Si MAXDOP supera el valor configurado con Resource Governor, el motor de base de datos de SQL Server utiliza el valor MAXDOP de Resource Governor, descrito en ALTER WORKLOAD GROUP. Todas las reglas semánticas utilizadas con la opción de configuración de grado máximo de paralelismo son aplicables cuando se utiliza la sugerencia de consulta MAXDOP. Para obtener más información, consulte Configurar la opción de configuración del servidor de grado máximo de paralelismo.

Observaciones

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

Si un tipo definido por el usuario está marcado como ordenado por bytes, sólo debe haber una serialización del tipo definido por el usuario. No tener una serialización consistente de tipos definidos por el usuario ordenados por bytes causa el error 2537 cuando se ejecuta DBCC CHECKDB. Para obtener más información, consulte Requisitos de los tipos definidos por el usuario.

Debido a que la base de datos de recursos sólo se puede modificar en modo monopuesto, el comando DBCC CHECKDB no se puede ejecutar en ella directamente. Sin embargo, cuando se ejecuta DBCC CHECKDB contra la base de datos maestra, también se ejecuta internamente un segundo CHECKDB 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 establece ninguna opción o cuando se establece la opción PHYSICAL_ONLY o ESTIMATEONLY.

A partir de SQL Server 2005 (9.x) SP2, al ejecutar DBCC CHECKDB ya no se borra la caché del plan para la instancia de SQL Server. Antes de SQL Server 2005 (9.x) SP2, al ejecutar DBCC CHECKDB se borraba la caché del plan. El borrado de la caché de planes provoca la recompilación de todos los planes de ejecución posteriores y puede causar una disminución repentina y temporal del rendimiento de las consultas.

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

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

• Si el nivel de compatibilidad es 100 (SQL Server 2008) o superior:
• A menos que se especifique NOINDEX, DBCC CHECKDB realiza comprobaciones de consistencia física y lógica en una única tabla y en todos sus índices no agrupados. Sin embargo, en los índices XML, índices espaciales y vistas indexadas sólo se realizan comprobaciones de consistencia física por defecto.
• Si se especifica WITH EXTENDED_LOGICAL_CHECKS, se realizan comprobaciones lógicas en una vista indexada, índices XML e índices espaciales, cuando están presentes. Por defecto, las comprobaciones de consistencia física se realizan antes que las lógicas. Si también se especifica NOINDEX, sólo se realizan las comprobaciones lógicas.

Estas comprobaciones de consistencia lógica cruzan la tabla de índices interna del objeto índice con la tabla de usuario a la que hace referencia. Para encontrar las filas que quedan fuera, se construye una consulta interna para realizar una intersección completa de las tablas internas y de usuario. La ejecución de esta consulta puede tener un efecto muy alto en el rendimiento, y su progreso no puede ser rastreado. Por lo tanto, se recomienda especificar WITH EXTENDED_LOGICAL_CHECKS sólo si se sospecha de problemas de índice que no están relacionados con la corrupción física, o si se han desactivado las sumas de comprobación a nivel de página y se sospecha de corrupción de hardware a nivel de columna.

• Si el índice es un índice filtrado, DBCC CHECKDB realiza comprobaciones de consistencia para verificar que las entradas del índice satisfacen el predicado del filtro.
• Si el nivel de compatibilidad es 90 o menos, a menos que se especifique NOINDEX, DBCC CHECKDB realiza comprobaciones de consistencia tanto físicas como lógicas en una única tabla o vista indexada y en todos sus índices no agrupados y XML. Los índices espaciales no son compatibles.
• A partir de SQL Server 2016, las comprobaciones adicionales de las columnas computadas persistentes, las columnas UDT y los índices filtrados no se ejecutarán de forma predeterminada para evitar las costosas evaluaciones de expresiones. Este cambio reduce en gran medida la duración de CHECKDB contra las bases de datos que contienen estos objetos. Sin embargo, las comprobaciones de consistencia física de estos objetos siempre se completan. Sólo cuando se especifique la opción EXTENDED_LOGICAL_CHECKS se realizarán 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.

Para conocer el nivel de compatibilidad de una base de datos

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

Snapshot interno de la base de datos

DBCC CHECKDB utiliza un snapshot interno de la base de datos para la consistencia transaccional necesaria para realizar estas comprobaciones. Esto evita problemas de bloqueo y concurrencia cuando se ejecutan estos comandos. Para obtener 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 la instantánea de base de datos interna de DBCC en DBCC (Transact-SQL). Si no se puede crear una instantánea, o se especifica TABLOCK, DBCC CHECKDB adquiere bloqueos para obtener la consistencia requerida. En este caso, se requiere un bloqueo de base de datos exclusivo para realizar las comprobaciones de asignación, y se requieren bloqueos de tabla compartidos para realizar las comprobaciones de tabla.DBCC CHECKDB falla cuando se ejecuta contra master si no se puede crear una instantánea de base de datos interna.La ejecución de DBCC CHECKDB contra tempdb no realiza ninguna comprobación de asignación o de catálogo y debe adquirir bloqueos de tabla compartidos para realizar las comprobaciones de tabla. Esto se debe a que, por razones de rendimiento, las instantáneas de la base de datos no están disponibles en tempdb. Esto significa que no se puede obtener la coherencia transaccional necesaria.En Microsoft SQL Server 2012 o en una versión anterior de SQL Server, es posible que aparezcan mensajes de error al ejecutar el comando DBCC CHECKDB para una base de datos que tiene sus archivos ubicados en un volumen con formato ReFS. Para obtener más información, consulte el artículo de la Base de conocimientos 2974455: Comportamiento de DBCC CHECKDB cuando la base de datos de SQL Server se encuentra en un volumen con formato ReFS.

Comprobación y reparación de datos FILESTREAM

Cuando FILESTREAM está habilitado para una base de datos y una tabla, puede almacenar opcionalmente objetos grandes binarios (BLOB) varbinary(max) en el sistema de archivos. Cuando se utiliza DBCC CHECKDB en una base de datos que almacena BLOBs en el sistema de archivos, DBCC comprueba la consistencia a nivel de enlace entre el sistema de archivos y la base de datos.Por ejemplo, si una tabla contiene una columna varbinary(max) que utiliza el atributo FILESTREAM, DBCC CHECKDB comprobará que existe una correspondencia uno a uno entre los directorios y archivos del sistema de archivos y las filas, columnas y valores de la tabla. DBCC CHECKDB puede reparar la corrupción si se especifica la opción REPAIR_ALLOW_DATA_LOSS. Para reparar la corrupción de FILESTREAM, DBCC borrará cualquier fila de la tabla a la que le falten datos del sistema de archivos.

Mejores prácticas

Recomendamos que utilice la opción PHYSICAL_ONLY para el uso frecuente en sistemas de producción. El uso de PHYSICAL_ONLY puede acortar en gran medida el tiempo de ejecución de DBCC CHECKDB en bases de datos grandes. También se recomienda ejecutar periódicamente DBCC CHECKDB sin opciones. La frecuencia con la que debe realizar estas ejecuciones depende de cada empresa y de sus entornos de producción.

Comprobación de objetos en paralelo

Por defecto, DBCC CHECKDB realiza una comprobación paralela de los objetos. El grado de paralelismo es determinado automáticamente por 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 la comprobación DBCC, utilice sp_configure. Para más información, consulte Configurar el grado máximo de paralelismo Opción de configuración del servidor. La comprobación paralela se puede desactivar utilizando el indicador de seguimiento 2528. Para obtener más información, consulte Banderas de rastreo (Transact-SQL).

Comprensión de los mensajes de error de DBCC

Después de que el comando DBCC CHECKDB finalice, se escribe un mensaje en el registro de errores de SQL Server. Si el comando DBCC se ejecuta correctamente, el mensaje indica el éxito y la cantidad de tiempo que se ejecutó el comando. Si el comando DBCC se detiene antes de completar la comprobación debido a un error, el mensaje indica que el comando ha finalizado, un valor de estado y el tiempo de ejecución del comando. La siguiente tabla enumera y describe los valores de estado que pueden incluirse en el mensaje.

Estado	Descripción
0	Se ha producido el error número 8930. Esto indica una corrupción en los metadatos que terminó el comando DBCC.
1	Se levantó el error número 8967. Se produjo un error interno de DBCC.
2	Se produjo un fallo durante la reparación de la base de datos en modo de emergencia.
3	Indica una corrupción en los metadatos que puso fin al comando DBCC.
4	Se detectó una afirmación o una violación de acceso.
5	Se produjo un error desconocido que terminó el comando DBCC.

Informe de errores

Se crea un archivo de volcado (SQLDUMP*nnnn*.txt) en el directorio LOG de SQL Server siempre que DBCC CHECKDB detecta un error de corrupción. Cuando las funciones de recopilación de datos de uso de funciones y de informe de errores están activadas para la instancia de SQL Server, el archivo se envía automáticamente a Microsoft. El archivo de volcado contiene los resultados del comando DBCC CHECKDB y otros resultados de diagnóstico. El acceso está limitado a la cuenta de servicio de SQL Server y a los miembros del rol de sysadmin. Por defecto, el rol sysadmin contiene todos los miembros del grupo Windows BUILTIN\Administrators y el grupo del administrador local. El comando DBCC no falla si el proceso de recopilación de datos falla.

Resolución de errores

Si DBCC CHECKDB informa de algún error, se recomienda restaurar la base de datos desde la copia de seguridad de la base de datos en lugar de ejecutar REPAIR con una de las opciones de REPAIR. Si no existe una copia de seguridad, la ejecución de la reparación corrige los errores reportados. La opción de reparación a utilizar se especifica al final de la lista de errores reportados. Sin embargo, la corrección de los errores mediante el uso de la opción REPAIR_ALLOW_DATA_LOSS podría requerir la eliminación de algunas páginas y, por lo tanto, de algunos datos.

En algunas circunstancias, es posible que se introduzcan valores en la base de datos que no sean válidos o estén fuera de rango según 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 lo tanto, la ejecución de DBCC CHECKDB con la opción DATA_PURITY en bases de datos que se han actualizado desde versiones anteriores de SQL Server podría revelar errores preexistentes en los valores de las columnas. Como SQL Server no puede reparar automáticamente estos errores, el valor de la columna debe actualizarse manualmente. 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 manualmente el error.

La reparación puede realizarse bajo una transacción de usuario para que éste pueda deshacer los cambios realizados. Si las reparaciones se deshacen, la base de datos seguirá conteniendo errores y deberá restaurarse 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 el modo de emergencia de la base de datos

Cuando una base de datos se ha puesto en modo de emergencia mediante la sentencia 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 normalmente irrecuperables vuelvan a estar en línea en un estado físicamente consistente. Estas reparaciones deben utilizarse como último recurso y sólo cuando no se pueda restaurar la base de datos a partir de una copia de seguridad. Cuando la base de datos se establece en modo de emergencia, la base de datos se marca como READ_ONLY, el registro se desactiva y el acceso se limita a los miembros del rol de servidor fijo sysadmin.

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

• DBCC CHECKDB utiliza las páginas que se han marcado como inaccesibles debido a errores de E/S o de suma de comprobación, como si los errores no se hubieran producido. Hacer esto aumenta las posibilidades de recuperación de datos de la base de datos.
• DBCC CHECKDB intenta recuperar la base de datos utilizando técnicas de recuperación regulares basadas en el registro.
• Si, debido a la corrupción del registro de transacciones, la recuperación de la base de datos no tiene éxito, se reconstruye el registro de transacciones. La reconstrucción del registro de transacciones puede provocar la pérdida de consistencia transaccional.

Si el comando DBCC CHECKDB tiene éxito, la base de datos está en un estado físicamente consistente y el estado de la base de datos se establece en ONLINE. Sin embargo, la base de datos puede contener una o más inconsistencias transaccionales. Se recomienda ejecutar DBCC CHECKCONSTRAINTS para identificar cualquier fallo de lógica empresarial y realizar inmediatamente una copia de seguridad de la base de datos.Si el comando DBCC CHECKDB falla, la base de datos no puede repararse.

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 publicación y suscripción) y a la base de datos de distribución utilizada por la replicación. Las bases de datos de publicación y suscripción incluyen tablas publicadas y tablas de metadatos de replicación. Tenga en cuenta los siguientes problemas potenciales en estas bases de datos:

• Tablas publicadas. Es posible que las acciones realizadas por el proceso CHECKDB para reparar los datos de usuario corruptos no se repliquen:
• La replicación de fusión utiliza desencadenantes para realizar un seguimiento de los cambios en las tablas publicadas. Si el proceso CHECKDB inserta, actualiza o elimina filas, los desencadenantes no se activan; por lo tanto, el cambio no se replica.
• La replicación transaccional utiliza el registro de transacciones para realizar un seguimiento de los cambios en las tablas publicadas. A continuación, el Agente Lector de Registros traslada estos cambios a la base de datos de distribución. Algunas reparaciones de DBCC, aunque se registran, no pueden ser replicadas por el Agente Lector de Registros. Por ejemplo, si el proceso CHECKDB desasigna una página de datos, el Log Reader Agent no traduce esto a una sentencia DELETE; por lo tanto, el cambio no se replica.
• Replicación de tablas de metadatos. Las acciones realizadas por el proceso CHECKDB para reparar las tablas de metadatos de replicación corruptas requieren la eliminación y la reconfiguración de la replicación.

Si tiene que 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. Interrumpa el sistema: Detener la actividad en la base de datos y en todas las demás bases de datos de la topología de replicación y, a continuación, intentar sincronizar todos los nodos. Para obtener más información, consulte Quiesce a Replication Topology (Replication Transact-SQL Programming).
2. Ejecute DBCC CHECKDB.
3. Si el informe DBCC CHECKDB incluye reparaciones para cualquier tabla en la base de datos de distribución o cualquier tabla de metadatos de replicación en una base de datos de usuario, elimine y vuelva a configurar la replicación. Para obtener más información, consulte Desactivación de la publicación y la distribución.
4. Si el informe DBCC CHECKDB incluye reparaciones para cualquier tabla replicada, realice la validación de datos para determinar si hay diferencias entre los datos de las bases de datos de publicación y de suscripción.

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

Requiere ser miembro del rol fijo de servidor sysadmin o del rol fijo de base de datos db_owner.

Ejemplos

A. Comprobando tanto la base de datos actual como otra base de datos

El siguiente ejemplo ejecuta DBCC CHECKDB para la base de datos actual y para la base de datos AdventureWorks2012.

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

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

El siguiente ejemplo comprueba la base de datos actual y suprime todos los mensajes informativos.

DBCC CHECKDB WITH NO_INFOMSGS; GO 

Vea 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)