DBCC CHECKDB (Transact-SQL)

Artikel
03/05/2025

van toepassing op:SQL Server Azure SQL Database Azure SQL Managed Instance

Controleert de logische en fysieke integriteit van alle objecten in de opgegeven database door de volgende bewerkingen uit te voeren:

Hiermee wordt DBCC CHECKALLOC- op de database uitgevoerd.
Voert DBCC CHECKTABLE- uit voor elke tabel en weergave in de database.
Hiermee wordt DBCC CHECKCATALOG- op de database uitgevoerd.
Valideert de inhoud van elke geïndexeerde weergave in de database.
Valideert consistentie op koppelingsniveau tussen tabelmetagegevens en bestandssysteemmappen en bestanden bij het opslaan van varbinary(max) gegevens in het bestandssysteem met behulp van FILESTREAM.
Valideert de Service Broker-gegevens in de database.

Dit betekent dat de opdrachten DBCC CHECKALLOC, DBCC CHECKTABLEof DBCC CHECKCATALOG niet afzonderlijk van DBCC CHECKDBhoeven te worden uitgevoerd. Zie de beschrijvingen van deze opdrachten voor meer gedetailleerde informatie over de controles die door deze opdrachten worden uitgevoerd.

DBCC CHECKDB wordt ondersteund op databases die tabellen bevatten die zijn geoptimaliseerd voor geheugen, maar validatie vindt alleen plaats op tabellen op basis van schijven. Als onderdeel van databaseback-up en herstel wordt echter een CHECKSUM-validatie uitgevoerd voor bestanden in voor geheugen geoptimaliseerde bestandsgroepen.

Omdat DBCC-herstelopties niet beschikbaar zijn voor tabellen die zijn geoptimaliseerd voor geheugen, moet u regelmatig een back-up van uw databases maken en de back-ups testen. Als er problemen met gegevensintegriteit optreden in een tabel die is geoptimaliseerd voor geheugen, moet u herstellen vanaf de laatst bekende goede back-up.

Transact-SQL syntaxisconventies

Syntaxis

DBCC CHECKDB
    [ [ ( database_name | database_id | 0
        [ , NOINDEX
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
    ) ]
    [ WITH
        {
            [ ALL_ERRORMSGS ]
            [ , EXTENDED_LOGICAL_CHECKS ]
            [ , NO_INFOMSGS ]
            [ , TABLOCK ]
            [ , ESTIMATEONLY ]
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]
            [ , MAXDOP = number_of_processors ]
        }
    ]
]

Argumenten

database_name | database_id | 0

De naam of id van de database waarvoor integriteitscontroles moeten worden uitgevoerd. Als dit niet is opgegeven of als 0 is opgegeven, wordt de huidige database gebruikt. Databasenamen moeten voldoen aan de regels voor id's.

NOINDEX

Hiermee geeft u op dat intensieve controles van niet-geclusterde indexen voor gebruikerstabellen niet worden uitgevoerd. Deze keuze vermindert de totale uitvoeringstijd. NOINDEX heeft geen invloed op systeemtabellen omdat integriteitscontroles altijd worden uitgevoerd op systeemtabelindexen.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Hiermee geeft u op dat DBCC CHECKDB de gevonden fouten herstelt. Gebruik de REPAIR_*-opties alleen als laatste redmiddel. De opgegeven database moet zich in de modus voor één gebruiker bevinden om een van de volgende herstelopties te kunnen gebruiken.

REPAIR_ALLOW_DATA_LOSS

Probeert alle gerapporteerde fouten te herstellen. Deze reparaties kunnen leiden tot gegevensverlies.

Waarschuwing

De optie REPAIR_ALLOW_DATA_LOSS kan leiden tot meer gegevensverlies dan als u herstelt vanuit een laatst bekende goede back-up. Zie waarschuwing voor gegevensverlies met REPAIR_ALLOW_DATA_LOSS

Microsoft raadt een gebruiker altijd aan om te herstellen vanaf de laatst bekende goede back-up als primaire methode om te herstellen van fouten die zijn gerapporteerd door DBCC CHECKDB. De optie REPAIR_ALLOW_DATA_LOSS is geen alternatief voor het herstellen van een bekende goede back-up. Het is een laatste redmiddel optie die alleen wordt aanbevolen voor gebruik als herstellen vanuit een back-up niet mogelijk is.

Bepaalde fouten, die alleen kunnen worden hersteld met behulp van de optie REPAIR_ALLOW_DATA_LOSS, kunnen betrekking hebben op het toewijzen van een rij, pagina of reeks pagina's om de fouten te wissen. Eventuele niet-toegewezen gegevens zijn niet meer toegankelijk of herstelbaar voor de gebruiker en de exacte inhoud van de niet-toegewezen gegevens kan niet worden bepaald. Daarom is referentiële integriteit mogelijk niet nauwkeurig nadat rijen of pagina's zijn toegewezen omdat beperkingen voor refererende sleutels niet worden gecontroleerd of onderhouden als onderdeel van deze herstelbewerking. De gebruiker moet de referentiële integriteit van de database controleren (met behulp van DBCC CHECKCONSTRAINTS) na het gebruik van de optie REPAIR_ALLOW_DATA_LOSS.

Voordat u de reparatie uitvoert, moet u fysieke kopieën maken van de bestanden die deel uitmaken van deze database. Dit omvat het primaire gegevensbestand (.mdf), alle secundaire gegevensbestanden (.ndf), alle transactielogboekbestanden (.ldf) en andere containers die de database vormen, inclusief volledige-tekstcatalogussen, bestandsstroommappen, geoptimaliseerde gegevens voor geheugen, enzovoort.

Voordat u de herstelbewerking uitvoert, kunt u overwegen de status van de database te wijzigen in EMERGENCY modus en zoveel mogelijk informatie uit de kritieke tabellen te extraheren en die gegevens op te slaan.
REPAIR_FAST

Onderhoudt alleen de syntaxis voor compatibiliteit met eerdere versies. Er worden geen herstelacties uitgevoerd.
REPAIR_REBUILD

Voert reparaties uit die geen kans hebben op gegevensverlies. Deze optie kan snelle reparaties omvatten, zoals het herstellen van ontbrekende rijen in niet-geclusterde indexen en meer tijdrovende reparaties, zoals het opnieuw opbouwen van een index.

Dit argument herstelt geen fouten met betrekking tot FILESTREAM-gegevens.

Belangrijk

Omdat DBCC CHECKDB met een van de REPAIR_* opties volledig zijn geregistreerd en hersteld, raadt Microsoft een gebruiker altijd aan DBCC CHECKDB te gebruiken met REPAIR_* opties binnen een transactie (voer BEGIN TRANSACTION uit voordat de opdracht wordt uitgevoerd), zodat de gebruiker kan bevestigen dat hij de resultaten van de bewerking wil accepteren. Vervolgens kan de gebruiker COMMIT TRANSACTION uitvoeren om alle werkzaamheden die door de reparatiebewerking worden uitgevoerd, door te voeren. Als de gebruiker de resultaten van de bewerking niet wil accepteren, kan deze een ROLLBACK TRANSACTION uitvoeren om de gevolgen van de herstelbewerkingen ongedaan te maken.

Als u fouten wilt herstellen, raden we u aan om te herstellen vanuit een back-up. Herstelbewerkingen houden niet rekening met een van de beperkingen die mogelijk bestaan in of tussen tabellen. Als de opgegeven tabel betrokken is bij een of meer beperkingen, raden we u aan DBCC CHECKCONSTRAINTS uit te voeren na een herstelbewerking. Als u REPAIR_*moet gebruiken, voert u DBCC CHECKDB uit zonder een reparatieoptie om het herstelniveau te vinden dat u wilt gebruiken. Als u het REPAIR_ALLOW_DATA_LOSS niveau gebruikt, wordt u aangeraden een back-up van de database te maken voordat u DBCC CHECKDB uitvoert met deze optie.

ALL_ERRORMSGS

Geeft alle gerapporteerde fouten per object weer. Alle foutberichten worden standaard weergegeven. Het opgeven of weglaten van deze optie heeft geen effect. Foutberichten worden gesorteerd op object-id, met uitzondering van berichten die zijn gegenereerd op basis van tempdb-database.

EXTENDED_LOGICAL_CHECKS

Als het compatibiliteitsniveau 100 is, geïntroduceerd in SQL Server 2008 (10.0.x), voert deze optie logische consistentiecontroles uit op een geïndexeerde weergave, XML-indexen en ruimtelijke indexen, waar aanwezig.

Zie Logische consistentiecontroles uitvoeren op indexen verderop in dit artikel voor meer informatie.

NO_INFOMSGS

Onderdrukt alle informatieve berichten.

TABLOCK

Zorgt ervoor dat DBCC CHECKDB vergrendelingen krijgt in plaats van een momentopname van een interne database te gebruiken. Dit omvat een exclusieve (X)-vergrendeling op de korte termijn voor de database. TABLOCK zorgt ervoor dat DBCC CHECKDB sneller wordt uitgevoerd op een database onder zware belasting, maar vermindert de gelijktijdigheid die beschikbaar is voor de database terwijl DBCC CHECKDB wordt uitgevoerd.

Belangrijk

TABLOCK beperkt de controles die worden uitgevoerd; DBCC CHECKCATALOG niet wordt uitgevoerd op de database en Service Broker-gegevens niet worden gevalideerd.

SCHATTING

Geeft de geschatte hoeveelheid tempdb ruimte weer die nodig is om DBCC CHECKDB uit te voeren met alle andere opgegeven opties. De werkelijke databasecontrole wordt niet uitgevoerd.

PHYSICAL_ONLY

Hiermee wordt de controle beperkt tot de integriteit van de fysieke structuur van de pagina en recordheaders en de toewijzingsconsistentie van de database. Deze controle is ontworpen om een kleine overheadcontrole te bieden van de fysieke consistentie van de database, maar kan ook gescheurde pagina's, controlesomfouten en veelvoorkomende hardwarefouten detecteren die de gegevens van een gebruiker kunnen in gevaar brengen.

Een volledige uitvoering van DBCC CHECKDB kan aanzienlijk langer duren dan eerdere versies. Dit gedrag treedt op omdat:

De logische controles zijn uitgebreider.
Sommige onderliggende structuren die moeten worden gecontroleerd, zijn complexer.
Er zijn veel nieuwe controles geïntroduceerd om de nieuwe functies op te nemen.

Daarom kan het gebruik van de optie PHYSICAL_ONLY een veel kortere runtime voor DBCC CHECKDB op grote databases veroorzaken en wordt aanbevolen voor frequent gebruik op productiesystemen. We raden nog steeds aan om een volledige uitvoering van DBCC CHECKDB periodiek uit te voeren. De frequentie van deze uitvoeringen is afhankelijk van factoren die specifiek zijn voor individuele bedrijven en productieomgevingen.

Dit argument impliceert altijd NO_INFOMSGS en is niet toegestaan met een van de reparatieopties.

Waarschuwing

Als u PHYSICAL_ONLY opgeeft, worden DBCC CHECKDB alle controles van FILESTREAM-gegevens overgeslagen.

DATA_PURITY

Zorgt ervoor dat DBCC CHECKDB de database controleert op kolomwaarden die niet geldig of buiten het bereik vallen. DBCC CHECKDB detecteert bijvoorbeeld kolommen met datum- en tijdwaarden die groter zijn dan of kleiner zijn dan het acceptabele bereik voor het datum/tijd- gegevenstype; of decimale of bij benadering numerieke gegevenstypekolommen met schaal- of precisiewaarden die niet geldig zijn.

Integriteitscontroles voor kolomwaarden zijn standaard ingeschakeld en vereisen geen DATA_PURITY optie. Voor databases die zijn bijgewerkt vanuit eerdere versies van SQL Server, worden kolomwaardecontroles niet standaard ingeschakeld totdat DBCC CHECKDB WITH DATA_PURITY foutloos is uitgevoerd op de database. Hierna controleert DBCC CHECKDB standaard de integriteit van kolomwaarden. Zie de sectie Opmerkingen verderop in dit artikel voor meer informatie over hoe CHECKDB mogelijk worden beïnvloed door een upgrade van de database uit eerdere versies van SQL Server.

Waarschuwing

Als PHYSICAL_ONLY is opgegeven, worden er geen controles voor kolomintegriteit uitgevoerd.

Validatiefouten die door deze optie worden gerapporteerd, kunnen niet worden opgelost met behulp van DBCC-herstelopties. Zie MSSQLSERVER_2570voor informatie over het handmatig corrigeren van deze fouten.

MAXDOP

Van toepassing op: SQL Server 2014 (12.x) Service Pack 2 en latere versies

Overschrijft de max degree of parallelism configuratieoptie van sp_configure voor de instructie. De MAXDOP kan de waarde overschrijden die is geconfigureerd met sp_configure. Als MAXDOP de waarde overschrijdt die is geconfigureerd met Resource Governor, gebruikt de SQL Server Database Engine de MAXDOP-waarde van Resource Governor, zoals beschreven in ALTER WORKLOAD GROUP. Alle semantische regels die worden gebruikt met de configuratieoptie max degree of parallelism zijn van toepassing wanneer u de MAXDOP queryhint gebruikt. Zie Serverconfiguratie: maximale mate van parallelle uitvoeringvoor meer informatie.

Waarschuwing

Als MAXDOP is ingesteld op nul, kiest SQL Server de max degree of parallelism die u wilt gebruiken.

Opmerkingen

DBCC CHECKDB onderzoekt uitgeschakelde indexen niet. Zie Indexen en beperkingen uitschakelenvoor meer informatie over uitgeschakelde indexen.

Als een door de gebruiker gedefinieerd type is gemarkeerd als byte geordende, mag er slechts één serialisatie van het door de gebruiker gedefinieerde type zijn. Als u geen consistente serialisatie hebt van door de gebruiker geordende door de gebruiker geordende typen, wordt fout 2537 veroorzaakt wanneer DBCC CHECKDB wordt uitgevoerd. Zie User-Defined typen maken - Vereistenvoor meer informatie.

Omdat de resourcedatabase alleen kan worden gewijzigd in de modus voor één gebruiker, kan de opdracht DBCC CHECKDB niet rechtstreeks op de database worden uitgevoerd. Wanneer DBCC CHECKDB echter wordt uitgevoerd op de hoofddatabase, wordt er ook intern een tweede CHECKDB uitgevoerd op de resourcedatabase. Dit betekent dat DBCC CHECKDB extra resultaten kan retourneren. De opdracht retourneert extra resultatensets wanneer er geen opties zijn ingesteld of wanneer de optie PHYSICAL_ONLY of ESTIMATEONLY is ingesteld.

In SQL Server 2005 (9.x) Service Pack 2 en nieuwere versies wordt de plancache voor het exemplaar van SQL Server niet meer gewist door het uitvoeren van DBCC CHECKDB. Voordat SQL Server 2005 (9.x) Service Pack 2 wordt uitgevoerd, wordt DBCC CHECKDB de plancache gewist. Als u de plancache wist, worden alle latere uitvoeringsplannen opnieuw gecompileren en kan dit leiden tot een plotselinge, tijdelijke afname van de queryprestaties.

Logische consistentiecontroles uitvoeren op indexen

De logische consistentiecontrole op indexen varieert als volgt volgens het compatibiliteitsniveau van de database:

Als het compatibiliteitsniveau ten minste 100 is (geïntroduceerd in SQL Server 2008 (10.0.x)):
Tenzij NOINDEX is opgegeven, voert DBCC CHECKDB zowel fysieke als logische consistentiecontroles uit op één tabel en op alle niet-geclusterde indexen. Bij XML-indexen, ruimtelijke indexen en geïndexeerde weergaven worden echter standaard alleen fysieke consistentiecontroles uitgevoerd.
Als WITH EXTENDED_LOGICAL_CHECKS is opgegeven, worden logische controles uitgevoerd in een geïndexeerde weergave, XML-indexen en ruimtelijke indexen, waar aanwezig. Fysieke consistentiecontroles worden standaard uitgevoerd vóór de logische consistentiecontroles. Als NOINDEX ook is opgegeven, worden alleen de logische controles uitgevoerd.

Deze logische consistentie controleert kruislings de interne indextabel van het indexobject met de gebruikerstabel waarnaar wordt verwezen. Om te achterhalen welke rijen er zijn, wordt een interne query samengesteld om een volledig snijpunt van de interne en gebruikerstabellen uit te voeren. Het uitvoeren van deze query kan een aanzienlijk effect hebben op de prestaties en de voortgang ervan kan niet worden bijgehouden. Daarom raden we u aan WITH EXTENDED_LOGICAL_CHECKS alleen op te geven als u indexproblemen vermoedt die niet gerelateerd zijn aan fysieke beschadiging, of als controlesommen op paginaniveau zijn uitgeschakeld en u vermoedt dat hardwarebeschadiging op kolomniveau is beschadigd.

Als de index een gefilterde index is, voert DBCC CHECKDB consistentiecontroles uit om te controleren of de indexvermeldingen voldoen aan het filterpredicaat.
Als het compatibiliteitsniveau 90 of minder is, tenzij NOINDEX is opgegeven, voert DBCC CHECKDB zowel fysieke als logische consistentiecontroles uit op één tabel of geïndexeerde weergave en op alle niet-geclusterde en XML-indexen. Ruimtelijke indexen worden niet ondersteund.
In SQL Server 2016 (13.x) en latere versies worden extra controles uitgevoerd op persistente berekende kolommen, UDT-kolommen en gefilterde indexen niet standaard om dure expressie-evaluaties te voorkomen. Deze wijziging vermindert de duur van CHECKDB aanzienlijk ten opzichte van databases die deze objecten bevatten. De fysieke consistentiecontrole van deze objecten wordt echter altijd voltooid. Alleen wanneer EXTENDED_LOGICAL_CHECKS optie is opgegeven, worden de expressie-evaluaties uitgevoerd, naast de logische controles die al aanwezig zijn als onderdeel van de optie EXTENDED_LOGICAL_CHECKS (geïndexeerde weergave, XML-indexen en ruimtelijke indexen).

Meer informatie over het compatibiliteitsniveau van een database

het compatibiliteitsniveau van een database weergeven of wijzigen

Momentopname van interne database

DBCC CHECKDB maakt gebruik van een momentopname van een interne database voor de transactionele consistentie die nodig is om deze controles uit te voeren. Dit voorkomt blokkerings- en gelijktijdigheidsproblemen wanneer deze opdrachten worden uitgevoerd. Zie De grootte van het Sparse-bestand van een momentopname van een database weergeven en het gedeelte databasemomentopname van dbcc sectie in DBCC-voor meer informatie. Als er geen momentopname kan worden gemaakt of TABLOCK is opgegeven, verkrijgt DBCC CHECKDB vergrendelingen om de vereiste consistentie te verkrijgen. In dit geval is een exclusieve databasevergrendeling vereist om de toewijzingscontroles uit te voeren en zijn gedeelde tabelvergrendelingen vereist om de tabelcontroles uit te voeren.

DBCC CHECKDB mislukt wanneer deze wordt uitgevoerd op de master-database als er geen momentopname van een interne database kan worden gemaakt.

Als u DBCC CHECKDB uitvoert op tempdb geen toewijzings- of cataloguscontroles uitvoert, moet u gedeelde tabelvergrendelingen verkrijgen om tabelcontroles uit te voeren. Dit komt omdat databasemomentopnamen om prestatieredenen niet beschikbaar zijn op tempdb. Dit betekent dat de vereiste transactionele consistentie niet kan worden verkregen.

Hoe DBCC CHECKDB een interne momentopnamedatabase maakt die begint met SQL Server 2014

DBCC CHECKDB maakt een interne momentopnamedatabase.
De interne momentopnamedatabase wordt gemaakt met behulp van fysieke bestanden. Bijvoorbeeld voor een database met database_id = 10 met drie bestanden E:\Data\my_DB.mdf, E:\Data\my_DB.ndfen E:\Data\my_DB.ldf, wordt de interne momentopnamedatabase gemaakt met behulp van E:\Data\my_DB.mdf_MSSQL_DBCC11- en E:\Data\my_DB.ndf_MSSQL_DBCC11-bestanden. De database_id van de momentopname is database_id + 1. Houd er ook rekening mee dat de nieuwe bestanden in dezelfde map worden gemaakt met behulp van de naamconventie <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>. Er wordt geen sparse-bestand gemaakt voor het transactielogboek.
De nieuwe bestanden worden gemarkeerd als sparsebestanden op bestandssysteemniveau. De grootte op schijf die door de nieuwe bestanden worden gebruikt, neemt toe op basis van hoeveel gegevens in de brondatabase worden bijgewerkt tijdens de opdracht DBCC CHECKDB. De grootte van de nieuwe bestanden is hetzelfde bestand als het .mdf- of .ndf-bestand.
De nieuwe bestanden worden aan het einde van DBCC CHECKDB verwerking verwijderd. Deze parseringsbestanden die door DBCC CHECKDB zijn gemaakt, hebben de kenmerken 'Verwijderen bij sluiten' ingesteld.

Waarschuwing

Als het besturingssysteem onverwacht wordt afgesloten terwijl de opdracht DBCC CHECKDB wordt uitgevoerd, worden deze bestanden niet opgeschoond. Ze nemen ruimte in beslag en kunnen fouten veroorzaken bij toekomstige DBCC CHECKDB uitvoeringen. In dat geval kunt u deze nieuwe bestanden verwijderen nadat u hebt bevestigd dat er geen DBCC CHECKDB opdracht wordt uitgevoerd.

De nieuwe bestanden zijn zichtbaar met behulp van gewone bestandshulpprogramma's zoals Windows Verkenner.

Notitie

Vóór SQL Server 2014 (12.x), met de naam bestandsstromen werden gebruikt om de interne momentopnamebestanden te maken. De benoemde bestandsstromen hebben de indeling <bestandsnaam.extension>:MSSQL_DBCC<database_id_of_snapshot>gebruikt. Benoemde bestandsstromen zijn niet zichtbaar met behulp van gewone bestandshulpprogramma's zoals Windows Verkenner. Daarom kunnen in SQL Server 2012 (11.x) en eerdere versies foutberichten 7926 en 5030 optreden wanneer u de opdracht DBCC CHECKDB uitvoert voor databasebestanden op een ReFS--geformatteerd volume. Dit komt doordat bestandsstromen niet kunnen worden gemaakt op Resilient File System (RefS).

FILESTREAM-gegevens controleren en herstellen

Wanneer FILESTREAM is ingeschakeld voor een database en tabel, kunt u desgewenst varbinary(max) binaire grote objecten (BLOBs) opslaan in het bestandssysteem. Wanneer u DBCC CHECKDB gebruikt in een database waarin BLOBs in het bestandssysteem worden opgeslagen, controleert DBCC de consistentie op koppelingsniveau tussen het bestandssysteem en de database.

Als een tabel bijvoorbeeld een varbinary(max) kolom bevat die gebruikmaakt van het kenmerk FILESTREAM, controleert DBCC CHECKDB of er een-op-een-toewijzing is tussen bestandssysteemmappen en bestanden en tabelrijen, kolommen en kolomwaarden. DBCC CHECKDB kan beschadiging herstellen als u de optie REPAIR_ALLOW_DATA_LOSS opgeeft. Als u FILESTREAM-beschadiging wilt herstellen, verwijdert DBCC alle tabelrijen die ontbrekende bestandssysteemgegevens bevatten.

Aanbevolen procedures

U wordt aangeraden de optie PHYSICAL_ONLY te gebruiken voor frequent gebruik op productiesystemen. Het gebruik van PHYSICAL_ONLY kan de runtime aanzienlijk verkorten voor DBCC CHECKDB op grote databases. U wordt ook aangeraden regelmatig DBCC CHECKDB zonder opties uit te voeren. Hoe vaak u deze uitvoeringen moet uitvoeren, is afhankelijk van individuele bedrijven en hun productieomgevingen.

In Azure SQL Managed Instance moet de beschikbare opslagruimte geschikt zijn voor het volledige momentopnamebestand van de interne database dat is gemaakt door DBCC CHECKDB, ongeacht hoeveel er daadwerkelijk door gegevens wordt gebruikt. Dit kan leiden tot een situatie waarbij het uitvoeren van DBCC CHECKDB op een zeer grote maar parserende database (de grootte van de gegevens veel kleiner is dan de grootte van de databasebestand) mislukt vanwege onvoldoende ruimte in uw beheerde SQL-exemplaar. Als DBCC CHECKDB tijdens de uitvoering alle beschikbare opslagruimte verbruikt, wordt het volgende foutbericht weergegeven:

Msg 1133, Level 16, State 3, Line 1
The managed instance has reached its storage limit. To storage usage for the managed instance cannot exceed (...) MBs.
You might need to temporarily scale up your SQL managed instance storage capacity before running `DBCC CHECKDB` again.

Objecten parallel controleren

Standaard voert DBCC CHECKDB parallelle controle van objecten uit. De mate van parallelle uitvoering wordt automatisch bepaald door de queryprocessor. De maximale mate van parallelle uitvoering wordt net als parallelle query's geconfigureerd. Gebruik sp_configureom het maximum aantal processors te beperken dat beschikbaar is voor DBCC-controles. Zie Serverconfiguratie: maximale mate van parallelle uitvoeringvoor meer informatie. Parallelle controle kan worden uitgeschakeld met traceringsvlag 2528. Zie traceringsvlagmenvoor meer informatie.

Notitie

Deze functie is niet beschikbaar in elke editie van SQL Server. Zie de parallelle consistentiecontrole in de sectie RDBMS-beheerbaarheid van Edities en ondersteunde functies van SQL Server 2022voor meer informatie.

DBCC-foutberichten begrijpen

Nadat de opdracht DBCC CHECKDB is voltooid, wordt er een bericht naar het SQL Server-foutenlogboek geschreven. Als de DBCC-opdracht is uitgevoerd, geeft het bericht aan dat de opdracht is geslaagd en hoe lang de opdracht is uitgevoerd. Als de DBCC-opdracht stopt voordat de controle wordt voltooid vanwege een fout, geeft het bericht aan dat de opdracht is beëindigd, een statuswaarde en de hoeveelheid tijd die de opdracht heeft uitgevoerd. In de volgende tabel worden de statuswaarden vermeld en beschreven die in het bericht kunnen worden opgenomen.

Staat	Beschrijving
`0`	Foutnummer 8930 is gegenereerd. Dit geeft een beschadiging aan in metagegevens die de DBCC-opdracht hebben beëindigd.
`1`	Foutnummer 8967 is gegenereerd. Er is een interne DBCC-fout opgetreden.
`2`	Er is een fout opgetreden tijdens het herstellen van de database in de noodmodus.
`3`	Dit geeft een beschadiging aan in metagegevens die de DBCC-opdracht hebben beëindigd.
`4`	Er is een schending van assert of toegang gedetecteerd.
`5`	Er is een onbekende fout opgetreden die de DBCC-opdracht heeft beëindigd.

SQL Server registreert de datum en tijd waarop een consistentiecontrole is uitgevoerd voor een database zonder fouten (of 'schone' consistentiecontrole). Dit staat bekend als de last known clean check. Wanneer een database voor het eerst wordt gestart, wordt deze datum naar het EventLog geschreven (EventID-17573) en wordt het foutenlogboek in de volgende indeling weergegeven:

CHECKDB for database '<database>' finished without errors on 2022-05-05 18:08:22.803 (local time). This is an informational message only; no user action is required.

Foutrapportage

Er wordt een stackdump (SQLDump<nnnn>.txt, SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp) gemaakt in de map SQL Server LOG wanneer DBCC CHECKDB een beschadigingsfout detecteert. Wanneer het functiegebruik gegevensverzameling en functies voor fout rapportage zijn ingeschakeld voor het exemplaar van SQL Server, wordt het bestand automatisch doorgestuurd naar Microsoft. De verzamelde gegevens worden gebruikt om de functionaliteit van SQL Server te verbeteren. Het dumpbestand bevat de resultaten van de opdracht DBCC CHECKDB en aanvullende diagnostische uitvoer. Toegang is beperkt tot het SQL Server-serviceaccount en leden van de rol sysadmin. De rol sysadmin bevat standaard alle leden van de Windows BUILTIN\Administrators-groep en de lokale beheerdersgroep. De DBCC-opdracht mislukt niet als het proces voor het verzamelen van gegevens mislukt.

Fouten oplossen

Als er fouten worden gerapporteerd door DBCC CHECKDB, raden we u aan om de database te herstellen vanuit de databaseback-up in plaats van DBCC CHECKDB uit te voeren met een van de REPAIR_* opties. Als er geen back-up bestaat, corrigeert het uitvoeren van herstel de gemelde fouten. De hersteloptie die u wilt gebruiken, wordt opgegeven aan het einde van de lijst met gerapporteerde fouten. Als u de fouten echter corrigeert met behulp van de optie REPAIR_ALLOW_DATA_LOSS, moet u mogelijk bepaalde pagina's en daarom bepaalde gegevens verwijderen.

In sommige gevallen kunnen waarden worden ingevoerd in de database die niet geldig of buiten het bereik vallen op basis van het gegevenstype van de kolom. DBCC CHECKDB kunt kolomwaarden detecteren die niet geldig zijn voor alle kolomgegevenstypen. Daarom kan het uitvoeren van DBCC CHECKDB met de optie DATA_PURITY op databases die zijn bijgewerkt vanuit eerdere versies van SQL Server, fouten met de bestaande kolomwaarde opleveren. Omdat SQL Server deze fouten niet automatisch kan herstellen, moet de kolomwaarde handmatig worden bijgewerkt. Als CHECKDB een dergelijke fout detecteert, retourneert CHECKDB een waarschuwing, het foutnummer 2570 en informatie om de betreffende rij te identificeren en de fout handmatig te corrigeren.

Het herstel kan worden uitgevoerd onder een gebruikerstransactie, zodat de gebruiker de wijzigingen die zijn aangebracht, kan terugdraaien. Als reparaties worden teruggedraaid, bevat de database nog steeds fouten en moet deze worden hersteld vanuit een back-up. Nadat de reparaties zijn voltooid, maakt u een back-up van de database.

Fouten in de databasemodus voor noodgevallen oplossen

Wanneer een database is ingesteld op de noodmodus met behulp van de instructie ALTER DATABASE, kan DBCC CHECKDB een aantal speciale reparaties uitvoeren op de database als de REPAIR_ALLOW_DATA_LOSS optie is opgegeven. Door deze reparaties kunnen databases normaal gesproken onherstelbaar weer online worden gebracht in een fysiek consistente status. Deze reparaties moeten als laatste redmiddel worden gebruikt en alleen wanneer u de database niet vanuit een back-up kunt herstellen. Wanneer de database is ingesteld op de noodmodus, wordt de database gemarkeerd als READ_ONLY, wordt logboekregistratie uitgeschakeld en is de toegang beperkt tot leden van de sysadmin vaste serverfunctie.

Notitie

U kunt de opdracht DBCC CHECKDB niet uitvoeren in de noodmodus binnen een gebruikerstransactie en de transactie terugdraaien na uitvoering.

Wanneer de database zich in de noodmodus bevindt en DBCC CHECKDB met de REPAIR_ALLOW_DATA_LOSS component wordt uitgevoerd, worden de volgende acties uitgevoerd:

DBCC CHECKDB maakt gebruik van pagina's die vanwege I/O- of controlesomfouten zijn gemarkeerd als gevolg van I/O-fouten, alsof de fouten niet zijn opgetreden. Hierdoor vergroot u de kans op gegevensherstel vanuit de database.
DBCC CHECKDB probeert de database te herstellen met behulp van normale hersteltechnieken op basis van logboeken.
Als het herstel van de database mislukt vanwege beschadiging van het transactielogboek, wordt het transactielogboek opnieuw opgebouwd. Het opnieuw opbouwen van het transactielogboek kan leiden tot verlies van transactionele consistentie.

Waarschuwing

De optie REPAIR_ALLOW_DATA_LOSS kan leiden tot meer gegevensverlies dan als u herstelt vanuit een laatst bekende goede back-up. Zie waarschuwing voor gegevensverlies met REPAIR_ALLOW_DATA_LOSS

Als de opdracht DBCC CHECKDB slaagt, heeft de database een fysiek consistente status en is de databasestatus ingesteld op ONLINE. De database kan echter een of meer transactionele inconsistenties bevatten. We raden u aan DBCC CHECKCONSTRAINTS- uit te voeren om eventuele fouten in bedrijfslogica te identificeren en onmiddellijk een back-up van de database te maken.

Als de opdracht DBCC CHECKDB mislukt, kan de database niet worden hersteld.

Waarschuwing voor gegevensverlies met REPAIR_ALLOW_DATA_LOSS

De optie REPAIR_ALLOW_DATA_LOSS is een ondersteunde functie van SQL Server. Het is echter mogelijk niet altijd de beste optie voor het overbrengen van een database naar een fysiek consistente status. Als dit lukt, kan de optie REPAIR_ALLOW_DATA_LOSS leiden tot gegevensverlies.

Het kan zelfs leiden tot meer gegevens die verloren gaan dan als een gebruiker de database terugzet vanaf de laatst bekende goede back-up. Microsoft raadt een gebruiker altijd aan om te herstellen vanaf de laatst bekende goede back-up als primaire methode om te herstellen van fouten die zijn gerapporteerd door DBCC CHECKDB.

De optie REPAIR_ALLOW_DATA_LOSS is geen alternatief voor het herstellen van een bekende goede back-up. Het is een laatste redmiddel optie wordt alleen aanbevolen voor gebruik als herstellen vanuit een back-up is niet mogelijk.

Nadat het logboek opnieuw is opgebouwd, is er geen volledige ACID-garantie.

Nadat het logboek opnieuw is opgebouwd, wordt DBCC CHECKDB automatisch uitgevoerd en worden zowel rapporten als fysieke consistentieproblemen gecorrigeerd.

Logische gegevensconsistentie en afgedwongen bedrijfslogica moeten handmatig worden gevalideerd.

De grootte van het transactielogboek wordt overgelaten aan de standaardgrootte en moet handmatig worden aangepast aan de recente grootte.

DBCC CHECKDB uitvoeren met REPAIR_ALLOW_DATA_LOSS in gerepliceerde databases

Het uitvoeren van de opdracht DBCC CHECKDB met de optie REPAIR_ALLOW_DATA_LOSS kan van invloed zijn op gebruikersdatabases (publicatie- en abonnementsdatabases) en de distributiedatabase die wordt gebruikt door replicatie. Publicatie- en abonnementsdatabases bevatten gepubliceerde tabellen en replicatiemetagegevenstabellen. Houd rekening met de volgende mogelijke problemen in deze databases:

Gepubliceerde tabellen. Acties die door het CHECKDB proces worden uitgevoerd om beschadigde gebruikersgegevens te herstellen, worden mogelijk niet gerepliceerd:
Samenvoegreplicatie maakt gebruik van triggers om wijzigingen in gepubliceerde tabellen bij te houden. Als rijen worden ingevoegd, bijgewerkt of verwijderd door het CHECKDB proces, worden triggers niet geactiveerd; daarom wordt de wijziging niet gerepliceerd.
Transactionele replicatie maakt gebruik van het transactielogboek om wijzigingen in gepubliceerde tabellen bij te houden. De logboeklezeragent verplaatst deze wijzigingen vervolgens naar de distributiedatabase. Sommige DBCC-reparaties, hoewel vastgelegd, kunnen niet worden gerepliceerd door de logboeklezeragent. Als de toewijzing van een gegevenspagina bijvoorbeeld ongedaan wordt gemaakt door het CHECKDB proces, vertaalt de logboeklezeragent deze toewijzing niet naar een DELETE-instructie; daarom wordt de wijziging niet gerepliceerd.
Replicatiemetagegevenstabellen. Acties die door het CHECKDB proces worden uitgevoerd om beschadigde replicatiemetagegevenstabellen te herstellen, moeten replicatie worden verwijderd en opnieuw geconfigureerd.

Als u de opdracht DBCC CHECKDB moet uitvoeren met de optie REPAIR_ALLOW_DATA_LOSS op een gebruikersdatabase of distributiedatabase:

Het systeem stilzetten: stop de activiteit op de database en alle andere databases in de replicatietopologie en probeer vervolgens alle knooppunten te synchroniseren. Zie een replicatietopologie (Replicatie Transact-SQL programmeren)voor meer informatie.
Voer DBCC CHECKDBuit.
Als het rapport DBCC CHECKDB reparaties bevat voor tabellen in de distributiedatabase of replicatiemetagegevenstabellen in een gebruikersdatabase, verwijdert en configureert u de replicatie opnieuw. Zie Publicatie- en distributie-uitschakelen voor meer informatie.
Als het DBCC CHECKDB rapport reparaties voor gerepliceerde tabellen bevat, voert u gegevensvalidatie uit om te bepalen of er verschillen zijn tussen de gegevens in de publicatie- en abonnementsdatabases.

Resultatenset

DBCC CHECKDB retourneert de volgende resultatenset. De waarden kunnen variëren, behalve wanneer de ESTIMATEONLY, PHYSICAL_ONLYof NO_INFOMSGS opties zijn opgegeven:

DBCC results for 'model'.
Service Broker Msg 9675, Level 10, State 1: Message Types analyzed: 13.
Service Broker Msg 9676, Level 10, State 1: Service Contracts analyzed: 5.
Service Broker Msg 9667, Level 10, State 1: Services analyzed: 3.
Service Broker Msg 9668, Level 10, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, Level 10, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, Level 10, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, Level 10, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.
There are 630 rows in 7 pages for object 'sys.sysrowsetcolumns'.

DBCC results for 'sys.sysrowsets'.
There are 97 rows in 1 pages for object 'sys.sysrowsets'.

DBCC results for 'sysallocunits'.
There are 195 rows in 3 pages for object 'sysallocunits'.
There are 0 rows in 0 pages for object "sys.sysasymkeys".

DBCC results for 'sys.syssqlguides'.
There are 0 rows in 0 pages for object "sys.syssqlguides".

DBCC results for 'sys.queue_messages_1977058079'.
There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".

DBCC results for 'sys.queue_messages_2009058193'.
There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".

DBCC results for 'sys.queue_messages_2041058307'.
There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".

CHECKDB found 0 allocation errors and 0 consistency errors in database 'model'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB retourneert de volgende resultatenset (bericht) wanneer NO_INFOMSGS is opgegeven:

The command(s) completed successfully.

DBCC CHECKDB retourneert de volgende resultatenset wanneer PHYSICAL_ONLY is opgegeven:

DBCC results for 'model'.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'master'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKDB retourneert de volgende resultatenset wanneer ESTIMATEONLY is opgegeven.

Estimated TEMPDB space needed for CHECKALLOC (KB)
-------------------------------------------------
13

(1 row(s) affected)

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
57

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Machtigingen

Vereist lidmaatschap van de sysadmin vaste serverfunctie of de db_owner vaste databaserol.

Voorbeelden

Een. Zowel de huidige als een andere database controleren

In het volgende voorbeeld wordt DBCC CHECKDB uitgevoerd voor de huidige database en voor de AdventureWorks2022-database.

-- Check the current database.
DBCC CHECKDB;
GO

-- Check the AdventureWorks2022 database without nonclustered indexes.
DBCC CHECKDB (AdventureWorks2022, NOINDEX);
GO

B. Controleer de huidige database en onderdrukt informatieve berichten

In het volgende voorbeeld wordt de huidige database gecontroleerd en worden alle informatieve berichten onderdrukt.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Delen via

DBCC CHECKDB (Transact-SQL)

Syntaxis

Argumenten

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

SCHATTING

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Opmerkingen

Logische consistentiecontroles uitvoeren op indexen

Meer informatie over het compatibiliteitsniveau van een database

Momentopname van interne database

Hoe DBCC CHECKDB een interne momentopnamedatabase maakt die begint met SQL Server 2014

FILESTREAM-gegevens controleren en herstellen

Aanbevolen procedures

Objecten parallel controleren

DBCC-foutberichten begrijpen

Foutrapportage

Fouten oplossen

Fouten in de databasemodus voor noodgevallen oplossen

Waarschuwing voor gegevensverlies met REPAIR_ALLOW_DATA_LOSS

DBCC CHECKDB uitvoeren met REPAIR_ALLOW_DATA_LOSS in gerepliceerde databases

Resultatenset

Machtigingen

Voorbeelden

Een. Zowel de huidige als een andere database controleren

B. Controleer de huidige database en onderdrukt informatieve berichten

Feedback

Aanvullende resources

Delen via

DBCC CHECKDB (Transact-SQL)

Syntaxis

Argumenten

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

SCHATTING

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Opmerkingen

Logische consistentiecontroles uitvoeren op indexen

Meer informatie over het compatibiliteitsniveau van een database

Momentopname van interne database

Hoe DBCC CHECKDB een interne momentopnamedatabase maakt die begint met SQL Server 2014

FILESTREAM-gegevens controleren en herstellen

Aanbevolen procedures

Objecten parallel controleren

DBCC-foutberichten begrijpen

Foutrapportage

Fouten oplossen

Fouten in de databasemodus voor noodgevallen oplossen

Waarschuwing voor gegevensverlies met REPAIR_ALLOW_DATA_LOSS

DBCC CHECKDB uitvoeren met REPAIR_ALLOW_DATA_LOSS in gerepliceerde databases

Resultatenset

Machtigingen

Voorbeelden

Een. Zowel de huidige als een andere database controleren

B. Controleer de huidige database en onderdrukt informatieve berichten

Verwante inhoud

Feedback

Aanvullende resources