Il fatto che il comando DBCC CHECKDB preveda una serie di opzioni che lascino intravedere una possibilità di recuperare i dati a seguito di un errore logico o fisico di allocazione, produce un falso senso di sicurezza in coloro i quali si attendono un miracolo che non può arrivare.

Qualunque sia l'entità del danno il tentativo di ripararlo può produrre una perdita di dati più o meno consistente a seconda del numero di pagine che sono state coinvolte e, soprattutto, della tipologia di informazioni in esse contenute. Se pensate che il danno su una pagina dati possa farvi perdere decine o centinaia di record, immaginate al danno su una pagina di sistema che referenzia centinaia di tabelle la cui "riparazione" lascerebbe le tabelle perfettamente integre ma di fatto inaccessibili.

In questi casi la soluzione migliore per salvaguardare l'integrità logica e fisica dei dati è sempre quella di ricorrere al ripristino di un backup recente, magari mantenendo in linea il database corrotto per trasferirvi determinate informazioni salvate successivamente al backup (ma in quest'ultimo caso attenzione ad eventuali problemi di consistenza dei dati).

Per chi volesse approfondire segnalo questa serie di post di Paul Randal.

Bye