Dela via

Felsök fel med databaskonsekvens som rapporteras av DBCC CHECKDB

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

Ursprunglig produktversion: SQL Server
Ursprungligt KB-nummer: 2015748

Symptom

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 börjar med "intern databasögonblicksbild..." visas bara om DBCC CHECKDB den kördes online, där databasen inte är i SINGLE_USER läget . Detta beror på att för en online DBCC CHECKDBanvänds en intern databasögonblicksbild för att presentera en konsekvent uppsättning data som ska kontrolleras.

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 konsekvensen 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 rotorsaken till rapporterade fel finns i Undersöka rotorsaken.

Åtgärd

  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-sökvägen (lokal dator, enhetsdrivrutiner, nätverkskort för lagring, SAN, serverdelslagring 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-sökvägen. Mer information om hur du undersöker rotorsaken finns i Undersöka rotorsaken.

  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älla och återställa.

  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. I dokumentationen för kumulativ uppdatering eller Service Pack finns kända problem som har åtgärdats som rör databasskada (konsekvensfel) och tillämpa eventuella relevanta korrigeringar. En central plats där du kan söka efter alla korrigeringar för en viss version om detaljerade korrigeringslistor 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 underhållarna av I/O-sökvä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 du en funktion för att reparera fel som du kan använda. Det finns två reparationsnivåer:

    • REPAIR_REBUILD – utför reparationer som inte har någon möjlighet till 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 den 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 en säkerhetskopia eller reparation återställs. 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 konsekvensfel i databasen "mydb".
    REPAIR_ALLOW_DATA_LOSS är den lägsta reparationsnivån för felen som hittas av DBCC CHECKDB (mydb).

    Reparationsrekommendationen är den minsta reparationsnivån för att försöka 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. Alla rapporterade fel kräver inte att den här reparationsnivån används. Det innebär att inte alla reparationer med CHECKDBREPAIR_ALLOW_DATA_LOSS resulterar i dataförlust. Reparation måste köras för att avgöra om lösningen på ett fel resulterar i dataförlust. En teknik som hjälper dig att begränsa 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 när CHECKDB reparationen eller dataexporten eller importen har slutförts. Mer information finns i DBCC CHECKDB-argument. Data kanske inte är logiskt konsekventa efter reparationen. Reparation (särskilt REPAIR_ALLOW_DATA_LOSS alternativ) kan till exempel ta bort hela datasidor som innehåller inkonsekventa data. I sådana fall kan en tabell med en sekundärnyckelrelation till en annan tabell sluta med rader som inte har motsvarande primärnyckelrader i den överordnade tabellen.

  6. Försök att skriva ut databasschemat. Använd skriptet för att skapa en ny databas och använd sedan ett verktyg som BCP eller guiden Exportera/importera SSIS 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öka rotorsaken 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.
  • Kontakta maskinvaruleverantören eller enhetstillverkaren för att se till att:
    • Maskinvaruenheterna och konfigurationen bekräftar kraven för In-/utdata för Microsoft SQL Server Database Engine.
    • Enhetsdrivrutinerna och andra stödprogramkomponenter för alla enheter i I/O-sökvägen är uppdaterade.
  • Överväg att använda ett verktyg som SQLIOSim på den enhet där databaserna som har rapporterat konsekvensfelen 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 .
  • I dokumentationen för kumulativ uppdatering eller Service Pack finns kända problem som har åtgärdats som rör databasskada (konsekvensfel) och tillämpa eventuella relevanta korrigeringar. En central plats där du kan söka efter alla korrigeringar för en viss version om detaljerade korrigeringslistor för SQL Server 2022, 2019, 2017.
  • Sök efter andra fel som rapporterats av SQL Server, till exempel åtkomstöverträdelser eller intyg. Aktivitet mot skadade databaser resulterar ofta i undantag för åtkomstöverträdelser eller kontrollfel.
  • Kontrollera att databaserna använder alternativet PAGE_VERIFY CHECKSUM . Om kontrollsummafel rapporteras är detta en indikation på att konsekvensfelen 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 meddelande 832-fel i ERRORLOG. Dessa fel kan tyda på att sidor kan skadas 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öker du återställa en säkerhetskopia av databasen som du vet är "ren" (inga fel från CHECKDB) följt av säkerhetskopieringar av transaktionsloggar 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 säkerhetskopiering av transaktionsloggar 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 datarenhetsfel finns i Felsöka DBCC-fel 2570 i SQL Server 2005.
  • Kontrollera filsystemets integritet med hjälp av kommandot chkdsk . Kör chkdsk inte 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 kan flytta filbyte till en annan plats på disken, och en sådan förflyttning kan leda till skada 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 hittas 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 CHECKDBav 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 i historiska syften eftersom den innehåller en lista över de fel som hittas 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 rensningen CHECKDB) kontrollerar du SQL Server ERRORLOG. Leta efter ett meddelande som liknar följande för en användare 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 for database 'master' finished without errors on Date/Time22:11:11.417 (lokal tid). Detta är endast ett informationsmeddelande. ingen användaråtgärd krävs