Felsök fel med databaskonsekvens som rapporteras av DBCC CHECKDB

I den här artikeln beskrivs hur du felsöker fel som rapporterats av kommandot DBCC CHECKDB.

Ursprunglig produktversion: SQL Server
Ursprungligt KB-nummer: 2015748

Symtom

När DBCC CHECKDB (eller andra liknande kommandon som DBCC CHECKTABLE) körs skrivs ett meddelande som följande till SQL Server-felloggen:

DBCC CHECKDB (mydb) executed by MYDOMAIN\theuser found 15 errors and repaired 3 errors.
Elapsed time: 0 hours 0 minutes 0 seconds.
Internal database snapshot has split point LSN = 00000026:0000089d:0001 and first LSN = 00000026:0000089c:0001.
This is an informational message only. No user action is required.

Det här meddelandet visar hur många databaskonsekvensfel som hittades och hur många som reparerades, om ett reparationsalternativ användes. Det här meddelandet skrivs också till Händelseloggen för Windows-program som ett meddelande på informationsnivå med EventID=8957. Även om fel rapporteras är det här meddelandet ett meddelande på informationsnivå.

Informationen i meddelandet som börjar med "intern databassnapshot..." visas bara om DBCC CHECKDB kördes online, där databasen inte är i SINGLE_USER-läget. Detta beror på att för en online DBCC CHECKDB används en intern databas-snapshot för att visa en konsekvent datamängd att kontrollera.

Den här artikeln beskriver inte hur du felsöker varje specifikt fel som rapporteras av DBCC CHECKDB , utan snarare den allmänna metoden om fel rapporteras. Alla referenser till CHECKDB i den här artikeln gäller även för DBCC CHECKTABLE och DBCC CHECKFILEGROUP om inget annat anges.

Orsak

Kommandot DBCC CHECKDB kontrollerar den fysiska och logiska konsistensen för databassidor, rader, allokeringssidor, indexrelationer, systemtabellens referensintegritet och andra strukturkontroller. Om någon av dessa kontroller misslyckas (beroende på vilka alternativ du har valt) rapporteras fel.

Orsaken till dessa problem kan vara allt från skadade filsystem, underliggande maskinvarusystemproblem, drivrutinsproblem, skadade sidor i minne eller lagringscacheminne eller problem med SQL Server. Information om hur du identifierar den grundläggande orsaken till rapporterade fel finns i Undersök rotorsaken.

Upplösning

  1. Lös eventuella underliggande maskinvarurelaterade problem i systemet innan du fortsätter med att återställa en säkerhetskopia eller på annat sätt reparera databasen. Tillämpa alla enhetsdrivrutiner, inbyggd programvara, BIOS och operativsystemuppdateringar som är relevanta för I/O-sökvägen. Arbeta med administratören för den fullständiga I/O-vägen (lokal dator, enhetsdrivrutiner, nätverkskort för lagring, SAN, bakändeslagring och cache) och minne (RAM) för att isolera och lösa eventuella problem. Exempel är att uppdatera enhetsdrivrutiner och kontrollera konfigurationen av hela I/O-kedjan. Mer information om hur du undersöker grundorsaken finns i Undersöka grundorsaken.

  2. Om DBCC CHECKDB rapporterar permanenta konsekvensfel är den bästa lösningen att återställa data från en känd bra säkerhetskopia. Mer information finns i Återställning och återhämtning.

  3. Använd den senaste kumulativa uppdateringen av SQL Server eller Service Pack för att se till att du inte stöter på några kända problem. Kontrollera dokumentationen för kumulativ uppdatering eller Service Pack för eventuella kända problem som har åtgärdats och som rör databasskada (konsistensfel), och tillämpa eventuella relevanta korrigeringar. En central plats där du kan söka efter alla korrigeringar för en viss version i de detaljerade korrigeringslistorna för SQL Server 2022, 2019, 2017.

  4. Om felen DBCC CHECKDB är tillfälliga, dvs om de visas vid en körning och försvinner i nästa, kan du stöta på problem med diskcache (antingen enhetsdrivrutin eller annat I/O-sökvägsproblem). Arbeta med de ansvariga för I/O-vägen för att isolera och lösa eventuella problem. Exempel är att uppdatera enhetsdrivrutiner, kontrollera konfigurationen av hela I/O-sökvägen och uppdatera inbyggd programvara och BIOS på I/O-sökvägsenheterna och systemet.

  5. Om det inte går att återställa från en säkerhetskopia, har CHECKDB en funktion för att reparera fel som du kan använda. Det finns två reparationsnivåer:

    • REPAIR_REBUILD – utför reparationer utan risk för dataförlust.
    • REPAIR_ALLOW_DATA_LOSS – utför reparationer som kan leda till dataförlust.

    Mer information finns i dokumentationen för DBCC CHECKDB.

    Du måste vara försiktig när du väljer att reparera med tillåten dataförlust eftersom det kan lämna databasen i ett logiskt inkonsekvent tillstånd. Utdata DBCC CHECKDB ger en rekommendation om den minsta reparationsnivå som ska användas. Det är vanligt att köra CHECKDB med REPAIR_ALLOW_DATA_LOSS flera gånger tills inga fler fel rapporteras. Detta beror på att när reparationen åtgärdar en uppsättning fel kan andra brutna kopplingar upptäckas. Nya fel kan dock visas om den underliggande orsaken inte har lösts. Om problem på systemnivå, till exempel maskinvara eller filsystem, orsakar skada på data, måste dessa problem därför åtgärdas först innan återställning från en säkerhetskopia eller reparation utförs. Microsofts supporttekniker kan inte hjälpa till med fysisk återställning av skadade data om reparationen inte åtgärdar konsekvensfelen eller om databassäkerhetskopian är skadad.

    När du kör DBCC CHECKDBges en rekommendation som anger det minsta reparationsalternativ som krävs för att reparera alla fel. Dessa meddelanden liknar följande utdata:

    CHECKDB hittade 0 allokeringsfel och 15 konsistensfel i databasen 'mydb'.
    REPAIR_ALLOW_DATA_LOSS är den minsta reparationsnivån för de fel som hittas av DBCC CHECKDB (mydb).

    Rekommenderad reparation är den lägsta reparationsnivå som bör försökas för att lösa alla fel från CHECKDB. Den minsta reparationsnivån innebär inte att det här reparationsalternativet åtgärdar alla fel. Vissa fel kan helt enkelt inte åtgärdas. Du kan också behöva köra reparationsprocessen mer än en gång. Inte alla rapporterade fel kräver att den här reparationsnivån används. Det innebär att inte alla reparationer av CHECKDB med REPAIR_ALLOW_DATA_LOSS resulterar i dataförlust. Reparera måste köras för att avgöra om åtgärden av ett fel resulterar i dataförlust. En teknik som hjälper dig att fastställa reparationsnivån för varje tabell är att använda DBCC CHECKTABLE för alla tabeller som rapporterar ett fel. Detta visar den lägsta reparationsnivån för en viss tabell.

    Varning

    Du måste utföra manuell dataverifiering efter att CHECKDB reparation eller dataexport eller import har slutförts. Mer information finns i avsnittet argument för DBCC CHECKDB. Data kanske inte är logiskt konsistent efter korrigeringen. Till exempel kan reparera (särskilt alternativet REPAIR_ALLOW_DATA_LOSS) ta bort hela datasidor som innehåller inkonsekventa data. I sådana fall kan en tabell med en främmande nyckelrelation till en annan tabell sluta med rader som inte har motsvarande primärnyckelrader i den överordnade tabellen.

  6. Försök att skripta databasschemat. Använd skriptet för att skapa en ny databas och använd sedan ett verktyg som BCP eller SSIS-guiden Exportera/importera för att exportera så mycket av data som möjligt från den skadade databasen till den nya databasen. Det är troligt att det inte går att exportera data från en skadad tabell. I sådana fall hoppar du över den här tabellen, går vidare till nästa och sparar det du kan.

  7. Granska följande artiklar för specifika fel som genereras av DBCC CHECKDB och följ de angivna stegen (om det finns några). Nedan följer några exempel:

Undersök grundorsaken till databaskonsekvensfel

Tänk på följande metoder för att identifiera rotorsaken till databaskonsekvensfel:

  • Kontrollera händelseloggen för Windows-system för eventuella systemnivå-, drivrutins- eller diskrelaterade fel och arbeta med maskinvarutillverkaren för att lösa dem.
  • Kör diagnostik som tillhandahålls av maskinvarutillverkarna för datorn och/eller disksystemet. De flesta system tillhandahåller inbyggd BIOS/UEFI-diagnostik för lagring (hårddiskar), minne, processorer, systemkort, RAID-matriser och flera andra komponenter.
  • Samarbeta med maskinvaruleverantören eller enhetstillverkaren för att se till att:
  • Överväg att använda ett verktyg som SQLIOSim på den enhet där de databaser för vilka konsekvensfelen har rapporterats finns. SQLIOSim är ett verktyg som är oberoende av SQL Server Engine för att testa integriteten för I/O för disksystemet. SQLIOSim levereras med SQL Server och kräver ingen separat nedladdning. Den finns i mappen \MSSQL\Binn.
  • Kontrollera dokumentationen för kumulativ uppdatering eller Service Pack för eventuella kända problem relaterade till databasskada (konsistensfel) som har åtgärdats och tillämpa eventuella relevanta korrigeringar. En central plats där du kan söka efter alla korrigeringar för en viss version finns i de detaljerade korrigeringslistorna för SQL Server 2022, 2019, 2017.
  • Sök efter andra fel som rapporterats av SQL Server, till exempel åtkomstöverträdelser eller assertioner. Aktivitet mot skadade databaser resulterar ofta i undantag för åtkomstöverträdelser eller assertionsfel.
  • Se till att databaserna använder alternativet PAGE_VERIFY CHECKSUM. Om kontrollsummafel rapporteras är detta en indikation på att konsistensfelen har inträffat efter att SQL Server skrev sidor till disken. Därför bör ditt I/O-undersystem kontrolleras noggrant. Mer information om kontrollsummor finns i Felsöka Msg 824 i SQL Server.
  • Leta efter fel för meddelande 832 i ERRORLOG. Dessa fel kan tyda på att sidor kan vara skadade medan de finns i cacheminnet innan de skrivs till disken. Mer information finns i Felsöka Msg 832 i SQL Server.
  • På ett annat system, försök att återställa en säkerhetskopia av databasen som du vet är "ren" (inga fel från CHECKDB) följt av säkerhetskopior av transaktionsloggen som sträcker sig över tiden då felet genererades. Om du kan "återskapa" det här problemet genom att återställa en "ren" databassäkerhetskopia och en säkerhetskopia av transaktionsloggen kontaktar du Microsofts tekniska support om du behöver hjälp.
  • datarenhetsfel kan vara ett problem när programmet infogar eller uppdaterar ogiltiga data i SQL Server-tabeller. Mer information om hur du felsöker Data Purity-fel finns i Felsöka DBCC-fel 2570 i SQL Server 2005.
  • Kontrollera filsystemets integritet med hjälp av kommandot chkdsk. chkdsk när SQL Server körs. Det kan rapportera tillfälliga filfel om SQL Server skriver till de filer som kontrolleras. Dessutom kan växlar som /r eller /f flytta filens byte till en annan plats på disken, och en sådan förflyttning kan leda till korruption om SQL Server också skriver till eller läser från dessa filer. Se därför till att stoppa SQL Server innan du kör chkdsk kommandot. Var också försiktig med reparationsalternativ som /r och /f. Kontrollera att du har en säkerhetskopia av dina databaser innan du kör en reparation, eftersom dessa alternativ kan skada filerna om diskfel upptäcks av chkdsk.

Mer information

Mer information om syntaxen för DBCC CHECKDB och information eller alternativ om hur du kör kommandot finns i DBCC CHECKDB (Transact-SQL).

Om några fel hittas med hjälp av CHECKDB, rapporteras andra meddelanden som liknar följande meddelande i ERRORLOG för felrapportering:

**Dump thread - spid = 0, EC = 0x00000000855F5EB0
***Stack Dump being sent toFilePath\FileName
* ******************************************************************************
*
* BEGIN STACK DUMP:
*  Date/Timespid 53
*
* DBCC database corruption
*
* Input Buffer 84 bytes -
*             dbcc checkdb(mydb)
*
* *******************************************************************************
*   -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000001E8
External dump process return code 0x20002001.

Felinformationen har skickats till Watsons felrapportering.

Filerna som används för felrapportering innehåller en SQLDump<nnn>.txt fil. Den här filen kan vara användbar för historiska ändamål eftersom den innehåller en lista över de fel som hittas från CHECKDB i ett XML-format.

Om du vill ta reda på den senaste gången DBCC CHECKDB kördes utan fel som identifierats för en databas (den senast kända felfria körningen CHECKDB) kontrollerar du SQL Server ERRORLOG. Leta efter ett meddelande som liknar följande i en användar- eller systemdatabas. Det här meddelandet skrivs som ett meddelande på informationsnivå i händelseloggen för Windows-program med EventID = 17573 också):

Date/Time spid7s CHECKDB för databasen 'master' slutfördes utan fel den Date/Time22:11:11.417 (lokal tid). Detta är endast ett informationsmeddelande. Ingen användaråtgärd krävs

  • Uppdaterades senast