Quella che segue è una raccolta di risultati che ho letto. Troverai molte più informazioni nei blog e nei documenti collegati.
Innanzitutto, può accadere che DBCC CHECKDBnon rilevi incoerenze se si disattiva il checksum o la verifica di torn_page. Una citazione di Paul Randal in questo post :
Hai ragione: se la pagina strappata o il checksum non è attivato, non è possibile rilevare nulla per quanto riguarda le opzioni di protezione della pagina. CHECKDB potrebbe ancora rilevare le corruzioni rilevate eseguendo tutti i controlli di coerenza che esegue, ma non vedrà corruzioni nel mezzo dei valori dei dati, ad esempio.
Ah - questo è il problema di attivare i checksum delle pagine - non succede nulla finché una pagina non viene letta, modificata e riscritta. L'unico modo per forzare le pagine a ottenere checksum è quello di farle cambiare, ad esempio ricostruendo tutti gli indici, il che potrebbe essere sgradevole, non esiste alcun strumento "touch".
La situazione precedente può colpirti se hai aggiornato un database da SQL Server 2000 o prima al 2005 o successivo. È quindi necessario abilitare manualmente i checksum delle pagine con ALTER DATABASE per renderli attivi. Ma poi il 2 ° paragrafo della citazione precedente entra in gioco e potrebbe disturbarti.
BACKUP WITH CHECKSUMrileverà incoerenze del checksum, ma solo se alla pagina è già stato scritto un checksum, quando viene eseguito il backup. Normalmente DBCC CHECKDBrileva anche questi errori, quindi non è una buona idea usare BACKUP CON CHECKSUM per sostituire DBCC CHECKDB .
Ora c'è una seconda possibilità per DBCC CHECKDBnon mostrare incoerenze, anche se ce ne sono. Per questo sto solo citando di nuovo Paul Randal in Idee sbagliate sulle corruzioni: possono scomparire? :
E le corruzioni che scompaiono? Questo spiega come funzionano i controlli di coerenza. I controlli di coerenza vengono eseguiti solo sulle pagine del database allocate. Se una pagina non è allocata a nulla, gli 8192 byte di essa sono privi di significato e non possono essere interpretati. Non confonderti tra riservato e allocato - lo spiego nei post sulle idee sbagliate qui. Finché una pagina viene allocata, verrà controllata la coerenza da DBCC CHECKDB, incluso il test del checksum della pagina, se esiste. Una corruzione può sembrare "scomparire" se una pagina corrotta viene allocata al momento dell'esecuzione di un DBCC CHECKDB, ma viene quindi allocata al momento dell'esecuzione del successivo DBCC CHECKDB. La prima volta verrà segnalato come corrotto, ma la seconda volta non viene allocato, quindi non viene verificato la coerenza e non verrà segnalato come corrotto. La corruzione sembra misteriosamente svanita. Ma non è così: è solo che la pagina corrotta non è più allocata. Non c'è nulla che impedisca a SQL Server di deallocare una pagina corrotta - in effetti, questo è ciò che fanno molte riparazioni di DBCC CHECKDB - deallocare ciò che è rotto e sistemare tutti i collegamenti.
Non ho una risposta definitiva alla tua domanda, ma poiché DBCC CHECKDBcontrolla solo le pagine allocate, non mostrerà incoerenze nelle pagine deallocate. L'unica situazione che posso immaginare ora è che BACKUP esegue anche il backup di quelle pagine deallocate che mostrano potenziali errori di checksum che sono stati saltati DBCC CHECKDB.