DBCC CHECKDB (Transact-SQL)

Artikel
03/05/2025

gäller för:SQL Server Azure SQL Database Azure SQL Managed Instance

Kontrollerar den logiska och fysiska integriteten för alla objekt i den angivna databasen genom att utföra följande åtgärder:

Kör DBCC CHECKALLOC- på databasen.
Kör DBCC CHECKTABLE på varje tabell och vy i databasen.
Kör DBCC CHECKCATALOG- på databasen.
Verifierar innehållet i varje indexerad vy i databasen.
Validerar konsekvens på länknivå mellan tabellmetadata och filsystemkataloger och filer när varbinary(max) lagras data i filsystemet med hjälp av FILESTREAM.
Validerar Service Broker-data i databasen.

Det innebär att kommandona DBCC CHECKALLOC, DBCC CHECKTABLEeller DBCC CHECKCATALOG inte behöver köras separat från DBCC CHECKDB. Mer detaljerad information om de kontroller som dessa kommandon utför finns i beskrivningarna av dessa kommandon.

DBCC CHECKDB stöds på databaser som innehåller minnesoptimerade tabeller, men verifiering sker bara på diskbaserade tabeller. Men som en del av säkerhetskopiering och återställning av databaser görs en CHECKSUM validering för filer i minnesoptimerade filgrupper.

Eftersom DBCC-reparationsalternativ inte är tillgängliga för minnesoptimerade tabeller måste du säkerhetskopiera databaserna regelbundet och testa säkerhetskopiorna. Om dataintegritetsproblem uppstår i en minnesoptimerad tabell måste du återställa från den senast kända säkerhetskopian.

Transact-SQL syntaxkonventioner

Syntax

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

Argument

database_name | database_id | 0

Namnet eller ID:t för databasen som integritetskontroller ska köras för. Om det inte anges, eller om 0 anges, används den aktuella databasen. Databasnamn måste följa reglerna för identifierare.

NOINDEX

Anger att intensiva kontroller av icke-illustrerade index för användartabeller inte utförs. Det här valet minskar den totala körningstiden. NOINDEX påverkar inte systemtabeller eftersom integritetskontroller alltid utförs på systemtabellindex.

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Anger att DBCC CHECKDB reparerar felen som hittades. Använd endast REPAIR_* alternativ som en sista utväg. Den angivna databasen måste vara i enanvändarläge för att kunna använda något av följande reparationsalternativ.

REPAIR_ALLOW_DATA_LOSS

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

Varning

Alternativet REPAIR_ALLOW_DATA_LOSS kan leda till mer dataförlust än om du återställer från en senast känd bra säkerhetskopia. Se Dataförlustvarning med REPAIR_ALLOW_DATA_LOSS

Microsoft rekommenderar alltid en användaråterställning från den senast kända bra säkerhetskopieringen som den primära metoden för att återställa från fel som rapporterats av DBCC CHECKDB. Alternativet REPAIR_ALLOW_DATA_LOSS är inte ett alternativ för att återställa från en känd bra säkerhetskopia. Det är en nödsituation sista utväg alternativ som rekommenderas endast för användning om det inte går att återställa från en säkerhetskopia.

Vissa fel, som bara kan repareras med hjälp av alternativet REPAIR_ALLOW_DATA_LOSS, kan innebära att frigöra en rad, sida eller serie med sidor för att rensa felen. Alla frigjorda data är inte längre tillgängliga eller kan återställas för användaren, och det exakta innehållet i de frigjorda data kan inte fastställas. Därför kanske referensintegriteten inte är korrekt när några rader eller sidor frigörs eftersom begränsningar för främmande nycklar inte kontrolleras eller underhålls som en del av den här reparationsåtgärden. Användaren måste kontrollera referensintegriteten i databasen (med hjälp av DBCC CHECKCONSTRAINTS) efter att ha använt alternativet REPAIR_ALLOW_DATA_LOSS.

Innan du utför reparationen måste du skapa fysiska kopior av filerna som tillhör den här databasen. Detta inkluderar den primära datafilen (.mdf), alla sekundära datafiler (.ndf), alla transaktionsloggfiler (.ldf) och andra containrar som utgör databasen, inklusive fulltextkataloger, filströmsmappar, minnesoptimerade data och så vidare.

Innan du utför reparationen bör du överväga att ändra databasens tillstånd till EMERGENCY läge och försöka extrahera så mycket information som möjligt från de kritiska tabellerna och spara dessa data.
REPAIR_FAST

Upprätthåller endast syntax 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. Det här alternativet kan omfatta snabbreparationer, till exempel reparation av saknade rader i icke-grupperade index och mer tidskrävande reparationer, till exempel återskapa ett index.

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

Viktig

Eftersom DBCC CHECKDB med något av de REPAIR_* alternativen är helt loggade och återställningsbara rekommenderar Microsoft alltid att en användare använder DBCC CHECKDB med alla REPAIR_* alternativ i en transaktion (kör BEGIN TRANSACTION innan kommandot körs) så att användaren kan bekräfta att de vill acceptera resultatet av åtgärden. Sedan kan användaren köra COMMIT TRANSACTION för att utföra allt arbete som utförts av reparationsåtgärden. Om användaren inte vill acceptera resultatet av åtgärden kan de köra en ROLLBACK TRANSACTION för att ångra effekterna av reparationsåtgärderna.

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 CHECKDB 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 CHECKDB med det här alternativet.

ALL_ERRORMSGS

Visar alla rapporterade fel per objekt. Alla felmeddelanden visas som standard. Att ange eller utelämna det här alternativet har ingen effekt. Felmeddelanden sorteras efter objekt-ID, förutom de meddelanden som genereras från tempdb-databas.

EXTENDED_LOGICAL_CHECKS

Om kompatibilitetsnivån är 100, som introducerades i SQL Server 2008 (10.0.x), utför det här alternativet 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 senare i den här artikeln.

NO_INFOMSGS

Undertrycker alla informationsmeddelanden.

TABLOCK

Gör att DBCC CHECKDB hämtar lås i stället för att använda en intern databasögonblicksbild. Detta inkluderar ett kortsiktigt exklusivt (X) lås på databasen. TABLOCK gör att DBCC CHECKDB körs snabbare på en databas med hög belastning, men minskar samtidigheten i databasen när DBCC CHECKDB körs.

Viktig

TABLOCK begränsar de kontroller som utförs. DBCC CHECKCATALOG körs inte på databasen och Service Broker-data verifieras inte.

ESTIMATEONLY

Visar den uppskattade mängden tempdb utrymme som krävs för att köra DBCC CHECKDB med alla andra angivna alternativ. Den faktiska databaskontrollen utförs inte.

PHYSICAL_ONLY

Begränsar kontrollen till integriteten för sidans fysiska struktur och postrubriker och databasens allokeringskonsekvens. Den här kontrollen är utformad för att ge en liten kontroll av databasens fysiska konsekvens, men den kan också identifiera skadade sidor, kontrollsummafel och vanliga maskinvarufel som kan kompromettera en användares data.

En fullständig körning av DBCC CHECKDB kan ta betydligt längre tid att slutföra än tidigare versioner. Det här beteendet beror på att:

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.

Därför kan användningen av alternativet PHYSICAL_ONLY orsaka mycket kortare körning för DBCC CHECKDB på stora databaser och rekommenderas för frekvent användning i produktionssystem. Vi rekommenderar fortfarande att en fullständig körning av DBCC CHECKDB utföras regelbundet. Frekvensen för dessa körningar beror på faktorer som är specifika för enskilda företag och produktionsmiljöer.

Det här argumentet innebär alltid NO_INFOMSGS och tillåts inte med något av reparationsalternativen.

Varning

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

DATA_PURITY

Orsakar DBCC CHECKDB att kontrollera databasen efter kolumnvärden som inte är giltiga eller som ligger inom intervallet. Till exempel identifierar DBCC CHECKDB 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 aktiveras inte kolumnvärdekontroller som standard förrän DBCC CHECKDB WITH DATA_PURITY har körts felfritt i databasen. Därefter kontrollerar DBCC CHECKDB kolumnvärdesintegriteten som standard. Mer information om hur CHECKDB kan påverkas av uppgradering av databasen från tidigare versioner av SQL Server finns i avsnittet Anmärkningar senare i den här artikeln.

Varning

Om PHYSICAL_ONLY anges utförs inte kolumnintegritetskontroller.

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 dessa fel manuellt finns i MSSQLSERVER_2570.

MAXDOP

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

Åsidosätter max degree of parallelism konfigurationsalternativet för sp_configure för -instruktionen. MAXDOP kan överskrida värdet som konfigurerats med sp_configure. Om MAXDOP överskrider det värde som konfigurerats med Resource Governor använder SQL Server Database Engine värdet Resource Governor MAXDOP, som beskrivs i ALTER WORKLOAD GROUP. Alla semantiska regler som används med konfigurationsalternativet max degree of parallelism gäller när du använder MAXDOP frågetips. Mer information finns i Server-konfiguration: maximal grad av parallellitet.

Varning

Om MAXDOP är inställt på noll väljer SQL Server den max degree of parallelism som ska användas.

Anmärkningar

DBCC CHECKDB undersöker inte inaktiverade index. Mer information om inaktiverade index finns i Inaktivera index och begränsningar.

Om en användardefinierad typ markeras som bytebeställd får det bara finnas en serialisering av den användardefinierade typen. Om du inte har en konsekvent serialisering av bytesorterade användardefinierade typer uppstår fel 2537 när DBCC CHECKDB körs. Mer information finns i Skapa User-Defined typer – krav.

Eftersom resursdatabasen endast kan ändras i enanvändarläge kan kommandot DBCC CHECKDB inte köras direkt på den. Men när DBCC CHECKDB körs mot huvuddatabasen, körs även en andra CHECKDB internt på resursdatabasen. Det innebär att DBCC CHECKDB kan returnera extra resultat. Kommandot returnerar extra resultatuppsättningar när inga alternativ har angetts, eller när antingen alternativet PHYSICAL_ONLY eller ESTIMATEONLY anges.

I VERSIONER av SQL Server 2005 (9.x) Service Pack 2 och senare rensar körningen DBCC CHECKDB inte längre plancachen för SQL Server-instansen. Innan SQL Server 2005 (9.x) Service Pack 2 körs DBCC CHECKDB rensar plancachen. Om du rensar plancacheminnet blir det en omkompilering av alla senare körningsplaner och kan orsaka en plötslig, tillfällig minskning av frågeprestanda.

Utföra logiska konsekvenskontroller på index

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

Om kompatibilitetsnivån är minst 100 (introducerades i SQL Server 2008 (10.0.x)):
Såvida inte NOINDEX anges utför DBCC CHECKDB 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 betydande 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 CHECKDB konsekvenskontroller för att kontrollera att indexposterna uppfyller filterpredikatet.
Om kompatibilitetsnivån är 90 eller mindre, såvida inte NOINDEX anges, utför DBCC CHECKDB 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.
I SQL Server 2016 (13.x) och senare versioner 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 CHECKDB mot databaser som innehåller dessa objekt. Den fysiska konsekvenskontrollen av dessa objekt slutförs dock alltid. Endast när EXTENDED_LOGICAL_CHECKS alternativet anges utförs uttrycksutvärderingarna, förutom de logiska kontroller som redan finns som en del av alternativet EXTENDED_LOGICAL_CHECKS (indexerad vy, XML-index och rumsliga index).

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

Visa eller ändra kompatibilitetsnivån för en databas

Intern databasögonblicksbild

DBCC CHECKDB använder en intern databasögonblicksbild för den transaktionskonsekvens som krävs för att utföra dessa kontroller. Detta förhindrar blockerings- och samtidighetsproblem när dessa kommandon körs. Mer information finns i Visa storleken på sparse-filen för en databasögonblicksbild och avsnittet dbcc intern databasögonblicksbild i DBCC-. Om det inte går att skapa en ögonblicksbild, eller om TABLOCK har angetts, hämtar DBCC CHECKDB lås för att få den konsekvens som krävs. I det här fallet krävs ett exklusivt databaslås för att utföra allokeringskontrollerna och delade tabelllås krävs för att utföra tabellkontrollerna.

DBCC CHECKDB misslyckas när den körs mot master-databasen om det inte går att skapa en intern databasögonblicksbild.

Att köra DBCC CHECKDB mot tempdb utför inga allokerings- eller katalogkontroller och måste hämta delade tabelllås för att utföra tabellkontroller. 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 hämtas.

Hur DBCC CHECKDB skapar en intern ögonblicksbilddatabas som börjar med SQL Server 2014

DBCC CHECKDB skapar en intern ögonblicksbilddatabas.
Den interna ögonblicksbilddatabasen skapas med hjälp av fysiska filer. För en databas med database_id = 10 som har tre filer E:\Data\my_DB.mdf, E:\Data\my_DB.ndfoch E:\Data\my_DB.ldfskapas till exempel den interna ögonblicksbilddatabasen med hjälp av E:\Data\my_DB.mdf_MSSQL_DBCC11 och E:\Data\my_DB.ndf_MSSQL_DBCC11 filer. Ögonblicksbildens database_id är database_id + 1. Observera också att de nya filerna skapas i samma mapp med namngivningskonventionen <filename.extension>_MSSQL_DBCC<database_id_of_snapshot>. Ingen gles fil skapas för transaktionsloggen.
De nya filerna markeras som glesa filer på filsystemnivå. Storlek på disk som används av de nya filerna ökar baserat på hur mycket data som uppdateras i källdatabasen under kommandot DBCC CHECKDB. Storlek för de nya filerna är samma fil som filen .mdf eller .ndf.
De nya filerna tas bort i slutet av DBCC CHECKDB bearbetning. Dessa glesa filer som skapas av DBCC CHECKDB har attributen "Ta bort vid stängning" inställda.

Varning

Om operativsystemet stöter på en oväntad avstängning medan kommandot DBCC CHECKDB pågår rensas inte filerna. De tar upp utrymme och kan potentiellt orsaka fel vid framtida DBCC CHECKDB körningar. I så fall kan du ta bort dessa nya filer när du har bekräftat att det inte finns något DBCC CHECKDB kommando som körs för närvarande.

De nya filerna visas med vanliga filverktyg som Utforskaren.

Not

Före SQL Server 2014 (12.x) användes filströmmar i stället för att skapa de interna ögonblicksbildfilerna. De namngivna filströmmarna använde formatet <filename.extension>:MSSQL_DBCC<database_id_of_snapshot>. Namngivna filströmmar visas inte med vanliga filverktyg som Utforskaren. I SQL Server 2012 (11.x) och tidigare versioner kan det därför uppstå felmeddelanden 7926 och 5030 när du kör kommandot DBCC CHECKDB för databasfiler som finns på en ReFS--formaterad volym. Det beror på att filströmmar inte kan skapas på Resilient File System (RefS).

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 CHECKDB på en databas 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 CHECKDB att det finns en en-till-en-mappning mellan filsystemkataloger och filer och tabellrader, kolumner och kolumnvärden. DBCC CHECKDB kan reparera skador om du anger alternativet REPAIR_ALLOW_DATA_LOSS. För att reparera FILESTREAM-skada tar DBCC bort alla tabellrader som saknar filsystemdata.

Metodtips

Vi rekommenderar att du använder alternativet PHYSICAL_ONLY för frekvent användning i produktionssystem. Att använda PHYSICAL_ONLY kan avsevärt förkorta körningen för DBCC CHECKDB på stora databaser. Vi rekommenderar också att du regelbundet kör DBCC CHECKDB utan alternativ. Hur ofta du ska utföra dessa körningar beror på enskilda företag och deras produktionsmiljöer.

På Azure SQL Managed Instance måste det tillgängliga lagringsutrymmet rymma hela den interna databasögonblicksfilen som skapats av DBCC CHECKDB, oavsett hur mycket av den som faktiskt används av data. Detta kan leda till en situation där körningen av DBCC CHECKDB på en mycket stor men gles databas (storleken på data är mycket mindre än databasens filstorlek) misslyckas på grund av brist på utrymme på din SQL-hanterade instans. Om DBCC CHECKDB förbrukar allt tillgängligt lagringsutrymme under körningen får du följande felmeddelande:

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.

Kontrollera objekt parallellt

Som standard utför DBCC CHECKDB parallell kontroll av objekt. Graden av parallellitet bestäms automatiskt av frågeprocessorn. Den maximala graden av parallellitet konfigureras precis 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 Server-konfiguration: maximal grad av parallellitet. Parallell kontroll kan inaktiveras med hjälp av spårningsflagga 2528. Mer information finns i Spårningsflaggor.

Not

Den här funktionen är inte tillgänglig i varje utgåva 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 CHECKDB kommandot har slutförts skrivs ett meddelande till SQL Server-felloggen. Om DBCC-kommandot körs anger meddelandet att det lyckades 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 skada i metadata som avslutade DBCC-kommandot.
`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 skada i metadata som avslutade DBCC-kommandot.
`4`	En kontroll- eller åtkomstöverträdelse har identifierats.
`5`	Ett okänt fel uppstod som avslutade DBCC-kommandot.

SQL Server registrerar datum och tid när en konsekvenskontroll kördes för en databas utan fel (eller "ren" konsekvenskontroll). Detta kallas last known clean check. När en databas startas först skrivs det här datumet till EventLog (EventID-17573) och felloggen i följande format:

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.

Felrapportering

En stackdump (SQLDump<nnnn>.txt, SQLDump<nnnn>.log, SQLDump<nnnn>.mdmp) skapas i KATALOGEN SQL Server LOG när DBCC CHECKDB 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 CHECKDB och ytterligare diagnostiska utdata. Å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 några fel rapporteras av DBCC CHECKDBrekommenderar vi att du återställer databasen från databassäkerhetskopian i stället för att köra DBCC CHECKDB med något av de REPAIR_* alternativen. Om det inte finns någon säkerhetskopia korrigerar reparationen de fel som rapporterats. Reparationsalternativet 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 tas bort och därför vissa data.

Under vissa omständigheter kan värden anges i databasen som inte är giltiga eller utom räckhåll baserat på kolumnens datatyp. DBCC CHECKDB kan identifiera kolumnvärden som inte är giltiga för alla kolumndatatyper. Därför kan körning av DBCC CHECKDB med alternativet DATA_PURITY på databaser som har uppgraderats från tidigare versioner av SQL Server avslöja befintliga kolumnvärdesfel. Eftersom SQL Server inte automatiskt kan reparera dessa fel måste kolumnvärdet uppdateras manuellt. Om CHECKDB upptäcker ett sådant fel returnerar CHECKDB en varning, felnumret 2570 och information för att identifiera den berörda raden och korrigera felet manuellt.

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 reparationerna har slutförts säkerhetskopierar du databasen.

Lösa fel i databasens nödläge

När en databas har ställts in på nödläge med hjälp av instruktionen ALTER DATABASE kan DBCC CHECKDB utföra vissa särskilda reparationer på databasen om alternativet REPAIR_ALLOW_DATA_LOSS anges. Dessa reparationer kan göra det möjligt för normalt oåterkalleliga databaser att tas online igen i ett fysiskt konsekvent tillstånd. Dessa reparationer bör användas som en sista utväg och endast när du inte kan återställa databasen från en säkerhetskopia. När databasen är inställd på nödläge markeras databasen READ_ONLY, loggning är inaktiverad och åtkomsten är begränsad till medlemmar i sysadmin fast serverroll.

Not

Du kan inte köra kommandot DBCC CHECKDB i nödläge i en användartransaktion och återställa transaktionen efter körningen.

När databasen är i nödläge och DBCC CHECKDB med REPAIR_ALLOW_DATA_LOSS-satsen körs, vidtas följande åtgärder:

DBCC CHECKDB använder sidor som har markerats som otillgängliga på grund av I/O- eller kontrollsummafel, som om felen inte har inträffat. Detta ökar risken för dataåterställning från databasen.
DBCC CHECKDB försöker återställa databasen med hjälp av vanliga loggbaserade återställningstekniker.
Om databasåterställningen misslyckas på grund av skada i transaktionsloggen återskapas transaktionsloggen. Om du återskapar transaktionsloggen kan det leda till att transaktionskonsekvensen går förlorad.

Varning

Alternativet REPAIR_ALLOW_DATA_LOSS kan leda till mer dataförlust än om du återställer från en senast känd bra säkerhetskopia. Se Dataförlustvarning med REPAIR_ALLOW_DATA_LOSS

Om kommandot DBCC CHECKDB lyckas är databasen i ett fysiskt konsekvent tillstånd och databasstatusen är inställd på ONLINE. Databasen kan dock innehålla en eller flera transaktionella inkonsekvenser. Vi rekommenderar att du kör DBCC CHECKCONSTRAINTS- för att identifiera eventuella affärslogikfel och omedelbart säkerhetskopiera databasen.

Om kommandot DBCC CHECKDB misslyckas kan databasen inte repareras.

Dataförlustvarning med REPAIR_ALLOW_DATA_LOSS

Alternativet REPAIR_ALLOW_DATA_LOSS är en funktion som stöds i SQL Server. Det kanske dock inte alltid är det bästa alternativet för att föra en databas till ett fysiskt konsekvent tillstånd. Om det lyckas kan alternativet REPAIR_ALLOW_DATA_LOSS resultera i viss dataförlust.

I själva verket kan det leda till att mer data går förlorade än om en användare skulle återställa databasen från den senast kända goda säkerhetskopian. Microsoft rekommenderar alltid en användaråterställning från den senast kända bra säkerhetskopieringen som den primära metoden för att återställa från fel som rapporterats av DBCC CHECKDB.

Alternativet REPAIR_ALLOW_DATA_LOSS är inte ett alternativ för att återställa från en känd bra säkerhetskopia. Det är en nödsituation sista utväg alternativ som rekommenderas endast för användning om återställning från en säkerhetskopia är inte möjligt.

När loggen har återskapats finns det ingen fullständig ACID-garanti.

När loggen har återskapats utförs DBCC CHECKDB automatiskt och både rapporter och korrigerar problem med fysisk konsekvens.

Logisk datakonsekvens och affärslogik framtvingade begränsningar måste verifieras manuellt.

Transaktionsloggens storlek lämnas till standardstorleken och måste justeras manuellt tillbaka till den senaste storleken.

Kör DBCC CHECKDB med REPAIR_ALLOW_DATA_LOSS i replikerade databaser

Om du kör kommandot DBCC CHECKDB med alternativet REPAIR_ALLOW_DATA_LOSS kan det påverka användardatabaser (publicerings- och prenumerationsdatabaser) och distributionsdatabasen som används av replikeringen. Publikations- och prenumerationsdatabaser innehåller publicerade tabeller och metadatatabeller för replikering. Tänk på följande potentiella problem i dessa databaser:

Publicerade tabeller. Åtgärder som utförs av CHECKDB för att reparera skadade användardata kanske inte replikeras:
Sammanslagningsreplikering använder utlösare för att spåra ändringar i publicerade tabeller. Om rader infogas, uppdateras eller tas bort av CHECKDB processen utlöses inte utlösare. Därför replikeras inte ändringen.
Transaktionsreplikering använder transaktionsloggen för att spåra ändringar i publicerade tabeller. Loggläsaragenten flyttar sedan ändringarna till distributionsdatabasen. Vissa DBCC-reparationer, även om de är loggade, kan inte replikeras av Log Reader Agent. Om en datasida till exempel frigörs av den CHECKDB processen översätter log reader-agenten inte den här friställningen till en DELETE-instruktion. Därför replikeras inte ändringen.
Metadatatabeller för replikering. Åtgärder som utförs av CHECKDB för att reparera skadade metadatatabeller för replikering kräver att replikering tas bort och konfigureras om.

Om du måste köra kommandot DBCC CHECKDB med alternativet REPAIR_ALLOW_DATA_LOSS på en användardatabas eller distributionsdatabas:

Quiesce systemet: Stoppa aktiviteten på databasen och vid alla andra databaser i replikeringstopologin och försök sedan synkronisera alla noder. Mer information finns i Quiesce a Replication Topology (Replication Transact-SQL Programming).
Kör DBCC CHECKDB.
Om DBCC CHECKDB rapporten innehåller reparationer för tabeller i distributionsdatabasen eller eventuella metadatatabeller för replikering i en användardatabas tar du bort och konfigurerar om replikeringen. Mer information finns i Inaktivera publicering och distribution.
Om DBCC CHECKDB rapporten innehåller reparationer för replikerade tabeller utför du dataverifiering för att avgöra om det finns skillnader mellan data i publikations- och prenumerationsdatabaserna.

Resultatuppsättning

DBCC CHECKDB returnerar följande resultatuppsättning. Värdena kan variera förutom när alternativen ESTIMATEONLY, PHYSICAL_ONLYeller NO_INFOMSGS anges:

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 returnerar följande resultatuppsättning (meddelande) när NO_INFOMSGS anges:

The command(s) completed successfully.

DBCC CHECKDB returnerar följande resultatuppsättning när PHYSICAL_ONLY anges:

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 returnerar följande resultatuppsättning när ESTIMATEONLY anges.

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.

Behörigheter

Kräver medlemskap i sysadmin fast serverroll eller db_owner fast databasroll.

Exempel

A. Kontrollera både den aktuella och en annan databas

I följande exempel körs DBCC CHECKDB för den aktuella databasen och för den AdventureWorks2022 databasen.

-- Check the current database.
DBCC CHECKDB;
GO

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

B. Kontrollera den aktuella databasen och ignorera informationsmeddelanden

I följande exempel kontrolleras den aktuella databasen och alla informationsmeddelanden ignoreras.

DBCC CHECKDB WITH NO_INFOMSGS;
GO

Dela via

DBCC CHECKDB (Transact-SQL)

Syntax

Argument

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Anmärkningar

Utföra logiska konsekvenskontroller på index

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

Intern databasögonblicksbild

Hur DBCC CHECKDB skapar en intern ögonblicksbilddatabas som börjar med SQL Server 2014

Kontrollera och reparera FILESTREAM-data

Metodtips

Kontrollera objekt parallellt

Förstå DBCC-felmeddelanden

Felrapportering

Lösa fel

Lösa fel i databasens nödläge

Dataförlustvarning med REPAIR_ALLOW_DATA_LOSS

Kör DBCC CHECKDB med REPAIR_ALLOW_DATA_LOSS i replikerade databaser

Resultatuppsättning

Behörigheter

Exempel

A. Kontrollera både den aktuella och en annan databas

B. Kontrollera den aktuella databasen och ignorera informationsmeddelanden

Feedback

Ytterligare resurser

Dela via

DBCC CHECKDB (Transact-SQL)

Syntax

Argument

database_name | database_id | 0

NOINDEX

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

ALL_ERRORMSGS

EXTENDED_LOGICAL_CHECKS

NO_INFOMSGS

TABLOCK

ESTIMATEONLY

PHYSICAL_ONLY

DATA_PURITY

MAXDOP

Anmärkningar

Utföra logiska konsekvenskontroller på index

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

Intern databasögonblicksbild

Hur DBCC CHECKDB skapar en intern ögonblicksbilddatabas som börjar med SQL Server 2014

Kontrollera och reparera FILESTREAM-data

Metodtips

Kontrollera objekt parallellt

Förstå DBCC-felmeddelanden

Felrapportering

Lösa fel

Lösa fel i databasens nödläge

Dataförlustvarning med REPAIR_ALLOW_DATA_LOSS

Kör DBCC CHECKDB med REPAIR_ALLOW_DATA_LOSS i replikerade databaser

Resultatuppsättning

Behörigheter

Exempel

A. Kontrollera både den aktuella och en annan databas

B. Kontrollera den aktuella databasen och ignorera informationsmeddelanden

Relaterat innehåll

Feedback

Ytterligare resurser