Database Console Command CHECKDB (DBCC CHECKDB)wordt gebruikt om de integriteit (fysiek & logisch) van objecten in een SQL Server database te controleren.Het commando wordt ondersteund in databases die geheugen-geoptimaliseerde tabellen bevatten, maar de validatie wordt alleen ondersteund in schijf-gebaseerde tabellen. De DBCC reparatie optie is niet beschikbaar in geheugen-geoptimaliseerde tabellen en daarom leidt tot de noodzaak van regelmatige database back-up.In het geval dat er een probleem ontstaat in een geheugen-geoptimaliseerde tabel, kunnen de gegevens worden hersteld vanaf de laatste back-up gedaan.
De verschillende bewerkingen die door CHECKDB worden uitgevoerd zijn:
- DBCC CHECKALLOC uitvoering op SQL database.
- DBCC CHECKTABLE uitvoering op elke tabel en view van SQL database.
- DBCC CHECKCATALOG uitvoering op SQL database.
- Validatie van de inhoud in de geïndexeerde view van de database.
- Validatie van consistentie op link-niveau tussen de bestandsdirectories en de tabelmetadata.
- Validatie van service broker-gegevens.
Omdat DBCC CHECKDB alle andere commando’s uitvoert, is het niet nodig om CHECKALLOC, CHECKTABLE en CHECKCATALOG commando’s afzonderlijk uit te voeren.
DBCC CHECKDB Syntax
De argumenten in de bovenstaande syntaxis betekenen het volgende:
database_name | database_id | 0 Dit is de naam van de database. Als de naam niet wordt aangegeven of als er alleen 0 wordt geschreven, wordt de huidige database gebruikt. NOINDEX Geeft aan dat de integriteitscontrole van niet-geclusterde indextabellen niet moet worden uitgevoerd. Deze syntaxis heeft geen invloed op de gegevens die zich in de tabellen bevinden. REPAIR_ALLOW_DATA_LOSS Deze syntaxis repareert de fouten die in de database worden gevonden. Dit kan leiden tot verlies van bepaalde gegevens.
Note: Deze syntax wordt ondersteund door Microsoft en blijkt niet iedere keer een ideale oplossing te zijn om de database in een goede fysieke staat te brengen. Dit komt omdat het de volledige gegevens verwijdert die corrupt blijken te zijn en kan leiden tot meer gegevensverlies, dan oorspronkelijk aan de database was gedaan. Daarom moet het worden aangenomen als een laatste redmiddel.
REPAIR_FAST Dit argument handhaaft alleen achterwaartse compatibiliteit en voert geen reparaties uit. REPAIR REBUILD Dit argument zorgt voor een sneller herstelproces, waarbij geen gevaar bestaat voor gegevensverlies. ALL_ERRORMSGS Dit toont alle fouten die gegenereerd zijn in alle objecten. Het in- of uitsluiten van deze syntaxis heeft geen effect omdat foutmeldingen gewoonlijk gesorteerd worden op object ID. Het maximum aantal foutmeldingen dat wordt gegenereerd kan oplopen tot 1000. EXTENDED_LOGICAL_CHECKS Dit argument voert een logische consistentiecontrole uit op views en indexen, alleen als het compatibiliteitsniveau 100 is. NO_INFOMSGS Hiermee worden alle informatieve berichten verwijderd. TABLOCK Deze syntaxis verkrijgt een exclusieve lock op de database en verhoogt de snelheid van DBCC CHECKDB op een database op momenten van zware belasting. Maar het vermindert de beschikbaarheid van de database voor gelijktijdige bewerkingen. ESTIMATEONLY Hiermee wordt de hoeveelheid ruimte opgegeven of geschat die de database nodig zou hebben om het CHECKDB-commando uit te voeren. PHYSICAL_ONLY Beperkt het controleren van alleen de fysieke structuur van de database. Een korte overheadcontrole van de fysieke database gaat gepaard met detectie van gescheurde pagina’s, storingen en veel voorkomende problemen van gebruikers. DATA PURITY Deze syntaxis controleert op kolomwaarden die buiten bereik zijn of niet geldig zijn. Integriteitscontroles van kolom-waarden zijn standaard ingeschakeld en hebben de DATA_PURITY syntaxis niet nodig.
Dingen om in gedachten te houden
- Uitgeschakelde indexen kunnen niet door DBCC CHECKDB worden gecontroleerd.
- De door de gebruiker gedefinieerde en byte-geordende typen moeten worden geserialiseerd als DBCC CHECKDB moet worden uitgevoerd. In elk ander geval treedt fout 2537 op.
- DBCC CHECKDB kan niet direct op Resource database worden uitgevoerd omdat deze alleen in single-mode kan worden gewijzigd.
Foutmeldingen gegenereerd door DBCC CHECKDB
Wanneer het CHECKDB commando klaar is met uitvoeren, wordt een bericht naar het SQL error log geschreven. In geval van succes wordt een bericht gegenereerd dat het succes aangeeft en de totale tijd gedurende welke het commando liep. In geval van mislukking wordt het proces beëindigd omdat er een fout optreedt, zoals aangegeven door een bericht. De verschillende toestandswaarden die de foutmelding weergeven, zijn:
Foutmelding
Wanneer door het CHECKDB-commando corruptie wordt gedetecteerd, wordt een dump-bestand met de naam SQLDUMPNNNN.txt aangemaakt in de log-directory van de SQL-server. In het geval dat de Feature Usage Data Collection en Error Reporting zijn ingeschakeld in SQL, wordt het foutenrapport naar Microsoft gestuurd voor verbeteringsdoeleinden.
Database Herstel
In het scenario van foutgeneratie in SQL server, is het aanbevolen om de database te herstellen vanaf de laatst gemaakte backup in plaats van de database te repareren.In het geval dat er geen backup bestaat, kunt u gaan voor reparatie opties. Maar kiezen voor reparatie met REPAIR_ALLOW_DATA_LOSS kan leiden tot het verwijderen van sommige gegevens.
Alternatieve Oplossing Voor Database Herstel
Basically de DBCC CHECKDB commando controleert de consistenties van de database, met inbegrip van fysieke of logische. Dit commando controleert de pagina’s, index en een aantal andere componenten van de SQL-server database, maar op sommige kritieke punten deze opt te weigeren om de SQL-database te herstellen. In het geval van afwezigheid van een back-up van MS SQL-server database, kan de gekozen reparatie opties verwijderen van een aanzienlijke hoeveelheid gegevens.Daarom, om de database te herstellen zonder afbreuk te doen aan de integriteit van de gegevens, kunt u kiezen voor Microsoft SQL database recovery-oplossing. Ze garanderen volledig herstel van de database zonder het verwijderen van een hoeveelheid gegevens.