Delen via

DBCC CHECKTABLE (Transact-SQL)

  • Artikel

van toepassing op:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Controleert de integriteit van alle pagina's en structuren waaruit de tabel of geïndexeerde weergave bestaat.

Transact-SQL syntaxisconventies

Syntaxis

DBCC CHECKTABLE
(
    table_name | view_name
    [ , { NOINDEX | index_id }
     | , { 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

table_name | view_name

De tabel of geïndexeerde weergave waarvoor integriteitscontroles moeten worden uitgevoerd. Namen van tabellen of weergaven moeten voldoen aan de regels voor id's.

NOINDEX

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

index_id

Het id-nummer (indexidentificatie) waarvoor integriteitscontroles moeten worden uitgevoerd. Als index_id is opgegeven, DBCC CHECKTABLE integriteitscontroles alleen op die index uitvoert, samen met de heap of geclusterde index.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Hiermee geeft u op dat DBCC CHECKTABLE de gevonden fouten herstellen. Als u een hersteloptie wilt gebruiken, moet de database zich in de modus voor één gebruiker bevinden.

  • REPAIR_ALLOW_DATA_LOSS

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

  • REPAIR_FAST

    De syntaxis wordt alleen behouden voor compatibiliteit met eerdere versies. Er worden geen herstelacties uitgevoerd.

  • REPAIR_REBUILD

    Voert reparaties uit die geen kans hebben op gegevensverlies. Dit 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

Gebruik de REPARATIE-opties alleen als laatste redmiddel. 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 kunnen 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 CHECKTABLE uit zonder een reparatieoptie om het herstelniveau te vinden dat moet worden gebruikt. Als u het REPAIR_ALLOW_DATA_LOSS niveau gebruikt, wordt u aangeraden een back-up van de database te maken voordat u DBCC CHECKTABLE uitvoert met deze optie.

ALL_ERRORMSGS

Geeft een onbeperkt aantal fouten weer. Alle foutberichten worden standaard weergegeven. Het opgeven of weglaten van deze optie heeft geen effect.

EXTENDED_LOGICAL_CHECKS

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

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

NO_INFOMSGS

Onderdrukt alle informatieve berichten.

TABLOCK

Zorgt ervoor dat DBCC CHECKTABLE een gedeelde tabelvergrendeling krijgt in plaats van een momentopname van een interne database te gebruiken. TABLOCK zorgt ervoor dat DBCC CHECKTABLE sneller wordt uitgevoerd op een tabel onder zware belasting, maar vermindert de gelijktijdigheid die beschikbaar is in de tabel terwijl DBCC CHECKTABLE wordt uitgevoerd.

SCHATTING

Geeft de geschatte hoeveelheid tempdb ruimte weer die nodig is om DBCC CHECKTABLE uit te voeren met alle andere opgegeven opties.

PHYSICAL_ONLY

Hiermee wordt de controle beperkt tot de integriteit van de fysieke structuur van de pagina, recordheaders en de fysieke structuur van B-trees. Deze controle is ontworpen voor een kleine overheadcontrole van de fysieke consistentie van de tabel, maar deze controle kan ook gescheurde pagina's detecteren en veelvoorkomende hardwarefouten die gegevens kunnen in gevaar brengen. Een volledige uitvoering van DBCC CHECKTABLE kan aanzienlijk langer duren dan in eerdere versies. Dit gedrag treedt op vanwege de volgende redenen:

  • 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.

Notitie

Documentatie maakt gebruik van de term B-tree in het algemeen in verwijzing naar indexen. In rijstore-indexen implementeert de database-engine een B+-structuur. Dit geldt niet voor columnstore-indexen of indexen voor tabellen die zijn geoptimaliseerd voor geheugen. Zie de SQL Server- en Azure SQL-indexarchitectuur en ontwerphandleidingvoor meer informatie.

Daarom kan het gebruik van de optie PHYSICAL_ONLY leiden tot een veel kortere runtime voor DBCC CHECKTABLE op grote tabellen en wordt daarom aanbevolen voor frequent gebruik op productiesystemen. We raden u nog steeds aan om regelmatig een volledige uitvoering van DBCC CHECKTABLE uit te voeren. De frequentie van deze uitvoeringen is afhankelijk van factoren die specifiek zijn voor individuele bedrijven en productieomgevingen. PHYSICAL_ONLY impliceert altijd NO_INFOMSGS en is niet toegestaan met een van de reparatieopties.

Notitie

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

DATA_PURITY

Zorgt ervoor dat DBCC CHECKTABLE de tabel controleert op kolomwaarden die niet geldig of buiten het bereik vallen. DBCC CHECKTABLE 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, kunt u DBCC CHECKTABLE WITH DATA_PURITY gebruiken om fouten in een specifieke tabel te vinden en te corrigeren; Controles van kolomwaarden in de tabel zijn echter niet standaard ingeschakeld totdat DBCC CHECKDB WITH DATA_PURITY foutvrij is uitgevoerd in de database. Hierna DBCC CHECKDB en DBCC CHECKTABLE standaard de integriteit van kolomwaarden controleren.

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

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

MAXDOP

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

Overschrijft de maximale mate van parallelle uitvoering 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 database-engine de MAXDOP-waarde van Resource Governor, zoals beschreven in ALTER WORKLOAD GROUP (Transact-SQL). Alle semantische regels die worden gebruikt met de maximale mate van parallelle configuratie zijn van toepassing wanneer u de MAXDOP-queryhint gebruikt. Zie De maximale mate van parallelle configuratie van server configurerenvoor meer informatie.

Notitie

Als MAXDOP is ingesteld op nul, kiest de server de maximale mate van parallelle uitvoering.

Opmerkingen

Notitie

Als u DBCC CHECKTABLE wilt uitvoeren voor elke tabel in de database, gebruikt u DBCC CHECKDB-.

Voor de opgegeven tabel controleert DBCC CHECKTABLE op het volgende:

  • Index-, rij-, LOB- en rij-overloopgegevenspagina's zijn correct gekoppeld.
  • Indexen bevinden zich in de juiste sorteervolgorde.
  • Aanwijzers zijn consistent.
  • De gegevens op elke pagina zijn redelijk, inclusief berekende kolommen.
  • Pagina-verschuivingen zijn redelijk.
  • Elke rij in de basistabel heeft een overeenkomende rij in elke niet-geclusterde index en omgekeerd.
  • Elke rij in een gepartitioneerde tabel of index bevindt zich in de juiste partitie.
  • Consistentie op koppelingsniveau tussen het bestandssysteem en de tabel bij het opslaan van varbinary(max) gegevens in het bestandssysteem met behulp van FILESTREAM.

Logische consistentiecontroles uitvoeren op indexen

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

  • Als het compatibiliteitsniveau 100 is (SQL Server 2008 (10.0.x)) of hoger:

    • Tenzij NOINDEX is opgegeven, voert DBCC CHECKTABLE 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 consistentiecontroles controleren de interne indextabel van het indexobject kruislings 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 zeer hoog 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 CHECKTABLE consistentiecontroles uit om te controleren of de indexvermeldingen voldoen aan het filterpredicaat.

  • Vanaf SQL Server 2016 (13.x) worden extra controles uitgevoerd op persistente berekende kolommen, UDT-kolommen en gefilterde indexen niet standaard om de dure expressie-evaluaties te voorkomen. Deze wijziging vermindert de duur van CHECKTABLE aanzienlijk ten opzichte van databases die deze objecten bevatten. De fysieke consistentiecontroles van deze objecten worden echter altijd voltooid. Alleen wanneer EXTENDED_LOGICAL_CHECKS optie is opgegeven, worden de expressie-evaluaties uitgevoerd, naast de reeds aanwezige logische controles (geïndexeerde weergave, XML-indexen en ruimtelijke indexen) als onderdeel van de optie EXTENDED_LOGICAL_CHECKS.

  • Als het compatibiliteitsniveau 90 is (SQL Server 2005 (9.x)) of minder, tenzij NOINDEX is opgegeven, voert DBCC CHECKTABLE 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.

Meer informatie over het compatibiliteitsniveau van een database

Momentopname van interne database

DBCC CHECKTABLE maakt gebruik van een momentopname van een interne database om de transactionele consistentie te bieden die nodig is om deze controles uit te voeren. Zie voor meer informatie De grootte van het Sparse-bestand van een momentopname van een database (Transact-SQL) en het gedeelte databasemomentopname van dbcc weergeven sectie in DBCC (Transact-SQL).

Als een momentopname niet kan worden gemaakt of TABLOCK is opgegeven, verkrijgt DBCC CHECKTABLE een gedeelde tabelvergrendeling om de vereiste consistentie te verkrijgen.

Notitie

Als DBCC CHECKTABLE wordt uitgevoerd op tempdb, moet deze een gedeelde tabelvergrendeling verkrijgen. Dit komt omdat databasemomentopnamen om prestatieredenen niet beschikbaar zijn op tempdb. Dit betekent dat de vereiste transactionele consistentie niet kan worden verkregen.

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 CHECKTABLE gebruikt in een tabel 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 CHECKTABLE of er een een-op-een-toewijzing is tussen bestandssysteemmappen en bestanden en tabelrijen, kolommen en kolomwaarden. DBCC CHECKTABLE 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 en worden alle mappen en bestanden verwijderd die niet zijn toegewezen aan een tabelrij, kolom of kolomwaarde.

Objecten parallel controleren

Standaard voert DBCC CHECKTABLE parallelle controle van objecten uit. De mate van parallelle uitvoering wordt automatisch bepaald door de queryprocessor. De maximale mate van parallelle uitvoering wordt op dezelfde manier geconfigureerd als die van parallelle query's. Gebruik sp_configureom het maximum aantal processors te beperken dat beschikbaar is voor DBCC-controles. Zie De maximale mate van parallelle configuratie van server configurerenvoor meer informatie.

Parallelle controle kan worden uitgeschakeld met traceringsvlag 2528. Zie traceringsvlagmen (Transact-SQL)voor meer informatie.

Notitie

Tijdens een DBCC CHECKTABLE bewerking moeten de bytes die zijn opgeslagen in een door de gebruiker geordende kolom van het door de gebruiker gedefinieerde type gelijk zijn aan de berekende serialisatie van de door de gebruiker gedefinieerde typewaarde. Als dit niet waar is, rapporteert de DBCC CHECKTABLE routine een consistentiefout.

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 CHECKTABLE is voltooid, wordt er een bericht naar het SQL Server-foutenlogboek geschreven. Als de DBCC-opdracht is uitgevoerd, geeft het bericht een geslaagde voltooiing aan en de hoeveelheid tijd die de opdracht heeft 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 van metagegevens aan waardoor de DBCC-opdracht is 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 van metagegevens aan waardoor de DBCC-opdracht is 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.

Foutrapportage

Er wordt een minidumpbestand (SQLDUMP<nnnn>.txt) gemaakt in de map SQL Server LOG wanneer DBCC CHECKTABLE 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 CHECKTABLE en aanvullende diagnostische uitvoer. Het bestand heeft beperkte discretionaire toegangsbeheerlijsten (DACL's). Toegang is beperkt tot het SQL Server-serviceaccount en leden van de rol sysadmin. De rol sysadmin bevat standaard alle leden van de groep Windows BUILTIN\Administrators en de groep van de lokale beheerder. De DBCC-opdracht mislukt niet als het proces voor het verzamelen van gegevens mislukt.

Fouten oplossen

Als DBCC CHECKTABLE fouten rapporteert, raden we u aan om de database te herstellen vanuit de databaseback-up in plaats van HERSTELLEN uit te voeren met een van de HERSTELopties. Als er geen back-up bestaat, kan het uitvoeren van REPAIR de fouten corrigeren die worden gerapporteerd. De te gebruiken REPARATIE-optie 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, moeten sommige pagina's en daarom gegevens worden verwijderd.

De reparatie 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 u alle reparaties hebt voltooid, maakt u een back-up van de database.

Resultatensets

DBCC CHECKTABLE retourneert de volgende resultatenset. Dezelfde resultatenset wordt geretourneerd als u alleen de tabelnaam of een van de opties opgeeft.

DBCC results for 'HumanResources.Employee'.
There are 288 rows in 13 pages for object 'Employee'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC CHECKTABLE retourneert de volgende resultatenset als de optie ESTIMATEONLY is opgegeven:

Estimated TEMPDB space needed for CHECKTABLES (KB)
--------------------------------------------------
21
(1 row(s) affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Machtigingen

De gebruiker moet eigenaar zijn van de tabel of lid zijn van de vaste serverrol sysadmin, de db_owner vaste databaserol of de db_ddladmin vaste databaserol.

Voorbeelden

Een. Een specifieke tabel controleren

In het volgende voorbeeld wordt de integriteit van de gegevenspagina van de HumanResources.Employee tabel in de Database AdventureWorks2022 gecontroleerd.

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. Een lage overheadcontrole van de tabel uitvoeren

In het volgende voorbeeld wordt een lage overheadcontrole uitgevoerd van de Employee tabel in de Database AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee') WITH PHYSICAL_ONLY;
GO

C. Een specifieke index controleren

In het volgende voorbeeld wordt een specifieke index gecontroleerd, verkregen door toegang te krijgen tot sys.indexes.

DECLARE @indid int;
SET @indid = (SELECT index_id
              FROM sys.indexes
              WHERE object_id = OBJECT_ID('Production.Product')
                    AND name = 'AK_Product_Name');
DBCC CHECKTABLE ('Production.Product',@indid);

Zie ook