Problemen met databaseconsistentiefouten, gerapporteerd door DBCC CHECKDB, oplossen

In dit artikel wordt uitgelegd hoe u fouten oplost die zijn gerapporteerd door de DBCC CHECKDB opdracht.

Oorspronkelijke productversie: SQL Server
Oorspronkelijk KB-nummer: 2015748

Symptomen

Wanneer DE DBCC CHECKDB (of andere vergelijkbare opdrachten zoals DBCC CHECKTABLE) wordt uitgevoerd, wordt een bericht zoals de volgende naar het FOUTENlogboek van SQL Server geschreven:

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.

Dit bericht laat zien hoeveel databaseconsistentiefouten zijn gevonden en hoeveel zijn hersteld, als er een hersteloptie is gebruikt. Dit bericht wordt ook naar het Windows-toepassingslogboek geschreven als een bericht op informatieniveau met EventID=8957. Zelfs als er fouten worden gerapporteerd, is dit bericht een bericht op informatieniveau.

De informatie in het bericht dat begint met 'momentopname van interne database...' wordt alleen weergegeven als DBCC CHECKDB online is uitgevoerd, wanneer de database niet in de SINGLE_USER-modus staat. Dit komt doordat voor een online DBCC CHECKDB een momentopname van een interne database wordt gebruikt om een consistente set gegevens weer te geven die moeten worden gecontroleerd.

In dit artikel wordt niet besproken hoe u elke specifieke fout oplost die door DBCC CHECKDB wordt gerapporteerd, maar wordt eerder de algemene aanpak besproken als er fouten worden gemeld. Elke verwijzing naar CHECKDB in dit artikel is ook van toepassing op DBCC CHECKTABLE en DBCC CHECKFILEGROUP , tenzij vermeld.

Oorzaak

De DBCC CHECKDB opdracht controleert de fysieke en logische consistentie van databasepagina's, rijen, toewijzingspagina's, indexrelaties, referentiële integriteit van de systeemtabel en andere structuurcontroles. Als een van deze controles mislukt (afhankelijk van de opties die u hebt gekozen), worden fouten gerapporteerd.

De oorzaak van deze problemen kan variëren van beschadiging van het bestandssysteem, onderliggende problemen met het hardwaresysteem, stuurprogrammaproblemen, beschadigde pagina's in het geheugen of de opslagcache of problemen met de SQL Server. Zie Hoofdoorzaak onderzoeken voor informatie over het identificeren van de hoofdoorzaak van gerapporteerde fouten.

Resolutie

  1. Los eventuele onderliggende hardwareproblemen op het systeem op voordat u doorgaat met het herstellen van een back-up of het anderszins herstellen van de database. Pas alle apparaatstuurprogramma's, firmware, BIOS en besturingssysteemupdates toe die relevant zijn voor het I/O-pad. Werk samen met de beheerder van het volledige I/O-pad (lokale computer, apparaatstuurprogramma's, opslag-NIC's, SAN, back-endopslag en cache) en geheugen (RAM) om eventuele problemen te isoleren en op te lossen. Voorbeelden hiervan zijn het bijwerken van apparaatstuurprogramma's en het controleren van de configuratie van het volledige I/O-pad. Zie Hoofdoorzaak onderzoeken voor meer informatie over het onderzoeken van de hoofdoorzaak.

  2. Als DBCC CHECKDB permanente consistentiefouten meldt, is het de beste oplossing om gegevens te herstellen vanaf een bekende goede back-up. Zie Terugzetten en herstel voor meer informatie.

  3. Pas de meest recente cumulatieve SQL Server-update of het meest recente servicepack toe om ervoor te zorgen dat u geen bekende problemen ondervindt. Raadpleeg de documentatie over cumulatieve updates of servicepacks voor bekende problemen die zijn opgelost met betrekking tot databasebeschadiging (consistentiefouten) en pas eventuele relevante oplossingen toe. Eén centrale locatie waar u kunt zoeken naar alle oplossingen voor een bepaalde versie, namelijk de gedetailleerde oplossingslijsten voor SQL Server 2022, 2019, 2017.

  4. Als de DBCC CHECKDB fouten af en toe optreden, dat wil zeggen: als ze in de ene run verschijnen en in de volgende verdwijnen, ondervindt u mogelijk problemen met de schijfcache (een probleem met het apparaatstuurprogramma of een ander I/O-pad). Werk samen met de onderhouders van het I/O-pad om eventuele problemen te isoleren en op te lossen. Voorbeelden zijn het bijwerken van apparaatstuurprogramma's, het controleren van de configuratie van het volledige I/O-pad en het bijwerken van firmware en BIOS op de I/O-padapparaten en het systeem.

  5. Als het niet mogelijk is om vanuit een back-up te herstellen, heeft CHECKDB een functie voor het herstellen van fouten die u kunt gebruiken. Er zijn twee reparatieniveaus:

    • REPAIR_REBUILD - voert reparaties uit waarbij geen kans op gegevensverlies bestaat.
    • REPAIR_ALLOW_DATA_LOSS - voert reparaties uit die de mogelijkheid van gegevensverlies hebben.

    Zie de DBCC CHECKDB-documentatie voor meer informatie.

    U moet voorzichtig zijn bij het kiezen van de optie Herstellen met gegevensverlies toestaan, omdat uw database mogelijk in een logisch inconsistente status blijft. De DBCC CHECKDB uitvoer doet een aanbeveling over het minimale herstelniveau dat moet worden gebruikt. Het is gebruikelijk om CHECKDB met REPAIR_ALLOW_DATA_LOSS meerdere keren uit te voeren totdat er geen fouten meer worden gerapporteerd. Dit komt doordat wanneer de reparatie een reeks fouten oplost, andere verbroken koppelingen mogelijk worden ontdekt. Nieuwe fouten kunnen echter optreden als de onderliggende oorzaak niet is opgelost. Als problemen op systeemniveau, zoals hardware of bestandssysteem, gegevensbeschadiging veroorzaken, moeten deze problemen daarom eerst worden opgelost voordat een back-up wordt teruggezet of een herstelbewerking wordt uitgevoerd. Microsoft-ondersteuningstechnici kunnen niet helpen bij het fysiek herstellen van beschadigde gegevens als de reparatie de consistentiefouten niet oplost of als de databaseback-up beschadigd is.

    Wanneer u DBCC CHECKDB uitvoert, wordt een aanbeveling gegeven om aan te geven welke minimale hersteloptie vereist is om alle fouten te herstellen. Deze berichten lijken op de volgende uitvoer:

    CHECKDB heeft 0 toewijzingsfouten en 15 consistentiefouten in database 'mydb' aangetroffen.
    REPAIR_ALLOW_DATA_LOSS is het minimale herstelniveau voor de fouten die zijn gevonden door DBCC CHECKDB (mydb).

    De aanbeveling voor herstel is het minimale herstelniveau om te proberen alle fouten uit CHECKDB op te lossen. Het minimale herstelniveau betekent niet dat met deze hersteloptie alle fouten worden opgelost. Sommige fouten kunnen gewoon niet worden opgelost. Mogelijk moet u het reparatieproces ook meerdere keren uitvoeren. Niet alle gerapporteerde fouten vereisen dit herstelniveau om te worden opgelost. Dit betekent dat niet alle reparaties door CHECKDB met REPAIR_ALLOW_DATA_LOSS tot gegevensverlies leiden. Reparatie moet worden uitgevoerd om te bepalen of de oplossing voor een fout resulteert in gegevensverlies. Eén techniek om te bepalen wat het herstelniveau is voor elke tabel is om DBCC CHECKTABLE te gebruiken voor elke tabel die een fout rapporteert. Hier ziet u het minimale herstelniveau voor een bepaalde tabel.

    Waarschuwing

    U moet handmatige gegevensvalidatie uitvoeren nadat de CHECKDBreparatie of het exporteren of importeren van gegevens is voltooid. Zie DBCC CHECKDB-argumenten voor meer informatie. De gegevens zijn mogelijk niet logisch consistent na de reparatie. Herstellen (met name REPAIR_ALLOW_DATA_LOSS optie) kan bijvoorbeeld hele gegevenspagina's verwijderen die inconsistente gegevens bevatten. In dergelijke gevallen kan een tabel met een refererende-sleutelrelatie met een andere tabel eindigen met rijen die geen overeenkomende primaire-sleutelrijen in de bovenliggende tabel hebben.

  6. Probeer het databaseschema als script te genereren. Gebruik het script om een nieuwe database te maken en gebruik vervolgens een hulpprogramma zoals BCP of SSIS Export/Import Wizard om zoveel mogelijk gegevens uit de beschadigde database naar de nieuwe database te exporteren. Het exporteren van gegevens uit een beschadigde tabel mislukt waarschijnlijk. In dergelijke gevallen slaat u deze tabel over, gaat u naar de volgende en slaat u op wat u kunt.

  7. Bekijk de volgende artikelen voor specifieke fouten die zijn gegenereerd door DBCC CHECKDB en volg de opgegeven stappen (indien van toepassing). Hieronder volgen een aantal voorbeelden:

Onderzoek de oorzaak van databaseconsistentiefouten

Als u de hoofdoorzaak van databaseconsistentiefouten wilt identificeren, kunt u de volgende methoden overwegen:

  • Controleer het Windows-systeemgebeurtenislogboek op eventuele systeem-, stuurprogramma- of schijfgerelateerde fouten en werk samen met de hardwarefabrikant om deze op te lossen.
  • Voer eventuele diagnoseprogramma's van uw hardwarefabrikanten uit voor de computer en/of het schijfsysteem. De meeste systemen bieden ingebouwde BIOS/UEFI-diagnostiek voor opslag (harde schijven), geheugen, CPU's, systeemborden, RAID-matrices en meerdere andere onderdelen.
  • Neem contact op met uw hardwareleverancier of apparaatfabrikant om ervoor te zorgen dat:
  • Overweeg het gebruik van een hulpprogramma zoals SQLIOSim op het station waar de databases zich bevinden waarvoor consistentiefouten zijn gemeld. SQLIOSim is een hulpprogramma dat onafhankelijk is van de SQL Server Engine om de integriteit van I/O voor het schijfsysteem te testen. SQLIOSim wordt geleverd met SQL Server en vereist geen afzonderlijke download. U vindt deze in de map \MSSQL\Binn .
  • Raadpleeg de documentatie voor cumulatieve updates of servicepacks voor bekende problemen die zijn opgelost met betrekking tot databasebeschadiging (consistentiefouten) en pas eventuele relevante oplossingen toe. Eén centrale locatie waar u kunt zoeken naar alle oplossingen voor een bepaalde versie in de gedetailleerde oplossingslijsten voor SQL Server 2022, 2019, 2017.
  • Controleer op andere fouten die zijn gerapporteerd door SQL Server, zoals toegangsschendingen of asserties. Bewerkingen op beschadigde databases resulteren vaak in toegangsschending-uitzonderingen of assertiefouten.
  • Zorg ervoor dat uw databases de PAGE_VERIFY CHECKSUM optie gebruiken. Als er controlesomfouten worden gerapporteerd, is dit een indicatie dat de consistentiefouten zijn opgetreden nadat SQL Server pagina's naar schijf heeft geschreven. Daarom moet uw I/O-subsysteem grondig worden gecontroleerd. Zie Problemen met Msg 824 in SQL Server oplossen voor meer informatie over controlesomfouten.
  • Zoek naar fouten van bericht 832 in de ERRORLOG. Deze fouten kunnen erop wijzen dat pagina's mogelijk beschadigd raken terwijl ze zich in de cache bevinden, voordat ze naar de schijf worden geschreven. Zie Problemen met Msg 832 in SQL Server oplossen voor meer informatie.
  • Probeer op een ander systeem een databaseback-up te herstellen waarvan u weet dat deze 'schoon' is (geen fouten van CHECKDB), gevolgd door back-ups van transactielogboeken die de periode bestrijken waarin de fout werd gegenereerd. Als u dit probleem opnieuw kunt maken door een 'schone' databaseback-up en back-up van transactielogboeken te herstellen, neemt u contact op met de technische ondersteuning van Microsoft voor hulp.
  • Data Purity-fouten kunnen een probleem zijn doordat de toepassing ongeldige gegevens in SQL Server-tabellen invoegt of bijwerkt. Zie Problemen met DBCC-fout 2570 in SQL Server 2005 oplossen voor meer informatie over het oplossen van Data Purity-fouten.
  • Controleer de integriteit van het bestandssysteem met behulp van de opdracht chkdsk. Startchkdsk niet terwijl SQL Server wordt uitgevoerd. Er kunnen tijdelijke bestandsfouten worden gerapporteerd als SQL Server naar de bestanden schrijft die worden gecontroleerd. Schakelopties zoals /r of /f kunnen bestand bytes verplaatsen naar een andere locatie op schijf, en dergelijke verplaatsing kan leiden tot beschadiging als SQL Server ook naar deze bestanden schrijft of leest. Zorg er daarom voor dat u SQL Server stopt voordat u de chkdsk opdracht uitvoert. Wees ook voorzichtig met reparatieopties zoals /r en /f. Zorg ervoor dat u een back-up van uw databases hebt voordat u een reparatie uitvoert, omdat deze opties de bestanden kunnen beschadigen als er schijffouten worden gevonden door chkdsk.

Meer informatie

Zie DBCC CHECKDB (Transact-SQL) voor meer informatie over de syntaxis van DBCC CHECKDB en informatie of opties over het uitvoeren van de opdracht.

Als er fouten worden gevonden met behulp van CHECKDB, worden andere berichten die vergelijkbaar zijn met het volgende bericht gerapporteerd in errorLOG voor foutrapportage:

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

De foutinformatie is verzonden naar Watson-foutrapportage.

De bestanden die worden gebruikt voor foutrapportage bevatten een SQLDump<nnn>.txt-bestand. Dit bestand kan nuttig zijn voor historische doeleinden omdat het een lijst bevat met de fouten die afkomstig zijn van CHECKDB in een XML-indeling.

Als u wilt achterhalen wanneer DBCC CHECKDB voor het laatst is uitgevoerd zonder gedetecteerde fouten voor een database (het laatst bekende schone CHECKDB), controleert u het SQL Server ERRORLOG. Zoek een bericht zoals het volgende voor een gebruiker of systeemdatabase. Dit bericht wordt geschreven als een bericht op informatieniveau in het gebeurtenislogboek van Windows-toepassingen met EventID = 17573 ook:

Datum/tijd spid7s CHECKDB voor database 'master' is voltooid zonder fouten op Datum/tijd 22:11:11.417 (lokale tijd). Dit is alleen een informatiebericht; er is geen actie van de gebruiker vereist

  • Laatst bijgewerkt om