La siguiente es una compilación de resultados que leí. Encontrará mucha más información en los blogs y documentos vinculados.
Primero, puede suceder que DBCC CHECKDBno detecte inconsistencias si desactiva la suma de verificación o la verificación de rasgado de página. Una cita de Paul Randal en esta publicación :
Tiene razón: si la página rasgada o la suma de comprobación no está activada, no hay nada que pueda detectarse en lo que respecta a las opciones de protección de página. CHECKDB aún puede detectar las corrupciones que encuentra al hacer todas las comprobaciones de consistencia que hace, pero no verá corrupciones en el medio de los valores de datos, por ejemplo.
Ja, ese es el fastidio de activar las sumas de verificación de página: no pasa nada hasta que una página se lee, cambia y vuelve a escribir. La única forma de obligar a las páginas a obtener sumas de verificación es hacer que cambien, por ejemplo, mediante la reconstrucción de todos sus índices, que pueden ser desagradables, no hay ninguna herramienta 'táctil' en absoluto.
La situación anterior puede afectarlo si actualizó una base de datos de SQL Server 2000 o anterior a 2005 o posterior. Luego, debe habilitar manualmente las sumas de verificación de página con ALTER DATABASE para activarlas. Pero luego el segundo párrafo de la cita anterior entra en acción y podría molestarlo.
BACKUP WITH CHECKSUMdetectará inconsistencias en la suma de verificación, pero solo si la página ya tenía una suma de verificación escrita cuando se realiza una copia de seguridad. Normalmente DBCC CHECKDBtambién detecta estos errores, por lo que no es una buena idea usar BACKUP WITH CHECKSUM para reemplazar DBCC CHECKDB .
Ahora hay una segunda posibilidad para DBCC CHECKDBno mostrar inconsistencias, incluso si hay algunas. Para esto solo estoy citando nuevamente a Paul Randal en Conceptos erróneos sobre la corrupción: ¿pueden desaparecer? :
Entonces, ¿qué pasa con las corrupciones que desaparecen? Esto entra en cómo funcionan las comprobaciones de consistencia. Las verificaciones de consistencia solo se ejecutan en las páginas de la base de datos que están asignadas. Si una página no está asignada a nada, sus 8192 bytes no tienen sentido y no se pueden interpretar. No se confunda entre reservado y asignado: explico eso en las primeras ideas erróneas publicadas aquí. Mientras se asigne una página, DBCC CHECKDB verificará la coherencia, incluida la prueba de la suma de comprobación de la página, si existe. Puede parecer que una corrupción "desaparece" si se asigna una página corrupta en el momento en que se ejecuta un DBCC CHECKDB, pero luego se desasigna cuando se ejecuta el siguiente DBCC CHECKDB. La primera vez se informará como corrupto, pero la segunda vez no se asignará, por lo que no se verifica la coherencia y no se informará como corrupto. Parece que la corrupción ha desaparecido misteriosamente. Pero no lo ha hecho, es solo que la página corrupta ya no está asignada. No hay nada que impida que SQL Server desplace una página corrupta; de hecho, eso es lo que hacen muchas de las reparaciones de DBCC CHECKDB: desasignar lo que está roto y corregir todos los enlaces.
No tengo una respuesta final a su pregunta, pero como DBCC CHECKDBsolo verifica las páginas asignadas, no mostrará inconsistencias en las páginas desasignadas. La única situación que puedo imaginar ahora es que BACKUP también realiza copias de seguridad de las páginas desasignadas que muestran posibles errores de suma de verificación que se omitieron DBCC CHECKDB.