DBCC CHECKTABLE (Transact-SQL)

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Kontrollerar integriteten för alla sidor och strukturer som utgör tabellen eller den indexerade vyn.

Transact-SQL syntaxkonventioner

Syntax

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 ]
        }
    ]

Argument

table_name | view_name

Den tabell eller indexerade vy som integritetskontroller ska köras för. Tabell- eller vynamn måste följa reglerna för identifierare.

NOINDEX

Anger att intensiva kontroller av icke-grupperade index för användartabeller inte ska utföras. Detta minskar den totala körningstiden. NOINDEX påverkar inte systemtabeller eftersom integritetskontrollerna alltid utförs på alla systemtabellindex.

index_id

Det indexidentifieringsnummer (ID) som integritetskontroller ska köras för. Om index_id anges kör DBCC CHECKTABLE endast integritetskontroller på indexet, tillsammans med heap- eller klustrade index.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Anger att DBCC CHECKTABLE reparera de fel som hittades. Om du vill använda ett reparationsalternativ måste databasen vara i enanvändarläge.

• REPAIR_ALLOW_DATA_LOSS

  Försöker reparera alla rapporterade fel. Dessa reparationer kan orsaka viss dataförlust.

• REPAIR_FAST

  Syntaxen bibehålls endast för bakåtkompatibilitet. Inga reparationsåtgärder utförs.

• REPAIR_REBUILD

  Utför reparationer som inte har någon möjlighet till dataförlust. Detta kan omfatta snabbreparationer, till exempel reparation av saknade rader i icke-illustrerade index och mer tidskrävande reparationer, till exempel återskapa ett index.

  Det här argumentet reparerar inte fel som rör FILESTREAM-data.

Viktig

Använd endast REPARATIONsalternativen som en sista utväg. För att reparera fel rekommenderar vi att du återställer från en säkerhetskopia. Reparationsåtgärder tar inte hänsyn till några av de begränsningar som kan finnas i eller mellan tabeller. Om den angivna tabellen ingår i en eller flera begränsningar rekommenderar vi att du kör DBCC CHECKCONSTRAINTS efter en reparationsåtgärd. Om du måste använda REPAIR kör du DBCC CHECKTABLE utan reparationsalternativ för att hitta den reparationsnivå som ska användas. Om du använder REPAIR_ALLOW_DATA_LOSS-nivån rekommenderar vi att du säkerhetskopierar databasen innan du kör DBCC CHECKTABLE med det här alternativet.

ALL_ERRORMSGS

Visar ett obegränsat antal fel. Alla felmeddelanden visas som standard. Att ange eller utelämna det här alternativet har ingen effekt.

EXTENDED_LOGICAL_CHECKS

Om kompatibilitetsnivån är 100, som introducerades i SQL Server 2008 (10.0.x), utför logiska konsekvenskontroller på en indexerad vy, XML-index och rumsliga index, där det finns.

Mer information finns i Utföra logiska konsekvenskontroller på index i avsnittet Kommentarer senare i den här artikeln.

NO_INFOMSGS

Undertrycker alla informationsmeddelanden.

TABLOCK

Gör att DBCC CHECKTABLE hämtar ett delat tabelllås i stället för att använda en intern databasögonblicksbild. TABLOCK gör att DBCC CHECKTABLE körs snabbare på en tabell med hög belastning, men minskar samtidigheten i tabellen medan DBCC CHECKTABLE körs.

ESTIMATEONLY

Visar den uppskattade mängden tempdb utrymme som krävs för att köra DBCC CHECKTABLE med alla andra angivna alternativ.

PHYSICAL_ONLY

Begränsar kontrollen till integriteten för sidans fysiska struktur, postrubriker och B-trädens fysiska struktur. Den här kontrollen är utformad för att ge en liten kontroll av tabellens fysiska konsekvens och kan även identifiera sönderrivna sidor och vanliga maskinvarufel som kan kompromettera data. En fullständig körning av DBCC CHECKTABLE kan ta betydligt längre tid än i tidigare versioner. Det här beteendet uppstår på grund av följande orsaker:

• De logiska kontrollerna är mer omfattande.
• Vissa av de underliggande strukturer som ska kontrolleras är mer komplexa.
• Många nya kontroller har införts för att inkludera de nya funktionerna.

Not

I dokumentationen används termen B-träd vanligtvis som referens till index. I radlagringsindex implementerar databasmotorn ett B+-träd. Detta gäller inte för kolumnlagringsindex eller index i minnesoptimerade tabeller. Mer information finns i arkitekturen och designguiden för SQL Server och Azure SQL-index.

Därför kan användningen av alternativet PHYSICAL_ONLY orsaka mycket kortare körning för DBCC CHECKTABLE på stora tabeller och rekommenderas därför för frekvent användning i produktionssystem. Vi rekommenderar fortfarande att en fullständig körning av DBCC CHECKTABLE utförs regelbundet. Frekvensen för dessa körningar beror på faktorer som är specifika för enskilda företag och produktionsmiljöer. PHYSICAL_ONLY innebär alltid NO_INFOMSGS och tillåts inte med något av reparationsalternativen.

Not

Om du anger PHYSICAL_ONLY kan DBCC CHECKTABLE hoppa över alla kontroller av FILESTREAM-data.

DATA_PURITY

Orsakar DBCC CHECKTABLE att kontrollera tabellen efter kolumnvärden som inte är giltiga eller som ligger inom intervallet. Till exempel identifierar DBCC CHECKTABLE kolumner med datum- och tidsvärden som är större än eller mindre än det acceptabla intervallet för datetime datatyp. eller decimaler eller ungefärliga numeriska datatypskolumner med skalnings- eller precisionsvärden som inte är giltiga.

Integritetskontroller för kolumnvärde är aktiverade som standard och kräver inte alternativet DATA_PURITY. För databaser som uppgraderats från tidigare versioner av SQL Server kan du använda DBCC CHECKTABLE WITH DATA_PURITY för att hitta och korrigera fel i en viss tabell. Men kolumnvärdeskontroller i tabellen är inte aktiverade som standard förrän DBCC CHECKDB WITH DATA_PURITY har körts felfritt i databasen. Därefter kontrollerar DBCC CHECKDB och DBCC CHECKTABLE kolumnvärdesintegritet som standard.

Valideringsfel som rapporteras av det här alternativet kan inte åtgärdas med hjälp av reparationsalternativ för DBCC. Information om hur du korrigerar de här felen manuellt finns i knowledge base-artikeln 923247: Felsökning av DBCC-fel 2570 i SQL Server 2005 och senare versioner.

Om PHYSICAL_ONLY anges utförs inte kolumnintegritetskontroller.

MAXDOP

gäller för: SQL Server 2014 (12.x) Service Pack 2 och senare versioner.

Åsidosätter maximal grad av parallellitet konfigurationsalternativet för sp_configure för -instruktionen. MAXDOP kan överskrida det värde som konfigurerats med sp_configure. Om MAXDOP överskrider det värde som konfigurerats med Resource Governor använder databasmotorn MAXDOP-värdet Resource Governor, som beskrivs i ALTER WORKLOAD GROUP (Transact-SQL). Alla semantiska regler som används med konfigurationsalternativet maximal grad av parallellitet gäller när du använder MAXDOP-frågetipset. Mer information finns i Konfigurera den maximala graden av parallellitet serverkonfigurationsalternativ.

Not

Om MAXDOP är inställt på noll väljer servern den maximala graden av parallellitet.

Anmärkningar

Not

Om du vill utföra DBCC CHECKTABLE på varje tabell i databasen använder du DBCC CHECKDB.

För den angivna tabellen söker DBCC CHECKTABLE efter följande:

• Index-, in-row-, LOB- och row-overflow-datasidor är korrekt länkade.
• Indexen är i rätt sorteringsordning.
• Pekare är konsekventa.
• Data på varje sida är rimliga, inkluderade beräknade kolumner.
• Sidförskjutningar är rimliga.
• Varje rad i bastabellen har en matchande rad i varje icke-grupperat index och vice versa.
• Varje rad i en partitionerad tabell eller ett index finns i rätt partition.
• Konsekvens på länknivå mellan filsystemet och tabellen vid lagring av varbinary(max) data i filsystemet med hjälp av FILESTREAM.

Utföra logiska konsekvenskontroller på index

Logisk konsekvenskontroll på index varierar beroende på databasens kompatibilitetsnivå enligt följande:

• Om kompatibilitetsnivån är 100 (SQL Server 2008 (10.0.x)) eller högre:

  • Såvida inte NOINDEX anges utför DBCC CHECKTABLE både fysiska och logiska konsekvenskontroller på en enda tabell och på alla dess icke-illustrerade index. På XML-index utförs dock endast fysiska konsekvenskontroller som standard för rumsliga index och indexerade vyer.

  • Om WITH EXTENDED_LOGICAL_CHECKS anges utförs logiska kontroller i en indexerad vy, XML-index och rumsliga index, där det finns. Som standard utförs fysiska konsekvenskontroller innan den logiska konsekvensen kontrolleras. Om NOINDEX också anges utförs endast de logiska kontrollerna.

    Dessa logiska konsekvenskontrollerar korskontrollera den interna indextabellen för indexobjektet med användartabellen som den refererar till. För att ta reda på rader skapas en intern fråga för att utföra en fullständig skärningspunkt mellan de interna tabellerna och användartabellerna. Att köra den här frågan kan ha en mycket hög effekt på prestanda och dess förlopp kan inte spåras. Därför rekommenderar vi att du anger WITH EXTENDED_LOGICAL_CHECKS endast om du misstänker indexproblem som inte är relaterade till fysisk skada, eller om kontrollsummor på sidnivå har inaktiverats och du misstänker maskinvarufel på kolumnnivå.

  • Om indexet är ett filtrerat index utför DBCC CHECKTABLE konsekvenskontroller för att kontrollera att indexposterna uppfyller filterpredikatet.

• Från och med SQL Server 2016 (13.x) körs inte ytterligare kontroller på beständiga beräknade kolumner, UDT-kolumner och filtrerade index som standard för att undvika dyra uttrycksutvärderingar. Den här ändringen minskar avsevärt varaktigheten för CHECKTABLE mot databaser som innehåller dessa objekt. De fysiska konsekvenskontrollerna av dessa objekt slutförs dock alltid. Endast när EXTENDED_LOGICAL_CHECKS alternativet anges utförs uttrycksutvärderingarna, förutom att redan visa logiska kontroller (indexerad vy, XML-index och rumsliga index) som en del av alternativet EXTENDED_LOGICAL_CHECKS.

• Om kompatibilitetsnivån är 90 (SQL Server 2005 (9.x)) eller mindre, såvida inte NOINDEX anges, utför DBCC CHECKTABLE både fysiska och logiska konsekvenskontroller på en enda tabell eller indexerad vy och på alla dess icke-illustrerade och XML-index. Rumsliga index stöds inte.

Lär dig kompatibilitetsnivån för en databas

• visa eller ändra kompatibilitetsnivån för en databas

Intern databasögonblicksbild

DBCC CHECKTABLE använder en intern databasögonblicksbild för att ge den transaktionskonsekvens som krävs för att utföra dessa kontroller. Mer information finns i Visa storleken på sparse-filen för en databasögonblicksbild (Transact-SQL) och avsnittet om databasögonblicksbild i DBCC (Transact-SQL).

Om en ögonblicksbild inte kan skapas eller TABLOCK har angetts, DBCC CHECKTABLE hämtar ett delat tabelllås för att få den konsekvens som krävs.

Not

Om DBCC CHECKTABLE körs mot tempdbmåste det hämta ett delat tabelllås. Det beror på att databasögonblicksbilder av prestandaskäl inte är tillgängliga på tempdb. Det innebär att den transaktionskonsekvens som krävs inte kan erhållas.

Kontrollera och reparera FILESTREAM-data

När FILESTREAM är aktiverat för en databas och tabell kan du lagra varbinary(max) binära stora objekt (BLOB) i filsystemet. När du använder DBCC CHECKTABLE i en tabell som lagrar BLOB i filsystemet kontrollerar DBCC konsekvens på länknivå mellan filsystemet och databasen.

Om en tabell till exempel innehåller en varbinary(max) kolumn som använder attributet FILESTREAM kontrollerar DBCC CHECKTABLE att det finns en en-till-en-mappning mellan filsystemkataloger och filer och tabellrader, kolumner och kolumnvärden. DBCC CHECKTABLE kan reparera skador om du anger alternativet REPAIR_ALLOW_DATA_LOSS. För att reparera FILESTREAM-skador tar DBCC bort alla tabellrader som saknar filsystemdata och tar bort alla kataloger och filer som inte mappas till en tabellrad, kolumn eller kolumnvärde.

Kontrollera objekt parallellt

Som standard utför DBCC CHECKTABLE parallell kontroll av objekt. Graden av parallellitet bestäms automatiskt av frågeprocessorn. Den maximala graden av parallellitet konfigureras på samma sätt som parallella frågor. Om du vill begränsa det maximala antalet tillgängliga processorer för DBCC-kontroll använder du sp_configure. Mer information finns i Konfigurera den maximala graden av parallellitet serverkonfigurationsalternativ.

Parallell kontroll kan inaktiveras med hjälp av spårningsflagga 2528. Mer information finns i Spårningsflaggor (Transact-SQL).

Not

Under en DBCC CHECKTABLE åtgärd måste byte som lagras i en bytedefinierad kolumn av användardefinierad typ vara lika med den beräknade serialiseringen av det användardefinierade typvärdet. Om detta inte är sant rapporterar DBCC CHECKTABLE-rutinen ett konsekvensfel.

Not

Den här funktionen är inte tillgänglig i varje version av SQL Server. Mer information finns i parallell konsekvenskontroll i avsnittet RDBMS-hanterbarhet i Editions och funktioner som stöds i SQL Server 2022.

Förstå DBCC-felmeddelanden

När DBCC CHECKTABLE kommandot har slutförts skrivs ett meddelande till SQL Server-felloggen. Om DBCC-kommandot körs anger meddelandet att det har slutförts och hur lång tid kommandot kördes. Om DBCC-kommandot stoppas innan kontrollen slutförs på grund av ett fel anger meddelandet att kommandot avslutades, ett tillståndsvärde och hur lång tid kommandot kördes. I följande tabell visas och beskrivs de tillståndsvärden som kan inkluderas i meddelandet.

Stat	Beskrivning
0	Felnummer 8930 har genererats. Detta indikerar en skadad metadata som gjorde att DBCC-kommandot avslutades.
1	Felnummer 8967 har genererats. Det uppstod ett internt DBCC-fel.
2	Ett fel inträffade under reparationen av databasen i nödläge.
3	Detta indikerar en skadad metadata som gjorde att DBCC-kommandot avslutades.
4	En kontroll- eller åtkomstöverträdelse har identifierats.
5	Ett okänt fel uppstod som avslutade DBCC-kommandot.

Felrapportering

En minidumpfil (SQLDUMP<nnnn>.txt) skapas i katalogen SQL Server LOG när DBCC CHECKTABLE upptäcker ett fel. När funktionsanvändning datainsamling och felrapportering funktioner aktiveras för sql Server-instansen vidarebefordras filen automatiskt till Microsoft. Insamlade data används för att förbättra SQL Server-funktioner.

Dumpfilen innehåller resultatet av kommandot DBCC CHECKTABLE och ytterligare diagnostiska utdata. Filen har begränsade diskretionära åtkomstkontrollistor (DACLs). Åtkomsten är begränsad till SQL Server-tjänstkontot och medlemmar i sysadmin-rollen. Som standard innehåller sysadmin-rollen alla medlemmar i gruppen Windows BUILTIN\Administrators och den lokala administratörsgruppen. DBCC-kommandot misslyckas inte om datainsamlingsprocessen misslyckas.

Lösa fel

Om DBCC CHECKTABLE rapporterar några fel rekommenderar vi att du återställer databasen från databassäkerhetskopian i stället för att köra REPAIR med något av reparationsalternativen. Om det inte finns någon säkerhetskopia kan du åtgärda felen som rapporteras genom att köra REPAIR. Alternativet REPARERA som ska användas anges i slutet av listan över rapporterade fel. Att korrigera felen med hjälp av alternativet REPAIR_ALLOW_DATA_LOSS kan dock kräva att vissa sidor och därmed data tas bort.

Reparationen kan utföras under en användartransaktion så att användaren kan återställa de ändringar som har gjorts. Om reparationer återställs innehåller databasen fortfarande fel och måste återställas från en säkerhetskopia. När du har slutfört alla reparationer säkerhetskopierar du databasen.

Resultatuppsättningar

DBCC CHECKTABLE returnerar följande resultatuppsättning. Samma resultatuppsättning returneras om du bara anger tabellnamnet eller något av alternativen.

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 returnerar följande resultatuppsättning om alternativet ESTIMATEONLY har angetts:

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

Behörigheter

Användaren måste äga tabellen eller vara medlem i den fasta serverrollen sysadmin, db_owner fast databasroll eller db_ddladmin fast databasroll.

Exempel

A. Kontrollera en specifik tabell

I följande exempel kontrolleras datasidans integritet för tabellen HumanResources.Employee i databasen AdventureWorks2022.

DBCC CHECKTABLE ('HumanResources.Employee');
GO

B. Utföra en kontroll av tabellen med låga omkostnader

I följande exempel utförs en låg belastningskontroll av tabellen Employee i databasen AdventureWorks2022.

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

C. Kontrollera ett specifikt index

I följande exempel kontrolleras ett specifikt index som hämtas genom att komma åt 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);

Se även

• DBCC (Transact-SQL)
• DBCC CHECKDB (Transact-SQL)