Delen via

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 begint met 'momentopname van interne database...' wordt alleen weergegeven als DBCC CHECKDB deze online is uitgevoerd, waarin de database zich niet in de SINGLE_USER modus bevindt. Dit komt doordat voor een online een momentopname DBCC CHECKDBvan 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 wordt gerapporteerd door DBCC CHECKDB , maar in plaats daarvan de algemene benadering als er fouten worden gerapporteerd. 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.

Oplossing

  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. Neem contact op 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 worden gerapporteerd, is het de beste oplossing om gegevens te herstellen van een bekende goede back-up. Zie Herstellen en herstellen 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 voor cumulatieve updates of servicepacks voor bekende problemen die zijn opgelost met betrekking tot databasebeschadiging (consistentiefouten) en pas eventuele relevante oplossingen toe. Een centrale locatie waar u kunt zoeken naar alle oplossingen voor een bepaalde versie als de gedetailleerde oplossingslijsten voor SQL Server 2022, 2019, 2017.

  4. Als de DBCC CHECKDB fouten af en toe optreden, is dat als ze worden weergegeven op een uitvoering en verdwijnen op de volgende, mogelijk ondervindt u problemen met de schijfcache (apparaatstuurprogramma of een ander I/O-padprobleem). 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 te herstellen vanuit een back-up, CHECKDB heeft u een functie voor het herstellen van fouten die u kunt gebruiken. Er zijn twee reparatieniveaus:

    • REPAIR_REBUILD - voert reparaties uit die geen kans hebben op gegevensverlies.
    • 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 maken van een keuze om gegevensverlies toe te staan, omdat uw database mogelijk in een logische inconsistente status blijft. De DBCC CHECKDB uitvoer doet een aanbeveling over het minimale herstelniveau dat moet worden gebruikt. Het is gebruikelijk om meerdere keren te worden uitgevoerd CHECKDBREPAIR_ALLOW_DATA_LOSS 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 worden weergegeven 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 of herstel wordt hersteld. Microsoft-ondersteuningstechnici kunnen niet helpen bij het fysiek herstellen van beschadigde gegevens als de herstelbewerking de consistentiefouten niet oplost of als de databaseback-up beschadigd is.

    Wanneer u wordt uitgevoerd DBCC CHECKDB, 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 op te lossen.CHECKDB 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 dat het gebruik van dit herstelniveau wordt opgelost. Dit betekent dat niet alle reparaties leiden CHECKDBREPAIR_ALLOW_DATA_LOSS tot gegevensverlies. Herstel 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 te gebruiken DBCC CHECKTABLE voor elke tabel die een fout rapporteert. Hier ziet u het minimale herstelniveau voor een bepaalde tabel.

    Waarschuwing

    U moet handmatige gegevensvalidatie uitvoeren nadat CHECKDB het herstellen of 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 uit te voeren. 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:

Hoofdoorzaak onderzoeken voor 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 diagnostische gegevens uit van uw hardwarefabrikanten voor de computer en/of het schijfsysteem. De meeste systemen bieden ingebouwde BIOS/UEFI-diagnostische gegevens 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:
    • De hardwareapparaten en de configuratie bevestigen de invoer-/uitvoervereisten voor de Microsoft SQL Server-database-engine.
    • De apparaatstuurprogramma's en andere ondersteunende softwareonderdelen van alle apparaten in het I/O-pad zijn bijgewerkt.
  • Overweeg het gebruik van een hulpprogramma zoals SQLIOSim op het station waar de databases die de consistentiefouten hebben gerapporteerd zich bevinden. 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. Een centrale locatie waar u kunt zoeken naar alle oplossingen voor een bepaalde versie als de gedetailleerde oplossingslijsten voor SQL Server 2022, 2019, 2017.
  • Controleer op andere fouten die zijn gerapporteerd door SQL Server, zoals toegangsschendingen of asserties. Activiteit tegen beschadigde databases resulteert vaak in uitzonderingen voor toegangsschendingen 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 Msg 824 in SQL Server oplossen voor meer informatie over controlesomfouten.
  • Zoek naar bericht 832-fouten in het FOUTENLOGBOEK. Deze fouten kunnen erop wijzen dat pagina's mogelijk beschadigd zijn 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 die 'schoon' is (geen fouten van CHECKDB) gevolgd door back-ups van transactielogboeken die de tijdsduur van het genereren van de fout omvatten. 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.
  • Fouten met gegevenszuiverheid kunnen een probleem zijn met het invoegen of bijwerken van ongeldige gegevens in SQL Server-tabellen. Zie Problemen met DBCC-fout 2570 in SQL Server 2005 oplossen voor meer informatie over het oplossen van gegevenszuiveringsfouten.
  • Controleer de integriteit van het bestandssysteem met behulp van de opdracht chkdsk . Niet uitvoeren chkdsk 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 zijn gevonden CHECKDB in een XML-indeling.

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

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

  • Last updated on