SQL Server DBCC CHECKDB Database Tool Hier leest u wanneer en hoe u de SQL Server DBCC CHECKDB Database Tool kunt gebruiken met de opties REPAIR_ALLOW_DATA_LOSS, REPAIR_REBUILD, TABLOCK, ESTIMATEONLY, PHYSICAL_ONLY en MAXDOP.
Hallo, mijn naam is Kirk. Ik ben een Senior Principal Engineer en werk samen met het GSE-team. In deze video bekijken we de Microsoft SQL Server TSQL-databasetool, DBCC CHECKDB. We bespreken waarom en wanneer DBCC CHECKDB moet worden uitgevoerd, samen met opdrachtopties die het niveau van databasecontrole en de betrokken runtime bepalen.
Voordat we aan de demo beginnen, zijn er een paar punten die we willen bespreken. DBCC CHECKDB is een TSQL-tool die kijkt naar de logische en fysieke integriteit van alle objecten binnen een bepaalde SQL Server-database. Er zijn enkele reparatieopties beschikbaar, en we hebben ook iets dat "TABLOCK" wordt genoemd als een optie die het gebruik of niet-gebruik van een snapshot van de database inhoudt. We gaan kijken naar de optie "ESTIMATEONLY", waarom we die zouden willen gebruiken, en dat is relatief ten opzichte van het gebruik van "TEMPDB" tijdens een CHECKDB-proces.
We gaan ook kijken naar "PHYSICAL_ONLY", waarom we die optie zouden willen gebruiken en wanneer. En we gaan ook kijken hoe we het aantal processors dat betrokken is bij het CHECKDB-proces kunnen controleren met iets dat "MAXDOP" wordt genoemd. Op dit punt gaan we dus kijken naar enkele voorbeelden van wat we zouden zien als we DBCC CHECKDB uitvoeren. Het eerste commando zelf controleert dus letterlijk alles wat DBCC CHECKDB kan bekijken binnen een bepaalde database.
Hier zijn de resultaten. De retourlijn waarin we het meest geïnteresseerd zijn wanneer we dit uitvoeren, is het aantal "toewijzingsfouten" en "consistentiefouten" dat in de database wordt gevonden. Ik heb dus een gezonde "AdventureWorks2019"-database, dus alles komt foutloos terug. Dit is ook een kleine database, dus dit werkt heel snel. Als we een veel grotere database hebben, een database die bijvoorbeeld 100 keer zo groot is als deze, duurt het veel langer om deze uit te voeren.
En veel mensen vragen zich af hoe vaak we moeten proberen DBCC CHECKDB uit te voeren, en meestal zullen de SQL-meesters je vertellen dat je het zo snel mogelijk wilt proberen. Als er inconsistenties of enige vorm van softwareschade in de database zijn, wilt u dat zo snel mogelijk ontdekken en oplossen. De volgende optie die we gaan bekijken is de optie genaamd "WITH PHYSICAL_ONLY".
Het is dezelfde opdracht, behalve dat het in dit geval letterlijk alleen de fysieke entiteit of de structuur van de database zelf controleert. Het zal meestal veel sneller werken dan een volledige controle, en daarom zouden we dit willen uitvoeren in productieomgevingen waar we beperkingen hebben op onze onderhoudstijden. We hebben ook een andere optie genaamd "WITH TABLOCK", dus een ding dat we moeten begrijpen over DBCC CHECKDB, een van de eerste dingen die het doet is het maken van een snapshotbestand dat is opgenomen in de "TEMPDB" database, en er zijn momenten waarop we misschien niet in staat zijn om "TEMPDB" te gebruiken voor zoiets met een CHECKDB proces.
Dus, wat we ook "WITH TABLOCK" noemen, we vertellen DBCC CHECKDB om geen snapshotbestand te maken, dus het zal die ruimte in "TEMPDB" niet innemen en het zal daardoor meestal sneller werken. Een van de andere dingen die we als optie kunnen uitvoeren, is "WITH ESTIMATEONLY". Deze specifieke opdracht zal ons vertellen hoeveel ruimte we zouden verwachten te hebben gebruikt in onze "TEMPDB"-database bij het uitvoeren van CHECKDB.
Hier is een voorbeeld van de uitvoer daarvan, het komt terug in kilobytes, dus dit is ongeveer 230 megabyte. Een andere optie die we hebben is "WITH MAXDOP". Wat DBCC CHECKDB ook uitvoert, het probeert zoveel processors te gebruiken als nodig is om parallel te werken. Het wil meerdere threads uitvoeren om te proberen zo snel mogelijk uit te voeren. Er kunnen dus beperkingen zijn met betrekking tot het aantal processors dat we in dit proces willen laten draaien, dus dat kunnen we beperken met de instructie "WITH MAXDOP".
In dit geval vertel ik SQL om slechts één processor te gebruiken voor onze CHECKDB-run. En als we dat doen, zijn er minder processors die hiervoor zijn bestemd, maar het duurt meestal langer om uw DBCC CHECKDB uit te voeren. Laten we nu eens kijken naar de reparatieopties. Er zijn verschillende reparatiemogelijkheden. De meest ingrijpende is wat we "REPAIR_ALLOW_DATA_LOSS" noemen. U kunt letterlijk gegevens verliezen wanneer we deze optie gebruiken om te proberen een database te repareren die terugkomt met fouten. Of we kunnen "REPAIR_REBUILD" gebruiken.
REPAIR_REBUILD wordt beschouwd als een zachte reparatieoptie, en wat we daarmee bedoelen is dat het garandeert dat we de beschikbare data in de database niet verliezen wanneer we dit uitvoeren. Bij de indeling van deze opdracht gebruiken we de context van de "Master"-database. Telkens wanneer we iets dergelijks doen, moeten we de database in de "SINGLE_USER"-modus zetten om een reparatiebewerking mogelijk te maken. Dus in dit geval zullen we dat uitvoeren.
Nu hebben we hier de optie van "ESTIMATEONLY", en nogmaals, de "ESTIMATEONLY" zal ons vertellen hoeveel ruimte we gaan opgeven in "TEMPDB" om dit te doen. Ons snapshotbestand zal ongeveer 230 megabyte in beslag nemen, op basis van ons rendement hier. En nadat we hiermee een reparatie hebben uitgevoerd, willen we hem weer in de "MULTI_USER"-modus zetten. Met "ESTIMATEONLY" hebben we de reparatie niet daadwerkelijk uitgevoerd, we hebben alleen de schatting gedaan. Laten we dus eens kijken hoe we de opdracht met de "REPAIR_REBUILD" uitvoeren.
Nogmaals, laten we dat gaan "uitvoeren", we gaan het terugzetten in "MULTI_USER". Dus nogmaals, in de context van de "Master"-database, zetten we deze in "SINGLE_USER"-modus. En in dit geval voeren we een reparatie uit. Dit is de zachte reparatieoperatie. En wat u gaat zien is veel van wat we zouden zien bij een normale DB-controle, en natuurlijk willen we nogmaals controleren op gerapporteerde fouten. In dit geval, nogmaals, zijn die er niet.
Ik heb hier een goede database. En het laatste deel van deze bewerking is het terugzetten in de "MULTI_USER"-modus. De reparatieopdracht "REPAIR_ALLOW_DATA_LOSS" is precies hetzelfde als de "REPAIR_REBUILD", behalve dat we de "REPAIR_ALLOW_DATA_LOSS" gebruiken. Meestal voeren we dit uit wanneer we hebben geprobeerd de "REPAIR_REBUILD" uit te voeren en de "REPAIR_REBUILD" terugkomt en ons vertelt dat het de reparatie van de database niet kon voltooien.
Dus ons laatste redmiddel zonder een goede back-up, en ja, we moeten een goede back-up gebruiken voordat we gedwongen worden om een "REPAIR_ALLOW_DATA_LOSS" te doen. Als er geen back-up bestaat, is dit onze enige optie om de database weer online en beschikbaar te krijgen. Dat is het einde van onze demo over het bespreken van DBCC CHECKDB, het overwegen van wanneer je CHECKDB moet gebruiken, en enkele van de meest voorkomende commando-opties die beschikbaar zijn. Ik hoop dat deze video u heeft geholpen de waarde in te zien van het gebruik van DBCC CHECKDB wanneer u probeert een consistente, stabiele SQL Server-database-installatie te onderhouden.
Bedankt voor uw aandacht.
