Ce qui suit est une compilation des résultats que j'ai lus. Vous trouverez beaucoup plus d'informations dans les blogs et documents liés.
Tout d'abord, il peut arriver que DBCC CHECKDBles incohérences ne soient pas détectées si vous désactivez la vérification de la somme de contrôle ou de torn_page. Une citation de Paul Randal dans ce post :
Vous avez raison - si la page déchirée ou la somme de contrôle n'est pas activée, rien ne peut être détecté en ce qui concerne les options de protection de la page. CHECKDB peut toujours détecter les corruptions qu'il trouve en effectuant toutes les vérifications de cohérence qu'il fait - mais il ne verra pas les corruptions au milieu des valeurs de données, par exemple.
Ha - c'est l'inconvénient d'activer les sommes de contrôle de page - rien ne se passe jusqu'à ce qu'une page soit lue, modifiée et réécrite. La seule façon de forcer les pages à obtenir des sommes de contrôle est de les faire changer - par exemple, en reconstruisant tous vos index, ce qui peut être désagréable - il n'y a pas du tout d'outil tactile.
La situation ci-dessus peut vous toucher si vous avez mis à niveau une base de données de SQL Server 2000 ou antérieur à 2005 ou ultérieur. Vous devez ensuite activer manuellement les sommes de contrôle de page avec ALTER DATABASE pour les activer. Mais alors le 2ème paragraphe de la citation ci-dessus entre en jeu et pourrait vous déranger.
BACKUP WITH CHECKSUMdétectera les incohérences de la somme de contrôle, mais uniquement si la page avait déjà une somme de contrôle écrite lors de la sauvegarde. Détecte DBCC CHECKDBégalement normalement ces erreurs, il n'est donc pas judicieux d'utiliser BACKUP WITH CHECKSUM pour remplacer DBCC CHECKDB .
Maintenant, il y a une deuxième possibilité pour DBCC CHECKDBne pas montrer d'incohérences, même s'il y en a. Pour cela, je cite à nouveau Paul Randal dans les idées fausses sur les corruptions: peuvent-elles disparaître? :
Alors qu'en est-il des corruptions qui disparaissent? Cela explique le fonctionnement des contrôles de cohérence. Les contrôles de cohérence ne s'exécutent que sur les pages de la base de données qui sont allouées. Si une page n'est allouée à rien, les 8192 octets de celle-ci n'ont aucun sens et ne peuvent pas être interprétés. Ne vous trompez pas entre réservé et alloué - j'explique cela dans le premier message sur les idées fausses ici. Tant qu'une page est allouée, sa cohérence sera vérifiée par DBCC CHECKDB, y compris le test de la somme de contrôle de la page, si elle existe. Une corruption peut sembler «disparaître» si une page corrompue est allouée au moment où un DBCC CHECKDB s'exécute, mais est ensuite désallouée au moment où le prochain DBCC CHECKDB s'exécute. La première fois, il sera signalé comme corrompu, mais la deuxième fois, il ne sera pas alloué, il n'est donc pas vérifié de cohérence et ne sera pas signalé comme corrompu. La corruption semble avoir disparu mystérieusement. Mais ce n'est pas le cas - c'est juste que la page corrompue n'est plus allouée. Il n'y a rien qui empêche SQL Server de désallouer une page corrompue - en fait, c'est ce que font la plupart des réparations DBCC CHECKDB - désallouer ce qui est cassé et réparer tous les liens.
Je n'ai pas de réponse définitive à votre question, mais comme DBCC CHECKDBne vérifie que les pages allouées, il ne montrera pas d'incohérences dans les pages désallouées. La seule situation que je peux imaginer maintenant est que BACKUP sauvegarde également les pages désallouées montrant des erreurs de somme de contrôle potentielles qui ont été ignorées DBCC CHECKDB.