Compartir a través de

DBCC CHECKDB (Transact-SQL)

  • Artículo

Actualizado: 17 de noviembre de 2008

Comprueba la integridad física y lógica de todos los objetos de la base de datos especificada mediante 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 los datos de 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, vea sus descripciones.

Icono de vínculo a temasConvenciones 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 ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
        }
    ]
]

Argumentos

  • database_name | database_id | 0
    Es el nombre o identificador 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 ajustarse a las reglas de los identificadores.
  • NOINDEX
    Especifica que no se deben realizar comprobaciones intensivas de índices sin agrupar 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 realizan en los índices de las tablas del sistema.

  • REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
    Especifica que DBCC CHECKDB repare los errores que encuentre. 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.
    • REPAIR_FAST
      La sintaxis se mantiene únicamente por compatibilidad con versiones anteriores. No se realizan acciones de reparación.
    • REPAIR_REBUILD
      Lleva a cabo rápidamente acciones de reparación menores, 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 riesgo de pérdida de datos.
    ms176064.note(es-es,SQL.90).gifImportante:
    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 utiliza 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. 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. Los mensajes de error se ordenan por identificador de objeto, salvo en el caso de los mensajes generados desde la base de datos tempdb.

    En SQL Server Management Studio, el número máximo de mensajes de error devueltos es 1000. Con Management Studio, puede que tenga que ejecutar DBCC CHECKDB varias veces para obtener una lista completa de errores cuando se especifica ALL_ERRORMSGS. Se recomienda ejecutar el comando DBCC con la utilidad sqlcmd o programando un trabajo del Agente SQL Server para ejecutar el comando y dirigir el resultado a un archivo. Cualquiera de estos métodos garantizará que el comando se ejecute una vez e informará de todos los mensajes de error.

  • NO_INFOMSGS
    Suprime todos los mensajes de información.

  • TABLOCK
    Hace que DBCC CHECKDB obtenga bloqueos en lugar de utilizar 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 disminuye la simultaneidad disponible en la base de datos mientras DBCC CHECKDB está ejecutándose. Para obtener más información acerca de los bloqueos, vea Modos de bloqueo.

    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 para la base de datos tempdb que se prevé 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, la estructura física de los árboles B 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. PHYSICAL_ONLY siempre implica NO_INFOMSGS y no se permite con ninguna de las opciones de reparación.

  • 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.

    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. 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 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 podría afectar a CHECKDB la actualización de bases de datos de versiones anteriores de SQL Server, vea la sección Notas más adelante en este tema.

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

    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.

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.

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

The command(s) completed successfully.

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

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.

Si se especifica ESTIMATEONLY, DBCC CHECKDB devuelve el siguiente conjunto de resultados:

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.

Notas

En versiones anteriores de SQL Server, los valores del recuento de filas por tabla y por índice, y del recuento de páginas pueden llegar a ser incorrectos. En algunas circunstancias, incluso uno o varios valores podrían convertirse en negativos. En SQL Server 2005, estos valores siempre se mantienen correctamente. Por tanto, las bases de datos creadas en SQL Server 2005 nunca contendrán recuentos incorrectos; sin embargo, las bases de datos actualizadas desde SQL Server 2005 sí podrían contenerlos. Esto no implica que se haya producido ningún daño en los datos almacenados en la base de datos. DBCC CHECKDB se ha mejorado para detectar si alguno de estos recuentos se vuelve negativo. En caso de que se detecte un recuento negativo, la salida de DBCC CHECKDB contiene una advertencia y una recomendación para que se ejecute DBCC UPDATEUSAGE con el fin de solucionar el problema. Aunque pudiera parecer que la causa del mismo es la actualización de la base de datos a SQL Server 2005, los recuentos incorrectos existían antes de la actualización.

DBCC CHECKDB no examina los índices deshabilitados. Para obtener más información acerca de los índices deshabilitados, vea Deshabilitar índices.

Si un tipo definido por el usuario se marca como ordenado por bytes, sólo 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 obtener más información, vea User-Defined Type Requirements.

Dado que sólo se puede modificar la base de datos Resource en modo de usuario único, el comando DBCC CHECKDB no se puede ejecutar directamente en ella. No obstante, al ejecutar DBCC CHECKDB en la base de datos maestra, se ejecuta un segundo comando CHECKDB internamente en la base de datos de recursos. 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.

En las versiones de SQL Server 2005 anteriores al Service Pack 2, al ejecutar DBCC CHECKDB se borra la memoria caché del plan de la instancia de SQL Server. Al borrar la memoria caché del plan, se provoca una nueva compilación de todos los planes de ejecución posteriores y puede ocasionar una disminución repentina y temporal del rendimiento de las consultas. En el Service Pack 2, al ejecutar DBCC CHECKDB no se borra la memoria caché del plan.

Instantánea de base de datos interna

DBCC CHECKDB utiliza una instantánea interna de la base de datos para la coherencia transaccional necesaria para realizar estas comprobaciones. Así se evitan problemas de bloqueo y simultaneidad cuando se ejecutan estos comandos. Para obtener más información, vea Descripción del tamaño de los archivos dispersos en instantáneas de bases de datos y la sección sobre el uso de la instantánea de base de datos interna DBCC en 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 en la base de datos maestra 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 se debe a que, por motivos de rendimiento, las instantáneas de bases de datos no están disponibles en tempdb. Eso significa que no es posible obtener la coherencia transaccional necesaria.

Prácticas recomendadas

En SQL Server 2005, la ejecución de DBCC CHECKDB sin opciones puede tardar mucho más tiempo que en versiones anteriores. Este comportamiento se debe a las razones siguientes:

  • Las comprobaciones lógicas incluidas 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 de SQL Server 2005.

Por tanto, se recomienda utilizar la opción PHYSICAL_ONLY para un uso frecuente en sistemas de producción. El uso de PHYSICAL_ONLY puede reducir mucho el tiempo de ejecución de DBCC CHECKDB en bases 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.

Comprobar 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 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).

Descripción de los mensajes de error de DBCC

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

Informes de errores

En SQL Server 2005 con el Service Pack 1, se crea un archivo de volcado (SQLDUMPnnnn.txt) en el directorio LOG de SQL Server siempre que DBCC CHECKDB detecta un error relacionado con datos dañados. Si la recopilación de datos de uso de características y la creación de 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 CHECKDB y salida de diagnóstico adicional. 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 CHECKDB notifica 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. En SQL Server 2000, DBCC CHECKDB no realiza comprobaciones de intervalo o de integridad en estos valores de columna. Sin embargo, en SQL Server 2005, 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 2005 no puede reparar estos errores automáticamente, será necesario actualizar el valor de la columna de forma manual. Si CHECKDB detecta un error de este tipo, 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.

Resolver 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 ponerse en línea con un estado físicamente coherente. Estas reparaciones sólo deben utilizarse como último recurso y sólo 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 de la función fija 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 utiliza 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 utilizando 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, este volverá a generarse. Volver a generar el registro de transacciones puede provocar la pérdida de coherencia transaccional.

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, no se puede reparar la base de datos.

Ejecutar 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 la publicación y de la suscripción) y a la base de datos de distribución utilizada por la réplica. Las bases de datos de la publicación y la suscripción incluyen tablas publicadas y tablas de metadatos de réplica. 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 réplica 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 réplica 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 acción en una instrucción DELETE; por tanto, el cambio no se replica.
  • Tablas de metadatos de réplica. Las acciones que realiza el proceso CHECKDB para reparar tablas de metadatos de réplica dañadas requieren que se quite y se vuelva a configurar la réplica.

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. Detenga el sistema: detenga la actividad en la base de datos y en todas las demás bases de datos de la topología de réplica, e intente sincronizar todos los nodos. Para obtener más información, vea How to: Quiesce a Replication Topology (Replication Transact-SQL Programming).
  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 réplica en una base de datos de distribución, quite la réplica y vuelva a configurarla. Para obtener más información, vea Quitar la réplica.
  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 la publicación y de la suscripción. Para obtener más información, vea Los datos en el publicador y el suscriptor no coinciden.

Permisos

Debe pertenecer a la función fija de servidor sysadmin o a la función fija de base de datos db_owner.

Ejemplos

A. Comprobar la base de datos actual y la base de datos AdventureWorks

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

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

B. Comprobar 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

Vea también

Referencia

DBCC (Transact-SQL)
sp_helpdb (Transact-SQL)
Tablas del sistema (Transact-SQL)

Otros recursos

Arquitectura física de una base de datos
Descripción del tamaño de los archivos dispersos en instantáneas de bases de datos
Solucionar problemas de errores DBCC en vistas indizadas
Optimizar el rendimiento de DBCC CHECKDB

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios

Versión Historial

17 de noviembre de 2008
Contenido nuevo:
  • En la definición de ALL_ERRORMSGS se describió la funcionalidad nueva de SP3.

12 de diciembre de 2006
Contenido nuevo:
  • Se agregó información en la sección Notas acerca de cuándo DBCC CHECKDB borra la memoria caché del plan.

17 de julio de 2006
Contenido nuevo:
  • Se agregó información sobre cómo devolver todos los mensajes de error en la definición de ALL_ERRORMSGS.

14 de abril de 2006
Contenido nuevo:
  • Se agregó la sección "Informes de errores". En esta sección se describe la nueva funcionalidad relacionada con el SP1.
  • Se agregó la sección "Resolver errores en modo de emergencia de base de datos".

5 de diciembre de 2005
Contenido nuevo:
  • Se agregó información sobre el mensaje de error 2537 para tipos definidos por el usuario ordenados por bytes.
  • Se agregó la sección "Ejecutar DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS en bases de datos replicadas".
  • Se agregó la sección "Descripción de los mensajes de error de DBCC".
Contenido modificado:
  • Se corrigió la sintaxis.
  • Se corrigió la definición de REPAIR_FAST. La opción no lleva a cabo acciones de reparación.
  • Se corrigió la definición de TABLOCK; se agregaron las operaciones que no se llevan a cabo cuando se especifica la opción.