DBCC CHECKDB: Guía completa de MS SQL Server Salud de la base de datos (2026)

DBCC CHECKDB es SQL ServerLa principal herramienta de integridad de bases de datos. Aprenda a usarla con ejemplos, a corregir errores y a optimizar el rendimiento.

3. Ejecución de DBCC CHECKDB: paso a paso

Prerrequisitos de 3.1

A continuación se muestra la lista de verificación antes de ejecutar cualquier operación DBCC CHECKDB:

• Copia de seguridad completa de la base de datos – Cree una copia de seguridad completa antes de ejecutar comprobaciones de integridad como red de seguridad en caso de que se descubran daños o se hagan necesarias operaciones de reparación.
• Permisos adecuados – Necesita permisos de administrador del sistema o db_owner para ejecutar comandos DBCC CHECKDB
• Recursos del sistema suficientes:
  • Memoria: 25% del tamaño de la base de datos
  • Espacio de Tempdb: 10-15% del tamaño de la base de datos
  • CPU: 50-70% de disponibilidad durante el mantenimiento
  • E/S: Se esperan operaciones de lectura pesadas
• Accesibilidad de la base de datos – Verifique que su base de datos sea accesible y no esté en un estado restringido, ya que CHECKDB requiere acceso de lectura a todas las páginas de la base de datos

3.2 Comando básico

El most El comando básico DBCC CHECKDB incluye tres variaciones comunes:

(1) Verifique la base de datos actual (sin parámetros):

DBCC CHECKDB

(2) Comprobar una base de datos por nombre:

DBCC CHECKDB ('YourDatabaseName')

(3) Comprobar una base de datos por ID:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Este comando fundamental realiza una comprobación completa de la integridad de la base de datos especificada, examinando todas las tablas, índices y estructuras del sistema. En bases de datos con nombres estándar sin espacios, puede omitir las comillas. El comando se ejecutará hasta su finalización, mostrando mensajes de progreso y resultados finales. Esta sintaxis básica funciona perfectamente con bases de datos pequeñas o cuando dispone de tiempo suficiente para el mantenimiento.

A continuación se muestra una captura de pantalla de la ejecución de DBCC CHECKDB en SQL Server Estudio de gestión (SSMS):

3.3 Opciones completas

A continuación se muestran las opciones completas para DBCC CHECKDB:

Categoría:	Opción	Descripción	Ejemplo de DBCC CHECKDB
Opciones de reparación	REPAIR_REBUILD	Reparaciones sin pérdida de datos (por ejemplo, reconstrucciones de índices)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Sin reparación. Solo compatibilidad con versiones anteriores.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Repara todos los errores (puede causar pérdida de datos)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Control de alcance	NOINDEX	Omite las comprobaciones de índices no agrupados	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Comprueba únicamente la integridad del almacenamiento físico (páginas/registros)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Comprueba si hay errores lógicos en los valores de las columnas (por ejemplo, fechas no válidas)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Comprobaciones lógicas profundas (vistas indexadas, índices XML/espaciales)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Control de salida	ALL_ERRORMSGS	Muestra todos los errores (predeterminado: 200 por objeto)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Oculta mensajes informativos	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Rendimiento	TABLOCK	Utiliza bloqueos de tabla (reduce el uso de TempDB pero bloquea las escrituras)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Anula la configuración de paralelismo	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Utilidad	ESTIMATEONLY	Estima el espacio TempDB necesario. (sin verificación real)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Entendiendo sus resultados

DBCC CHECKDB generará diferentes resultados según se complete correctamente o no. A continuación, los explicaremos en detalle.

4.1 La ejecución de CHECKDB se completa correctamente

Si la ejecución de DBCC CHECKDB se completa con éxito, informará diferentes tipos de resultados dependiendo del estado de salud de su base de datos.

4.1.1 No se encontraron problemas

Si DBCC CHECKDB no encuentra ningún problema, verá un resultado similar a este:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Este resultado indica que su base de datos mantiene una integridad perfecta en todas las estructuras comprobadas.

4.1.2 Errores de corrupción encontrados

Siempre que DBCC CHECKDB detecte un error de corrupción, informará un mensaje de error con la siguiente estructura:
Guía de niveles de gravedad:

• Nivel 16-19: Errores corregibles por el usuario, a menudo corrupciones menores
• Nivel 20-24: Errores del sistema, corrupción grave que requiere atención inmediata
• Nivel 25: Errores fatales, la base de datos puede ser inaccesible

Los errores comunes incluyen:

• Errores de suma de comprobación de página (mensaje 824)
• Errores de asignación (mensaje 8928)
• Problemas de consistencia del índice (mensaje 8964)

Comprender la estructura del mensaje ayuda a priorizar las acciones de respuesta y determinar estrategias de recuperación adecuadas.

4.1.3 Mensajes informativos y de advertencia comunes

No todos los resultados de DBCC CHECKDB indican problemas graves. También puede mostrar mensajes informativos y de advertencia, como:

• Declaraciones de reparación – Mensajes que sugieren comandos de reparación para solucionar problemas menores
• Advertencias de asignación – Advertencias sobre la asignación de espacio que no afectan el acceso a los datos
• Recomendaciones de rendimiento – Sugerencias para el mantenimiento y optimización del índice
• Avisos informativos – Mensajes de estado generales que no requieren una acción inmediata

Estos mensajes brindan una valiosa guía de mantenimiento y al mismo tiempo distinguen entre daños críticos que requieren una acción inmediata y problemas menores que pueden abordarse durante las ventanas de mantenimiento regulares.

Ejemplo de mensaje de advertencia:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 La ejecución de CHECKDB se cancela

Si CHECKDB se interrumpe durante su ejecución debido a diversas razones, informará un mensaje de error y agregará un registro de errores con el código de estado a continuación:

Estado	Descripción
0	Se generó el error 8930. Esto indica una corrupción en los metadatos que finalizó el comando DBCC.
1	Se generó el error número 8967. Hubo un error interno de DBCC.
2	Se produjo un error durante la reparación de la base de datos del modo de emergencia.
3	Esto indica una corrupción en los metadatos que finalizó el comando DBCC.
4	Se detectó una violación de acceso o afirmación.
5	Se produjo un error desconocido que finalizó el comando DBCC.

Ejemplo de mensaje de error:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

O

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Ejemplo de registro de errores:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

En tal caso, puedes probar opciones avanzadas alternativas como DataNumen SQL Recovery para arreglar la corrupción en su base de datos.

5. Corrección de errores de corrupción

5.1 Copia de seguridad y restauración: la solución más segura

Cuando DBCC CHECKDB identifica errores de corrupción, restaurar desde una copia de seguridad limpia representa la opción más segura y eficaz.ost Solución confiable. Este enfoque garantiza la integridad de los datos y elimina las causas subyacentes de la corrupción. Antes de restaurar, verifique la integridad de la copia de seguridad utilizando RESTAURAR SÓLO VERIFICACIÓN Comandos y considere opciones de recuperación puntuales para minimizar la pérdida de datos. Documente los detalles de la corrupción para analizar la causa raíz, ya que los problemas de hardware o los errores de software pueden requerir atención adicional para evitar su recurrencia.

5.2 Soluciones a la corrupción a nivel de página

En caso de corrupción de páginas aisladas que afecten a pequeñas porciones de datos, SQL Server La Edición Enterprise ofrece funciones de restauración de páginas que reparan páginas dañadas específicas sin necesidad de restaurar la base de datos completa. Esta técnica avanzada requiere un modelo de recuperación completa y copias de seguridad de registros actualizadas.

Proceso de restauración de página paso a paso:

1. Identificar la página dañada del mensaje de error de CHECKDB (por ejemplo, página 1:256)
2. Realice una copia de seguridad del registro actual Para capturar transacciones recientes:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. Restaurar la página dañada desde el most copia de seguridad completa reciente:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. Aplicar copia de seguridad diferencial (si está disponible):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. Aplicar todas las copias de seguridad de registros en secuencia, incluido el que se acaba de crear:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Realice una copia de seguridad final del registro y restáurela Para actualizar la página:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Alternativa para datos no críticos: Si la corrupción afecta datos no críticos, puede exportar filas no afectadas a nuevas tablas antes de reconstruir las estructuras dañadas:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Soluciones rápidas para la corrupción del índice

La corrupción del índice a menudo responde bien a las operaciones de reconstrucción que recrean las estructuras del índice sin afectar los datos de la tabla subyacente:

ALTER INDEX ALL ON YourTable REBUILD

Este enfoque funciona particularmente bien en casos de corrupción de índices no agrupados, ya que la reconstrucción regenera las páginas de índice a partir de los datos de la tabla de origen, eliminando eficazmente la corrupción y preservando toda la información original.

6. Utilice REPAIR_REBUILD y REPAIR_ALLOW_DATA_LOSS

Si todos los métodos anteriores fallan o no son factibles, puede utilizar las opciones REPAIR_REBUILD y REPAIR_ALLOW_DATA_LOSS para reparar la base de datos.

6.1 REPARAR_RECONSTRUIR (Opción más segura):

• Usar para: Corrupción de índices y errores menores de asignación
• Seguridad de datos: Intenta corregir la corrupción sin borrar datos
• Nivel de riesgo: Bajo: no se espera pérdida de datos
• Escenarios típicos: Corrupción de índice no agrupado, problemas menores de metadatos
• Ejemplo de comando: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPARAR_PERMITIR_PERDIDA_DE_DATOS (Último recurso):

• Usar para: Corrupción grave cuando las copias de seguridad no están disponibles
• Seguridad de datos: Puede eliminar datos dañados para restaurar la funcionalidad de la base de datos
• Nivel de riesgo: Alto: posible pérdida permanente de datos
• Escenarios típicos: Corrupción de página, daños en la tabla del sistema, errores en la cadena de asignación
• Ejemplo de comando: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Mejores prácticas para estas opciones:

• Siempre prueba operaciones de reparación en copias de bases de datos cuando sea posible
• Siempre haga copias de seguridad antes de ejecutar estas opciones
• Documentar todos los cambios para fines de cumplimiento y resolución de problemas
• Establecer la base de datos en modo de usuario único antes de ejecutar operaciones de reparación

Normalmente deberíamos intentarlo REPARAR_RECONSTRUIR Opción primero. Si falla, inténtalo. REPAIR_ALLOW_DATA_LOSS .

6.4 Resultados de REPAIR_ALLOW_DATA_LOSS

6.4.1 La reparación se realiza correctamente en caso de pérdida de datos

A veces el REPAIR_ALLOW_DATA_LOSS La opción tendrá éxito, pero faltan algunos datos.ost Después de la reparación.

A continuación se muestran algunos mensajes de muestra:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Esto se debe a que DBCC CHECKDB repara la base de datos abandonando algunos registros dañados, pero en realidad, most De ellos aún se pueden recuperar vía DataNumen SQL Recovery.

Archivos de muestra:

SQL Server versión	Archivo MDF dañado	Archivo MDF arreglado por DataNumen SQL Recovery
SQL Server 2014	Error10_1.mdf (Msg 8909 seguido de Msg 8939) (600 registros lost con REPARACIÓN_PERMITIR_PÉRDIDA_DE_DATOS)	Error10_1_fijo.mdf (No hay registro lost)
SQL Server 2014	Error10_2.mdf (Msg 8909 seguido de Msg 8939) (6000 registros (50%) lost con REPARACIÓN_PERMITIR_PÉRDIDA_DE_DATOS)	Error10_2_fijo.mdf (Solo 100 registros lost)
SQL Server 2014	Error7.mdf (100 registros lost con REPARACIÓN_PERMITIR_PÉRDIDA_DE_DATOS)	Error7_fijo.mdf (Solo un registro lost)

6.4.2 Reparaciones fallidas: considere una solución profesional

If REPAIR_ALLOW_DATA_LOSS Si falla, se emitirán uno o varios mensajes de error.

A continuación hay algunos ejemplos:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

En estos escenarios, es necesario utilizar una solución profesional como DataNumen SQL Recovery para arreglar su base de datos.

Archivos de muestra

SQL Server versión	Archivo MDF dañado	Archivo MDF arreglado por DataNumen SQL Recovery
SQL Server 2014	Error1_3.mdf (Mensaje único 824)	Error1_3_fijo.mdf
SQL Server 2014	Error1_1.mdf (Errores continuos del mensaje 824)	error1_1_fijo.mdf
SQL Server 2014	Error1_2.mdf ((Mensaje 824 seguido del Mensaje 7909)	Error1_2_fijo.mdf
SQL Server 2014	Error4_1.mdf (Mensaje 8992 seguido del Mensaje 3852)	Error4_1_fijo.mdf
SQL Server 2014	Error4_2.mdf (Mensaje 8992 seguido del Mensaje 3852)	Error4_2_fijo.mdf
SQL Server 2014	Error5.mdf (Mensaje 8945)	Error5_fijo.mdf
SQL Server 2014	Error6.mdf (Mensaje 2510)	Error6_fijo.mdf
SQL Server 2014	Error2.mdf (Mensaje 2575)	Error2_fijo.mdf
SQL Server 2014	Error11.mdf (Mensaje 8905)	Error11_fijo.mdf
SQL Server 2014	Error3.mdf (Mensaje 5028)	Error3_fijo.mdf
SQL Server 2014	Error8.mdf (Mensaje 5125)	Error8_fijo.mdf
SQL Server 2014	Error9.mdf (Mensaje 3313)	Error9_fijo.mdf

7. Mejores prácticas

7.1 Programación de operaciones regulares de CHECKDB

Implemente la ejecución semanal de DBCC CHECKDB para bases de datos de producción críticas, con comprobaciones diarias para sistemas con alto volumen de transacciones. Programe las operaciones durante periodos de bajo uso para minimizar el impacto en el rendimiento y considere alternar entre comprobaciones completas y opciones PHYSICAL_ONLY según el tamaño de la base de datos y las ventanas de mantenimiento. Programación automatizada mediante SQL Server El agente garantiza una ejecución consistente al tiempo que proporciona capacidades centralizadas de monitoreo y alerta.

7.2 Gestión del impacto en el rendimiento

Las operaciones DBCC CHECKDB consumen una cantidad considerable de recursos del sistema, lo que podría afectar la actividad simultánea de los usuarios. Supervise el uso de la CPU, el consumo de memoria y la E/S de disco durante las comprobaciones para comprender los patrones de impacto en el rendimiento. Considere usar opciones NOINDEX para las comprobaciones rutinarias, reservando la validación completa para las ventanas de mantenimiento mensuales. Implemente extensiones de tiempo de espera de consultas y estrategias de comunicación con los usuarios para gestionar las expectativas durante los periodos de comprobación de integridad.

7.3 Planificación de la ventana de mantenimiento

Coordine la programación de DBCC CHECKDB con otras actividades de mantenimiento, como copias de seguridad, reconstrucción de índices y actualizaciones de estadísticas. Evite la superposición de operaciones que consumen muchos recursos y que podrían causar una degradación del rendimiento o problemas de tiempo de espera. Planifique las ventanas de mantenimiento según las proyecciones de crecimiento del tamaño de la base de datos, garantizando el tiempo suficiente para una verificación completa de la integridad a medida que aumenta el volumen de datos.

7.4 Monitoreo y alertas automatizadas

Configurar SQL Server Alertas de agente para notificar inmediatamente a los administradores cuando DBCC CHECKDB detecta corrupción. Implemente soluciones de análisis de registros que extraigan y categoricen los resultados de las comprobaciones de integridad, lo que permite el análisis de tendencias y la identificación proactiva de problemas. Cree procedimientos de escalamiento que definan los plazos de respuesta y el personal responsable para los diferentes niveles de gravedad de la corrupción.

8. DBCC CHECKTABLE: La alternativa ligera

8.1 Cuándo utilizar CHECKTABLE en lugar de CHECKDB

DBCC CHECKTABLE proporciona una verificación de integridad enfocada en tablas individuales, lo que lo hace ideal para tarSolución de problemas y mantenimiento de objetos específicos de la base de datos. Utilice CHECKTABLE para investigar problemas de rendimiento con tablas específicas, validar tablas de negocio críticas entre comprobaciones completas de la base de datos o cuando las limitaciones de tiempo impiden una validación completa. Este enfoque resulta especialmente útil en bases de datos grandes donde las operaciones completas de CHECKDB exceden las ventanas de mantenimiento disponibles.

8.2 Sintaxis y ejemplos de DBCC CHECKTABLE

El comando básico CHECKTABLE tarobtiene tablas específicas:

DBCC CHECKTABLE('YourTable')

Al igual que CHECKDB, CHECKTABLE admite varias opciones, incluyendo NOINDEX para optimizar el rendimiento y parámetros de reparación para la resolución de daños. También puede especificar nombres de esquema para una identificación precisa de las tablas:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Esta tarEl enfoque administrado permite la verificación granular de la integridad mientras se mantiene el rendimiento del sistema durante el horario comercial.

8.3 Beneficios de rendimiento para bases de datos grandes

Las operaciones de CHECKTABLE se completan significativamente más rápido que las comprobaciones completas de la base de datos, lo que permite una verificación de integridad más frecuente de las tablas críticas. Este enfoque permite la validación diaria de las tablas esenciales de negocio, reservando las operaciones completas de CHECKDB para programaciones semanales o mensuales. El menor consumo de recursos hace que CHECKTABLE sea adecuado para la ejecución en entornos de producción con un impacto mínimo en el usuario.

9. Cuando CHECKDB falla

DBCC CHECKDB fallará en varios escenarios, incluidos:

• Ejecución de DBCC CHECKDB termina anormalmente
• La ejecución de DBCC CHECKDB se completa correctamente, pero el opciones de reparación No se pudo reparar la base de datos.

En estos escenarios, necesitamos una herramienta más profesional que nos ayude a corregir los errores en la base de datos.

9.1 Introducción a DataNumen SQL Recovery

DataNumen SQL Recovery Proporciona capacidades más avanzadas:

• Mejor tasa de recuperación en la industria.
• Recupere archivos de base de datos severamente dañados.
• Recupere todos los objetos de la base de datos, incluidas tablas, índices, vistas, desencadenadores, reglas y valores predeterminados.
• Recupere procedimientos almacenados, funciones escalares, funciones con valores de tabla en línea y funciones con valores de tabla de varias instrucciones.
• Recuperar registros eliminados permanentemente.
• Descifrar objetos cifrados en SQL Server bases de datos.
• Reparar archivos MDF por lotes.
• Opciones de reparación integrales.
• Registro e informes avanzados.
• Apoyo para todos SQL Server versiones.
• Disponibilidad de soporte técnico
• Actualizaciones y mejoras periódicas

9.2 Comparación de la tasa de éxito

Las tasas de éxito de recuperación difieren significativamente:

• DBCC CHECKDB y CHECKTABLE: un 1.27% tasa de recuperación promedio
• DataNumen: un 92.6% índice de recuperación

A continuación se muestra una comparación competitiva completa:

9.3 Recuperación de la corrupción grave

Capacidades avanzadas para casos graves:

• Recuperación de almacenamiento dañado físicamente
• Recuperación de unidades formateadas o sistemas averiados
• Recuperación de imágenes de disco, archivos de respaldo, archivos de disco de máquina virtual, temporary archivos, etc.

9.4 Cuándo considerar soluciones profesionales

• No hay disponibilidad de copias de seguridad recientes
• DBCC CHECKDB falla
• Escenarios graves de corrupción
• Manejo de datos empresariales críticos
• Cuando el tiempo es crítico
• Cuando la recuperación máxima es esencial

10. Preguntas frecuentes

11. Conclusión

11.1 Resumen de puntos clave

11.1.1 Resumen de los comandos esenciales de DBCC CHECKDB

Domine la sintaxis básica DBCC CHECKDB para una verificación integral de la base de datos, utilice las opciones NOINDEX y PHYSICAL_ONLY para la optimización del rendimiento y comprenda CHECKTABLE para tarVerificación de tablas obtenidas. Estos comandos fundamentales constituyen la base del mantenimiento proactivo de bases de datos, lo que permite la detección temprana de daños y la monitorización sistemática de la integridad.

11.1.2 Recordatorio de mejores prácticas críticas

Mantenga siempre copias de seguridad actualizadas antes de ejecutar comprobaciones de integridad, programe operaciones regulares de CHECKDB según la criticidad de la base de datos e implemente la monitorización automatizada para alertas inmediatas de corrupción. Recuerde que la prevención mediante la monitorización regular supera los enfoques reactivos, y las soluciones de recuperación profesionales ofrecen valiosas opciones de copia de seguridad cuando las herramientas estándar resultan insuficientes.

11.2 Cuándo usar DBCC CHECKDB frente a soluciones avanzadas

Utilice DBCC CHECKDB para la monitorización rutinaria de la integridad y la resolución de daños menores, reservando las herramientas de recuperación profesionales para escenarios de daños graves que superen las funciones de reparación integradas. El marco de decisión debe considerar la disponibilidad de las copias de seguridad, la criticidad de los datos, las limitaciones de tiempo y la gravedad de los daños. Los administradores de bases de datos eficaces combinan la monitorización regular de CHECKDB con estrategias integrales de copias de seguridad y el conocimiento de las opciones avanzadas de recuperación cuando los métodos estándar resultan insuficientes.

11.3 Lista rápida de verificación de salud diaria para administradores de bases de datos

Además de ejecutar DBCC CHECKDB, mantenga la salud óptima de la base de datos con estas prácticas diarias esenciales:

1. Verificar la integridad de la copia de seguridad

• Confirmar que las copias de seguridad programadas se completaron correctamente
• Utilice RESTORE VERIFYONLY para verificar la legibilidad de la copia de seguridad
• Asegúrese de que las copias externas estén sincronizadas y accesibles

También puede obtener más información en Nuestra guía completa sobre SQL Server copia de seguridad.

2. Revisar el estado de consistencia

• Consulte los resultados automatizados de DBCC CHECKDB de las ejecuciones nocturnas
• Monitorización SQL Server registros de errores para advertencias de corrupción
• Investigar inmediatamente cualquier fallo de integridad

3. Supervisar el estado del servidor

• Verifique las métricas de E/S de CPU, memoria y disco
• Verificar la disponibilidad de espacio en tempdb
• Identificar procesos bloqueados y consultas de larga duración

4. Seguimiento de la actividad de interbloqueo

• Revisar los gráficos de interbloqueo de los eventos de salud del sistema
• Identificar consultas problemáticas y optimizarlas con los equipos de desarrollo
• Monitorear el número de víctimas de bloqueos y el impacto comercial

Recordatorios importantes

• Evite la reducción frecuente de la base de datos Aumenta la fragmentación y degrada el rendimiento. Reduzca el tamaño solo después de eliminar grandes cantidades de datos cuando sea realmente necesario.
• Automatizar tareas de monitorización usando SQL Server Trabajos de agente o planes de mantenimiento con alertas para problemas críticos.
• Pruebe los procedimientos de recuperación ante desastres semanalmente para garantizar que las copias de seguridad se puedan restaurar y que los objetivos de recuperación sigan siendo alcanzables.

Al combinar esta lista de verificación diaria con las operaciones regulares de DBCC CHECKDB, crea una protección integral para su entorno de base de datos a través de un monitoreo proactivo y una respuesta rápida a los problemas.

12. referencias

1. Microsoft Learn. “DBCC CHECKDB (Transact-SQL)”. SQL Server Documentación. Corporación Microsoft.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. “Solucione los errores de consistencia de la base de datos reportados por DBCC CHECKDB”. SQL Server Documentación. Corporación Microsoft.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors