DBCC CHECKDB è vitale per i database di SQL Server per essere sicuri al 100% che non vi sia corruzione. Tuttavia, a causa delle dimensioni dei database di dimensioni enormi, è molto difficile trovare una finestra di manutenzione quando si afferma di essere 24x7. Nel corso degli anni, il team di SQL Server ha implementato vari meccanismi che rileveranno le forme più comuni di corruzione, in particolare quelle correlate alla corruzione fisica causata dall'hardware.
SQL Server 2005 e versioni successive hanno PAGE_VERIFY = CHECKSUM che può aiutarti a rilevare in modo proattivo la corruzione fisica nelle pagine del database aggiungendo così un checksum a ciascuna pagina mentre viene scritto sul sistema I / O e convalida il checksum mentre viene letto dal disco.
Inoltre, il backup (completo o differenziale) con CHECKSUM garantirà il rilevamento di eventuali danni I / O causati dall'hardware.
Quindi, dal lato hardware della corruzione, SQL Server fa un buon lavoro nel rilevarlo e nel segnalarlo. (Assicurati di impostare anche importanti avvisi relativi alla corruzione ).
Detto questo, la corruzione ancora logica , lo scribbler ha causato errori - in cui le pagine in memoria sono danneggiate dal codice di terze parti in esecuzione all'interno del processo di SQL Server o da driver o altri software con privilegi sufficienti in esecuzione in modalità kernel di Windows e / o SQL Server Bug , ecc. Non sono rilevabili usando i metodi sopra e quindi CHECKDB appare in figura.
DBCC CHECKDB esegue controlli più approfonditi che includono il controllo delle intestazioni di pagina per possibili danni che non sono rilevabili con nessun altro mezzo.
Qualche script esistente là fuori?
Invece di reinventare la ruota, ti consiglio vivamente di dare un'occhiata alla soluzione di controllo dell'integrità di SQL Server di Ola
Esecuzione efficiente di DBCC CHECKDB:
Devi solo essere creativo quando sei stretto nella finestra di manutenzione con enormi database o un elevato numero di database su cui eseguire CHECKDB.
Dopo aver frequentato la formazione SQLSkills, ciò che ho implementato nel mio ambiente è:
- dare priorità a quali tabelle sono fondamentali per il controllo.
- separare le tabelle in gruppi con priorità diverse e quindi eseguire
DBCC CHECKTABLEinsieme a running DBCC CHECKALLOCeDBCC CHECKCATALOG
- Creare una tabella di lavoro che memorizzerà i nomi delle tabelle con priorità. Assicurati solo che tutte le tabelle con priorità elevate (che sono enormemente grandi) non appartengano a un gruppo altrimenti il tuo CHECKDB non verrà completato.
- Puoi anche avere una colonna di timeout nella tua tabella di lavoro che orchestrerà quando CHECKDB verrà ucciso una volta superata la finestra di manutenzione
- Aggiungi il tempo impiegato per ogni tabella a correre
DBCC CHECKTABLE, DBCC CHECKALLOCe DBCC CHECKCATALOG. In modo che tu possa avere un'idea di quanto tempo richiede solitamente l'esecuzione dei controlli.
- È anche possibile eseguire con l'
NOINDEXopzione in quanto accelererà l'operazione in quanto non controlla gli indici non cluster sulle tabelle utente. Ciò presenta alcuni vantaggi in quanto non è così critico come il danneggiamento dei dati poiché non vengono persi dati e, se necessario, è possibile eliminare e ricreare l'indice.
Ovviamente, l'edizione Enterprise può trarre vantaggio dall'esecuzione parallela delle istruzioni DBCC, ma cerca l'impostazione MAXDOP in quanto potrebbe finire per prendere tutta la tua CPU. Questo può essere fortemente limitato da Resource Governor.
Nota: se si dispone della colonna SPARSE, CHECKDB sarà molto lento come descritto qui .
Infine, è come prevenire la corruzione del database utilizzando tutto il set di strumenti disponibili + la tua fiducia nel sistema hardware del tuo server di database e, soprattutto, il valore dei tuoi dati.
Alcuni riferimenti eccellenti: