Il comando CHECKDB (DBCC CHECKDB) è usato per controllare l’integrità (fisica & logica) degli oggetti in un database SQL Server. L’opzione di riparazione DBCC non è disponibile nelle tabelle ottimizzate per la memoria e quindi, porta alla necessità di un backup regolare del database.Nel caso in cui si verifichi un problema in una tabella ottimizzata per la memoria, i dati possono essere ripristinati dall’ultimo backup fatto.
Le varie operazioni che vengono eseguite da CHECKDB sono:
- DBCC CHECKALLOC esecuzione sul database SQL.
- DBCC CHECKTABLE esecuzione su ogni tabella e vista del database SQL.
- DBCC CHECKCATALOG esecuzione sul database SQL.
- Validazione del contenuto nella vista indicizzata del database.
- Validazione della coerenza a livello di link tra le directory dei file e i metadati delle tabelle.
- Validazione dei dati del service broker.
Siccome DBCC CHECKDB esegue tutti gli altri comandi, non sarà necessario eseguire separatamente i comandi CHECKALLOC, CHECKTABLE e CHECKCATALOG.
Sintassi di DBCC CHECKDB
Gli argomenti usati nella sintassi di cui sopra significano quanto segue:
nome_database | database_id | 0 Questo è il nome del database; se il nome non è indicato o è scritto solo 0, allora viene usato il database corrente. NOINDEX Specifica che il controllo di integrità delle tabelle con indice non clusterizzato non dovrebbe essere eseguito. Questo porta a una diminuzione del tempo di esecuzione completo, ma questa sintassi non influisce sui dati che risiedono nelle tabelle. REPAIR_ALLOW_DATA_LOSS Questa sintassi ripara gli errori che si trovano nel database e può portare alla perdita di alcuni dati.
Nota: Questa sintassi è supportata da Microsoft e non sempre si rivela una soluzione ideale per trasformare il database in un buono stato fisico. Questo perché cancella l’intero dato che si trova corrotto e può portare a una perdita di dati maggiore di quella che è stata fatta originariamente al database, quindi dovrebbe essere adottata come ultima risorsa.
REPAIR_FAST Questo argomento mantiene solo la compatibilità all’indietro e non esegue alcuna riparazione. REPAIR REBUILD Questo argomento include un processo di riparazione più veloce che non comporta la minaccia di alcuna perdita di dati. ALL_ERRORMSGS Mostra tutti gli errori generati in tutti gli oggetti. Includere o escludere questa sintassi non avrà alcun effetto poiché i messaggi di errore sono solitamente ordinati in base all’ID dell’oggetto. Il numero massimo di messaggi di errore generati può arrivare fino a 1000. EXTENDED_LOGICAL_CHECKS Questo argomento esegue un controllo logico coerente su viste e indici, solo se il livello di compatibilità è 100. NO_INFOMSGS Rimuove tutti i messaggi informativi. TABLOCK Questa sintassi ottiene un blocco esclusivo sul database e aumenterà la velocità di DBCC CHECKDB su un database in momenti di forte carico. Ma diminuisce la disponibilità del database per operazioni concorrenti. ESTIMATEONLY Questo specifica o stima la quantità di spazio che il database richiederebbe per eseguire il comando CHECKDB. PHYSICAL_ONLY Questo pone una limitazione per controllare solo la struttura fisica del database. Un breve controllo del database fisico è accompagnato dal rilevamento di pagine strappate, guasti e problemi comuni affrontati dagli utenti. DATA PURITY Questa sintassi controlla i valori delle colonne che sono fuori portata o non sono validi. I controlli di integrità dei valori di colonna sono abilitati di default e non hanno bisogno della sintassi DATA_PURITY.
Cose da tenere a mente
- Gli indici disabilitati non possono essere controllati da DBCC CHECKDB.
- I tipi definiti dall’utente e ordinati per byte devono essere serializzati se DBCC CHECKDB deve essere eseguito. In ogni altro caso, si verifica l’errore 2537.
- DBCC CHECKDB non può essere eseguito direttamente sul database Resource poiché può essere modificato solo in modalità singola.
Messaggi di errore generati da DBCC CHECKDB
Quando il comando CHECKDB ha finito di essere eseguito, viene scritto un messaggio nel log degli errori SQL. In caso di successo, genera un messaggio che indica il successo e il tempo totale di esecuzione del comando. In caso di fallimento, il processo viene terminato a causa del verificarsi di qualche errore, come indicato da un messaggio. I vari valori di stato che rappresentano il messaggio di errore sono:
Rapporto di errore
Ogni volta che viene rilevata la corruzione dal comando CHECKDB, viene creato un file di dump chiamato SQLDUMPNNNN.txt nella directory dei log del server SQL. Nel caso in cui la raccolta dei dati d’uso e la segnalazione degli errori siano abilitate in SQL, il rapporto d’errore viene inviato a Microsoft per scopi di miglioramento.
Ripristino del database
Nello scenario di generazione degli errori nel server SQL, si raccomanda di ripristinare il database dall’ultimo backup creato invece di riparare il database.Nel caso in cui non esista un backup, si può andare per le opzioni di riparazione. Ma optare per la riparazione con REPAIR_ALLOW_DATA_LOSS può portare alla cancellazione di alcuni dati.
Risoluzione alternativa per il recupero del database
Fondamentalmente il comando DBCC CHECKDB controlla la consistenza del database, sia fisica che logica. Questo comando controlla le pagine, l’indice e alcuni altri componenti del database del server SQL, ma in alcuni punti critici questo opta per rifiutare di recuperare il database SQL. In caso di assenza di backup del database del server MS SQL, le opzioni di riparazione scelte possono eliminare una quantità apprezzabile di dati, quindi, al fine di recuperare il database senza compromettere l’integrità dei dati, è possibile optare per la soluzione di recupero del database Microsoft SQL. Garantiscono il recupero completo del database senza cancellare alcuna quantità di dati.