DBCC CHECKDB (Transact-SQL)

• 12/14/2017
• 22 minuten om te lezen
• • p
  • M
  • m
  • M
  • P
  • +3

Geldt voor: SQL Server (alle ondersteunde versies) Azure SQL Database

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

• Uitvoeren van DBCC CHECKALLOC op de database.
• Loopt DBCC CHECKTABLE op elke tabel en view in de database.
• Loopt DBCC CHECKCATALOG op de database.
• Valideert de inhoud van elke geïndexeerde view in de database.
• Valideert de consistentie op linkniveau tussen tabelmetagegevens en bestandssysteemdirectory’s en -bestanden wanneer varbinary(max)-gegevens in het bestandssysteem worden opgeslagen met FILESTREAM.
• Valideert de Service Broker-gegevens in de database.

Dit betekent dat de DBCC CHECKALLOC-, DBCC CHECKTABLE- of DBCC CHECKCATALOG-opdrachten niet afzonderlijk van DBCC CHECKDB hoeven te worden uitgevoerd. Zie de beschrijvingen van deze opdrachten voor meer gedetailleerde informatie over de controles die deze opdrachten uitvoeren.

Transact-SQL Syntaxconventies

Syntax

DBCC CHECKDB ) ] } ] ] 

Arguments

database_name | database_id | 0
Is de naam of ID van de database waarvoor integriteitscontroles moeten worden uitgevoerd. Indien niet opgegeven, of indien 0 is opgegeven, wordt de huidige database gebruikt. Databasenamen moeten voldoen aan de regels voor identifiers.

NOINDEX
Specificeert dat intensieve controles van niet-geclusterde indexen voor gebruikerstabellen niet moeten worden uitgevoerd. Dit verlaagt de totale uitvoeringstijd. NOINDEX heeft geen invloed op systeemtabellen omdat integriteitscontroles altijd worden uitgevoerd op systeemtabelindexen.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD
Specifieert dat DBCC CHECKDB de gevonden fouten repareert. Gebruik de REPAIR-opties alleen als laatste redmiddel. De opgegeven database moet in single-user mode staan om een van de volgende reparatieopties te kunnen gebruiken.

REPAIR_ALLOW_DATA_LOSS
Probeert alle gemelde fouten te repareren. Deze reparaties kunnen enig gegevensverlies veroorzaken.

REPAIR_FAST
Behoudt de syntax alleen voor achterwaartse compatibiliteit. Er worden geen herstelacties uitgevoerd.

REPAIR_REBUILD
Voer reparaties uit die geen mogelijkheid tot gegevensverlies bieden. Dit kunnen snelle reparaties zijn, zoals het repareren van ontbrekende rijen in niet-geclusterde indexen, en meer tijdrovende reparaties, zoals het opnieuw opbouwen van een index.
Dit argument repareert geen fouten waarbij FILESTREAM-gegevens zijn betrokken.

ALL_ERRORMSGS
Weergave van alle gerapporteerde fouten per object. Standaard worden alle foutmeldingen weergegeven. Het opgeven of weglaten van deze optie heeft geen effect. Foutmeldingen worden gesorteerd op object ID, behalve voor de meldingen die gegenereerd worden vanuit de tempdb database.

EXTENDED_LOGICAL_CHECKS
Als het compatibiliteitsniveau 100 (SQL Server 2008) of hoger is, worden logische consistentiecontroles uitgevoerd op een geïndexeerde view, XML-indexen en ruimtelijke indexen, indien aanwezig.
Voor meer informatie, zie Logische consistentiecontroles uitvoeren op indexen, in het gedeelte Opmerkingen verderop in dit onderwerp.

NO_INFOMSGS
onderdrukt alle informatieve berichten.

TABLOCK
Geeft DBCC CHECKDB opdracht om vergrendelingen te verkrijgen in plaats van een interne databasesnapshot te gebruiken. Dit omvat een kortetermijn-exclusief (X) slot op de database. TABLOCK zorgt ervoor dat DBCC CHECKDB sneller wordt uitgevoerd op een database die zwaar wordt belast, maar vermindert de beschikbare gelijktijdigheid in de database terwijl DBCC CHECKDB wordt uitgevoerd.

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

PHYSICAL_ONLY
Limiteert de controle 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 van de fysieke consistentie van de database te bieden, maar kan ook gescheurde pagina’s, checksumfouten en veelvoorkomende hardwarefouten detecteren die de gegevens van een gebruiker in gevaar kunnen brengen.
Het kan aanzienlijk langer duren om een volledige uitvoering van DBCC CHECKDB te voltooien dan bij eerdere versies. Dit gedrag treedt op omdat:

• De logische controles uitgebreider zijn.
• Sommige van de te controleren onderliggende structuren complexer zijn.
• Er veel nieuwe controles zijn geïntroduceerd om de nieuwe functies op te nemen.
  Het gebruik van de optie PHYSICAL_ONLY kan daarom leiden tot een veel kortere doorlooptijd voor DBCC CHECKDB op grote databases en wordt aanbevolen voor frequent gebruik op productiesystemen. Wij raden nog steeds aan om DBCC CHECKDB periodiek volledig uit te voeren. De frequentie van deze runs hangt af van factoren die specifiek zijn voor individuele bedrijven en productieomgevingen.
  Dit argument impliceert altijd NO_INFOMSGS en is niet toegestaan met een van de herstelopties.

DATA_PURITY
Zorgt ervoor dat DBCC CHECKDB de database controleert op kolomwaarden die niet geldig zijn of buiten het bereik vallen. DBCC CHECKDB detecteert bijvoorbeeld kolommen met datum- en tijdwaarden die groter of kleiner zijn dan het aanvaardbare bereik voor het gegevenstype datetime; of kolommen van het type decimale of benaderend-numerieke gegevens met schaal- of precisiewaarden die niet geldig zijn.
De integriteitscontroles van kolommen zijn standaard ingeschakeld en vereisen de optie DATA_PURITY niet. Voor databases die zijn opgewaardeerd vanuit eerdere versies van SQL Server, worden kolom-waardecontroles niet standaard ingeschakeld totdat DBCC CHECKDB WITH DATA_PURITY foutloos op de database is uitgevoerd. Daarna controleert DBCC CHECKDB standaard de integriteit van kolomwaarden. Zie het gedeelte Opmerkingen verderop in dit onderwerp voor meer informatie over hoe CHECKDB kan worden beïnvloed door het upgraden van databases van eerdere versies van SQL Server.

Validatiefouten die door deze optie worden gerapporteerd, kunnen niet worden hersteld met behulp van DBCC-reparatieopties. Zie Knowledge Base-artikel 923247 voor informatie over het handmatig corrigeren van deze fouten: DBCC-fout 2570 oplossen in SQL Server 2005 en latere versies.

MAXDOP
Geldt voor: SQL Server ( SQL Server 2014 (12.x) SP2 en later).

Overrides the max degree of parallelism configuration option of sp_configure for the statement. MAXDOP kan groter zijn dan de waarde die is geconfigureerd met sp_configure. Als MAXDOP hoger is dan de waarde 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. Voor meer informatie, zie Configureer de max graad van parallellisme Server Configuratie Optie.

Opmerkingen

DBCC CHECKDB onderzoekt geen uitgeschakelde indexen. Voor meer informatie over uitgeschakelde indexen, zie Uitgeschakelde indexen en restricties.

Als een door de gebruiker gedefinieerd type is gemarkeerd als zijnde byte-geordend, mag er slechts één serialisatie van het door de gebruiker gedefinieerde type zijn. Het ontbreken van een consistente serialisatie van byte-geordende door de gebruiker gedefinieerde typen veroorzaakt fout 2537 wanneer DBCC CHECKDB wordt uitgevoerd. Zie voor meer informatie Vereisten voor door de gebruiker gedefinieerde typen.

Omdat de Resource-database alleen in de modus voor één gebruiker kan worden gewijzigd, kan het DBCC CHECKDB-commando er niet rechtstreeks op worden uitgevoerd. Wanneer DBCC CHECKDB echter wordt uitgevoerd tegen de hoofddatabase, wordt intern ook een tweede CHECKDB uitgevoerd op de resource-database. Dit betekent dat DBCC CHECKDB extra resultaten kan retourneren. Het commando retourneert extra resultaatreeksen wanneer geen opties zijn ingesteld, of wanneer de optie PHYSICAL_ONLY of ESTIMATEONLY is ingesteld.

Met ingang van SQL Server 2005 (9.x) SP2 wist het uitvoeren van DBCC CHECKDB niet langer de plan-cache voor de instantie van SQL Server. Vóór SQL Server 2005 (9.x) SP2 werd de plan cache wel gewist door het uitvoeren van DBCC CHECKDB. Het wissen van de plan cache veroorzaakt een hercompilatie van alle latere uitvoeringsplannen en kan een plotselinge, tijdelijke vermindering van de query-prestaties veroorzaken.

Het uitvoeren van logische consistentiecontroles op indexen

Logische consistentiecontroles op indexen zijn afhankelijk van het compatibiliteitsniveau van de database, en wel als volgt:

• Als het compatibiliteitsniveau 100 (SQL Server 2008) of hoger is:
• Of NOINDEX is gespecificeerd, voert DBCC CHECKDB zowel fysieke als logische consistentiecontroles uit op een enkele tabel en op alle niet-geclusterde indexen daarvan. Op 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 op een geïndexeerde weergave, XML-indexen en ruimtelijke indexen, indien aanwezig. Standaard worden fysieke consistentiecontroles uitgevoerd vóór de logische consistentiecontroles. Als NOINDEX ook is opgegeven, worden alleen de logische controles uitgevoerd.

Deze logische consistentiecontroles controleren de interne indextabel van het indexobject kruiselings met de gebruikerstabel waarnaar wordt verwezen. Om afwijkende rijen te vinden, wordt een interne query geconstrueerd om een volledige intersectie van de interne en gebruikerstabellen uit te voeren. Het uitvoeren van deze query kan een zeer groot effect hebben op de performance, en de voortgang kan niet worden bijgehouden. Daarom wordt aanbevolen WITH EXTENDED_LOGICAL_CHECKS alleen te specificeren als u indexproblemen vermoedt die geen verband houden met fysieke corruptie, of als controlesommen op paginaniveau zijn uitgeschakeld en u corruptie op kolomniveau vermoedt.

• Als de index een gefilterde index is, voert DBCC CHECKDB consistentiecontroles uit om te controleren of de indexingangen voldoen aan het filterpredicaat.
• Als het compatibiliteitsniveau 90 of lager is, tenzij NOINDEX is gespecificeerd, voert DBCC CHECKDB zowel fysieke als logische consistentiecontroles uit op een enkele tabel of geïndexeerde view en op alle niet-geclusterde en XML-indexen daarvan. Ruimtelijke indexen worden niet ondersteund.
• Met ingang van SQL Server 2016 worden extra controles op persisted computed columns, UDT-kolommen en gefilterde indexen standaard niet uitgevoerd om de dure expressie-evaluaties te vermijden. Deze wijziging verkort de duur van CHECKDB tegen databases die deze objecten bevatten aanzienlijk. De fysieke consistentiecontroles van deze objecten worden echter altijd uitgevoerd. Alleen wanneer de EXTENDED_LOGICAL_CHECKS optie is gespecificeerd zullen de expressie evaluaties worden uitgevoerd in aanvulling op de reeds aanwezige logische controles (geïndexeerde view, XML indexen, en ruimtelijke indexen) als onderdeel van de EXTENDED_LOGICAL_CHECKS optie.

Om het compatibiliteitsniveau van een database te weten te komen

• Bekijk of wijzig het compatibiliteitsniveau van een database

Internal Database Snapshot

DBCC CHECKDB gebruikt een interne databasesnapshot voor de transactieconsistentie die nodig is om deze controles uit te voeren. Dit voorkomt blocking en concurrency problemen wanneer deze commando’s worden uitgevoerd. Zie voor meer informatie De grootte van het sparse-bestand van een databasesnapshot weergeven (Transact-SQL) en de sectie DBCC Interne databasesnapshot gebruiken in DBCC (Transact-SQL). Als een momentopname niet kan worden gemaakt, of als TABLOCK is gespecificeerd, verwerft DBCC CHECKDB vergrendelingen om de vereiste consistentie te verkrijgen. In dit geval is een exclusieve databaseslot nodig om de toewijzingscontroles uit te voeren en zijn gedeelde tabellensloten nodig om de tabelcontroles uit te voeren.DBCC CHECKDB mislukt wanneer het tegen master wordt uitgevoerd als er geen interne databasesnapshot kan worden gemaakt.DBCC CHECKDB uitvoeren tegen tempdb voert geen toewijzings- of cataloguscontroles uit en moet gedeelde tabellensloten verwerven om tabelcontroles uit te voeren. Dit komt omdat, om performance redenen, database snapshots niet beschikbaar zijn op tempdb. Dit betekent dat de vereiste transactionele consistentie niet kan worden verkregen.In Microsoft SQL Server 2012 of een eerdere versie van SQL Server kunt u foutberichten tegenkomen wanneer u de opdracht DBCC CHECKDB uitvoert voor een database waarvan de bestanden zich op een ReFS-geformatteerd volume bevinden. Zie voor meer informatie Knowledge Base-artikel 2974455: DBCC CHECKDB-gedrag wanneer de SQL Server-database zich op een ReFS-volume bevindt.

FILESTREAM-gegevens controleren en repareren

Wanneer FILESTREAM is ingeschakeld voor een database en tabel, kunt u optioneel varbinary(max) binary large objects (BLOB’s) opslaan in het bestandssysteem. Wanneer u DBCC CHECKDB gebruikt op een database die BLOB’s opslaat in het bestandssysteem, controleert DBCC de consistentie op linkniveau tussen het bestandssysteem en de database. Als een tabel bijvoorbeeld een varbinary(max)-kolom bevat die het kenmerk FILESTREAM gebruikt, controleert DBCC CHECKDB of er een-op-een-afstemming is tussen directory’s en bestanden op het bestandssysteem en tabelrijen, -kolommen en -kolomwaarden. DBCC CHECKDB kan corruptie repareren als u de optie REPAIR_ALLOW_DATA_LOSS opgeeft. Om FILESTREAM-corruptie te repareren, verwijdert DBCC tabelrijen die bestandssysteemgegevens missen.

Best Practices

Wij raden u aan de optie PHYSICAL_ONLY te gebruiken voor veelvuldig gebruik op productiesystemen. Het gebruik van PHYSICAL_ONLY kan de run-time voor DBCC CHECKDB op grote databases aanzienlijk verkorten. Wij raden u ook aan om DBCC CHECKDB regelmatig zonder opties uit te voeren. Hoe vaak u deze runs moet uitvoeren, hangt af van individuele bedrijven en hun productie-omgevingen.

Dobjecten parallel controleren

Bestandaard voert DBCC CHECKDB parallelle controles van objecten uit. De mate van parallellisme wordt automatisch bepaald door de query processor. De maximale graad van parallellisme wordt net als bij parallelle queries geconfigureerd. Om het maximum aantal processors dat beschikbaar is voor DBCC-controle te beperken, gebruikt u sp_configure. Voor meer informatie, zie Configureer de max. graad van parallellisme Server Configuratie Optie. Parallelle controle kan worden uitgeschakeld door traceervlag 2528 te gebruiken. Voor meer informatie, zie Trace Flags (Transact-SQL).

Inzicht in DBCC-foutberichten

Nadat het DBCC CHECKDB-commando is voltooid, wordt een bericht naar het SQL Server-foutlogboek geschreven. Als het DBCC commando succesvol wordt uitgevoerd, geeft het bericht het succes aan en de tijd dat het commando liep. Als de DBCC-opdracht stopt voordat de controle is voltooid vanwege een fout, geeft het bericht aan dat de opdracht is beëindigd, een statuswaarde en de duur van de opdracht. In de volgende tabel worden de statuswaarden opgesomd en beschreven die in het bericht kunnen worden opgenomen.

State	Description
0	Er is foutnummer 8930 opgetreden. Dit wijst op een corruptie in de metadata die het DBCC-commando heeft beëindigd.
1	Error number 8967 was raised. Er was een interne DBCC-fout.
2	Er is een fout opgetreden tijdens het repareren van de database in de noodmodus.
3	Dit duidt op een corruptie in de metadata die het DBCC-commando heeft beëindigd.
4	Er is een assert of access violation gedetecteerd.
5	Er is een onbekende fout opgetreden die het DBCC-commando heeft beëindigd.

Error Reporting

Er wordt een dump-bestand (SQLDUMP*nnnn*.txt) gemaakt in de SQL Server LOG-directory wanneer DBCC CHECKDB een corruptiefout detecteert. Wanneer de functies Feature Usage data collection en Error Reporting zijn ingeschakeld voor de instantie van SQL Server, wordt het bestand automatisch doorgestuurd naar Microsoft. De verzamelde gegevens worden gebruikt om de SQL Server-functionaliteit te verbeteren. Het dump-bestand bevat de resultaten van het DBCC CHECKDB-commando en aanvullende diagnostische uitvoer. Toegang is beperkt tot de SQL Server service account en leden van de sysadmin rol. Standaard bevat de sysadmin-rol alle leden van de Windows BUILTIN\Administrators-groep en de groep van de lokale beheerder. De DBCC-opdracht mislukt niet als het gegevensverzamelingsproces mislukt.

Fouten oplossen

Als DBCC CHECKDB fouten rapporteert, raden wij aan de database te herstellen vanaf de databaseback-up in plaats van REPAIR uit te voeren met een van de REPAIR-opties. Als er geen backup bestaat, corrigeert het uitvoeren van repair de gerapporteerde fouten. De te gebruiken reparatie-optie wordt gespecificeerd aan het einde van de lijst met gerapporteerde fouten. Het corrigeren van de fouten met de optie REPAIR_ALLOW_DATA_LOSS kan echter betekenen dat sommige pagina’s, en dus sommige gegevens, moeten worden verwijderd.

Onder bepaalde omstandigheden kunnen waarden in de database worden ingevoerd die niet geldig zijn of buiten het bereik vallen op basis van het gegevenstype van de kolom. DBCC CHECKDB kan kolomwaarden detecteren die niet geldig zijn voor alle kolomdatatypen. Daarom kan het uitvoeren van DBCC CHECKDB met de optie DATA_PURITY op databases die zijn opgewaardeerd vanuit eerdere versies van SQL Server, reeds bestaande fouten in kolomwaarden aan het licht brengen. 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 getroffen rij te identificeren en de fout handmatig te corrigeren.

De reparatie kan worden uitgevoerd onder een gebruikerstransactie om de gebruiker de aangebrachte wijzigingen te laten terugdraaien. Als reparaties worden teruggerold, bevat de database nog steeds fouten en moet deze worden hersteld vanaf een back-up. Maak een back-up van de database nadat de reparaties zijn voltooid.

Fouten oplossen in de noodmodus van de database

Wanneer een database in de noodmodus is gezet met het ALTER DATABASE statement, kan DBCC CHECKDB een aantal speciale reparaties op de database uitvoeren als de REPAIR_ALLOW_DATA_LOSS optie is opgegeven. Deze reparaties kunnen ervoor zorgen dat databases die normaal gesproken niet hersteld kunnen worden, weer online kunnen worden gebracht in een fysiek consistente staat. Deze reparaties moeten als laatste redmiddel worden gebruikt en alleen als u de database niet vanaf een back-up kunt herstellen. Wanneer de database in de noodmodus is gezet, is de database gemarkeerd als READ_ONLY, is logging uitgeschakeld en is de toegang beperkt tot leden van de vaste serverrol sysadmin.

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

• DBCC CHECKDB gebruikt pagina’s die als ontoegankelijk zijn gemarkeerd vanwege I/O- of checksum-fouten, alsof de fouten niet zijn opgetreden. Dit vergroot de kans op herstel van gegevens uit de database.
• DBCC CHECKDB probeert de database te herstellen met behulp van reguliere, op logboek gebaseerde hersteltechnieken.
• Als herstel van de database vanwege corruptie van het transactielogboek niet succesvol is, wordt het transactielogboek opnieuw opgebouwd. Het opnieuw opbouwen van het transactielogboek kan resulteren in het verlies van transactionele consistentie.

Als het DBCC CHECKDB-commando slaagt, is de database in een fysiek consistente staat en wordt de databasestatus ingesteld op ONLINE. De database kan echter een of meer transactionele inconsistenties bevatten. Wij raden u aan DBCC CHECKCONSTRAINTS uit te voeren om eventuele fouten in de bedrijfslogica te identificeren en onmiddellijk een back-up van de database te maken.Als het DBCC CHECKDB-commando mislukt, kan de database niet worden gerepareerd.

Het uitvoeren van DBCC CHECKDB met REPAIR_ALLOW_DATA_LOSS in gerepliceerde databases

Het uitvoeren van het DBCC CHECKDB-commando met de optie REPAIR_ALLOW_DATA_LOSS kan van invloed zijn op gebruikersdatabases (publicatie- en abonnementsdatabases) en de distributiedatabase die door replicatie wordt gebruikt. Publicatie- en abonnementsdatabases bevatten gepubliceerde tabellen en replicatiemetadatatabellen. Wees u bewust van de volgende potentiële problemen in deze databases:

• Gepubliceerde tabellen. Acties die door het CHECKDB-proces worden uitgevoerd om corrupte gebruikersgegevens te repareren, worden mogelijk niet gerepliceerd:
• Merge replicatie gebruikt triggers om wijzigingen in gepubliceerde tabellen bij te houden. Als rijen worden ingevoegd, bijgewerkt of verwijderd door het CHECKDB-proces, worden de triggers niet geactiveerd; de wijziging wordt dus niet gerepliceerd.
• Transactionele replicatie gebruikt het transactielogboek om wijzigingen in gepubliceerde tabellen bij te houden. De Log Reader Agent verplaatst deze wijzigingen vervolgens naar de distributiedatabase. Sommige DBCC-reparaties, hoewel gelogd, kunnen niet worden gerepliceerd door de Log Reader Agent. Als bijvoorbeeld een gegevenspagina door het CHECKDB-proces wordt gedelocaliseerd, vertaalt de Log Reader Agent dit niet naar een DELETE-instructie; de wijziging wordt dus niet gerepliceerd.
• Replicatiemetadatatabellen. Acties uitgevoerd door het CHECKDB proces om corrupte replicatie metadata tabellen te repareren vereisen het verwijderen en opnieuw configureren van replicatie.

Als u het DBCC CHECKDB commando moet uitvoeren met de REPAIR_ALLOW_DATA_LOSS optie op een gebruikersdatabase of distributie database:

1. Druk op het systeem: Stop de activiteit op de database en op alle andere databases in de replicatietopologie, en probeer vervolgens alle knooppunten te synchroniseren. Zie Een replicatietopologie onderbreken (Replicatie Transact-SQL Programmeren) voor meer informatie.
2. Uitvoeren DBCC CHECKDB.
3. Als het DBCC CHECKDB-rapport reparaties bevat voor tabellen in de distributiedatabase of voor replicatiemetadatatatabellen in een gebruikersdatabase, verwijdert u de replicatie en configureert u deze opnieuw. Zie Publiceren en distribueren uitschakelen voor meer informatie.
4. Als het DBCC CHECKDB-rapport reparaties bevat voor gerepliceerde tabellen, voer dan gegevensvalidatie uit om te bepalen of er verschillen zijn tussen de gegevens in de publicatie- en abonnementsdatabases.

Result Sets

DBCC CHECKDB retourneert de volgende resultatenset. De waarden kunnen variëren, behalve wanneer de opties ESTIMATEONLY, PHYSICAL_ONLY of NO_INFOMSGS 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 resultatenreeks (bericht) wanneer NO_INFOMSGS is opgegeven:

 The command(s) completed successfully.

DBCC CHECKDB retourneert de volgende resultaatreeks wanneer FYSIEKE_ONLY is gespecificeerd:

 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 resultaatreeks wanneer ESTIMATEONLY is gespecificeerd.

 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.

Permissions

Veist lidmaatschap van de vaste serverrol sysadmin of de vaste databaserol db_owner.

Examples

A. De huidige en een andere database controleren

Het volgende voorbeeld voert DBCC CHECKDB uit voor de huidige database en voor de AdventureWorks2012-database.

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

B. De huidige database controleren, informatieve berichten onderdrukken

Het volgende voorbeeld controleert de huidige database en onderdrukt alle informatieve berichten.

DBCC CHECKDB WITH NO_INFOMSGS; GO 

Zie ook

DBCC (Transact-SQL)
De grootte van het Sparse File van een Database Snapshot bekijken (Transact-SQL)
sp_helpdb (Transact-SQL)
Systeemtabellen (Transact-SQL)