Salve, io sono Kirk. Sono Senior Principal Engineer e lavoro con il Team GSE. Questo video è dedicato all'analisi dello strumento di database TSQL di Microsoft SQL Server, DBCC CHECKDB. Verranno illustrati perché e quando eseguire DBCC CHECKDB, insieme alle opzioni di comando che determinano il livello di controllo e runtime del database coinvolti.
Ecco alcuni punti di cui discutere prima di avviare la demo. DBCC CHECKDB è uno strumento TSQL che esamina l'integrità logica e fisica di tutti gli oggetti all'interno di un determinato database SQL Server. Sono disponibili anche alcune opzioni di riparazione, denominata "TABLOCK", che prevede l'utilizzo o meno di un'istantanea del database. Esamineremo l'opzione "ESTIMATEONLY" e il motivo per cui dovremmo utilizzarla, e questo è relativo all'utilizzo di "TEMPDB" durante un processo CHECKDB.
Inoltre, esamineremo "PHYSICAL_ONLY", perché dovremmo utilizzare questa opzione e quando. Vedremo anche come possiamo controllare il numero di processori coinvolti nel processo CHECKDB con qualcosa chiamato "MAXDOP". A questo punto esamineremo alcuni esempi di ciò che vedremmo quando eseguiamo DBCC CHECKDB. Quindi, il primo comando controllerà letteralmente tutto ciò che è possibile che DBCC CHECKDB possa esaminare all'interno di un determinato database.
Ecco i risultati. La riga di ritorno che ci interessa di più quando lo eseguiamo è il numero di "errori di allocazione" ed "errori di coerenza" trovati nel database. Quindi, ho un database "AdventureWorks2019" integro, quindi tutto viene restituito senza errori. Ora, in questo caso il database è di piccole dimensioni, e viene eseguito tutto molto rapidamente. Se abbiamo un database molto più grande, ad esempio un database 100 volte più grande di questo, ci vorrà molto più tempo per eseguirlo.
Inoltre, molte persone si chiedono con quale frequenza dovremmo provare a eseguire DBCC CHECKDB e di solito i master SQL ti diranno che vuoi provare a eseguirlo il prima possibile. Se ci sono incongruenze o qualsiasi tipo di danno software nel database, vuoi scoprirlo il più rapidamente possibile e risolverlo. Quindi, la prossima opzione che esamineremo è quella denominata "WITH PHYSICAL_ONLY".
È lo stesso comando, tranne per il fatto che, in questo caso, si tratta letteralmente solo di controllare l'entità fisica o la struttura del database stesso. Di solito viene eseguito molto più velocemente di un controllo completo, ed è per questo motivo che vorremmo eseguire questa operazione in ambienti di produzione in cui abbiamo limitazioni sui nostri tempi di manutenzione. Abbiamo anche un'altra opzione chiamata "WITH TABLOCK", quindi una cosa che dobbiamo capire su DBCC CHECKDB, una delle prime cose che fa è creare un file di istantanea contenuto nel database "TEMPDB" e ci sono momenti in cui potremmo non essere in grado di usare "TEMPDB" per qualcosa del genere con un processo CHECKDB.
Indipendentemente da ciò che designiamo come "WITH TABLOCK", stiamo dicendo a DBCC CHECKDB di non creare un file di snapshot, quindi non occuperà quello spazio in "TEMPDB" e di solito verrà eseguito più velocemente di conseguenza. Un'altra opzione che possiamo eseguire è "WITH ESTIMATEONLY". Questo particolare comando indica la quantità di spazio che ci aspetteremo di aver utilizzato all'interno del database "TEMPDB" durante l'esecuzione di CHECKDB.
Ecco un esempio dell'output, restituito in kilobyte, circa 230 megabyte. Un'altra opzione è "WITH MAXDOP". Ora, qualunque sia l'esecuzione di DBCC CHECKDB, tenta di utilizzare tutti i processori necessari per l'esecuzione in parallelo. Desidera eseguire più thread per tentare di eseguire il più rapidamente possibile. Pertanto, potrebbero esserci limitazioni al numero di processori che vogliamo consentire l'esecuzione in questo processo, quindi possiamo limitarlo con l'istruzione "WITH MAXDOP".
In questo caso, sto dicendo a SQL di utilizzare un solo processore per l'esecuzione di CHECKDB. In questo caso, il numero di processori dedicati a questa operazione è inferiore, ma di solito l'esecuzione di DBCC CHECKDB richiede più tempo. Esaminiamo ora le opzioni di riparazione. Esistono quindi diverse opzioni di riparazione. L'opzione più drastica è quella che chiamiamo "REPAIR_ALLOW_DATA_LOSS". Potresti letteralmente perdere dati ogni volta che usiamo questa opzione per provare a riparare un database che sta tornando con errori. Oppure, potremmo utilizzare l'opzione "REPAIR_REBUILD".
REPAIR_REBUILD tratta di un'opzione di riparazione flessibile e con ciò intendiamo che garantisce che non perderemo i dati disponibili nel database durante l'esecuzione. Quindi, nel modo in cui questo comando è strutturato, utilizzeremo il contesto del database "Master". Ogni volta che facciamo qualcosa di simile, dobbiamo mettere il database in modalità "SINGLE_USER" per consentire un'operazione di riparazione. In questo caso allora lo eseguiremo.
Qui è disponibile l'opzione "ESTIMATEONLY" e, ancora una volta, "ESTIMATEONLY" indica la quantità di spazio a disposizione in "TEMPDB" per eseguire questa operazione. Il nostro file di istantanea occuperà circa 230 megabyte, in base al nostro ritorno qui. E dopo aver eseguito una riparazione con questo, vorremmo rimetterlo in modalità "MULTI_USER". Ora, con "ESTIMATEONLY" non abbiamo effettivamente eseguito la riparazione, abbiamo fatto solo la stima. Vediamo come eseguire il comando con il tasto "REPAIR_REBUILD".
Ancora una volta, eseguiamo "Execute" e lo reinseriamo in "MULTI_USER". Quindi, ancora una volta, nel contesto del database "Master", lo imposteremo in modalità "SINGLE_USER". In questo caso, eseguiremo un'operazione di riparazione. Si tratta dell'operazione di riparazione assistita. E quello che vedrete è molto di ciò che vedremmo in un normale controllo del DB e, naturalmente, ancora una volta, vogliamo verificare la presenza di errori segnalati. In questo caso, ancora una volta, non ci sono errori.
Quindi vuol dire che ho un database in buone condizioni. L'ultima parte dell'operazione consiste nel riportarlo in modalità "MULTI_USER". Il comando di riparazione "REPAIR_ALLOW_DATA_LOSS" è esattamente come il comando "REPAIR_REBUILD", tranne per il fatto che viene utilizzato il comando "REPAIR_ALLOW_DATA_LOSS". In genere, lo eseguiamo quando abbiamo tentato di eseguire "REPAIR_REBUILD" e il "REPAIR_REBUILD" ci dice che non è stato possibile completare la riparazione del database.
Quindi, la nostra ultima risorsa senza un buon backup, e sì, dovremmo usare un buon backup prima di essere costretti a fare un "REPAIR_ALLOW_DATA_LOSS". Se non esiste alcun backup, questa è l'unica opzione per riportare il database online e disponibile. Con questo si conclude la demo in cui si discute di DBCC CHECKDB, considerando quando utilizzare CHECKDB e alcune delle opzioni di comando più comuni disponibili. Spero che questo video abbia aiutato a comprendere il valore dell'utilizzo di DBCC CHECKDB quando si tenta di mantenere un'installazione coerente e stabile del database SQL Server.
Grazie per l'attenzione.
