Het oplossen van fouten in de database consistent gemeld door DBCC CHECKB

Van toepassing: Microsoft SQL Server

Symptomen


Wanneer de DBCC CHECKDB (of andere soortgelijke opdrachten zoals CHECKTABLE) wordt uitgevoerd, wordt een bericht als volgt geschreven naar het FOUTENLOGBOEK van SQL Server: 

Datum/tijd -spid53      DBCC CHECKDB (mijndb) uitgevoerd door MYDOMAIN\theuser 15 fouten gevonden en gerepareerd 0 fouten. Verstreken tijd: 0 uur 0 minuten 0 seconden.  Momentopname van de interne database is opgesplitst in punt LSN = 00000026:0000089 d: 0001 en eerste LSN = 00000026:0000089 c: 0001.  Dit is slechts een informatief bericht. Er is geen gebruikersactie vereist.

Dit bericht wordt weergegeven hoeveel fouten in de database consistent zijn gevonden en hoeveel zijn hersteld (als een optie voor herstellen met de opdracht is gebruikt). Dit bericht ook naar het gebeurtenislogboek van Windows-toepassing is geschreven als een gegevensniveau bericht met gebeurtenis-id = 8957 (zelfs als dit bericht is een bericht informatie niveau worden fouten gemeld).

De informatie in het bericht dat begint met 'interne database snapshot...' wordt alleen weergegeven als DBCC CHECKDB online, namelijk als de database niet in de modus SINGLE_USER is is uitgevoerd. Dit komt doordat voor een on line DBCC CHECKDB, een momentopname van de interne database wordt gebruikt om een consistente reeks gegevens te controleren.

In dit artikel wordt geen informatie over het oplossen van elke specifieke fout door DBCC CHECKDB maar veeleer de algemene benadering worden gerapporteerd als fouten worden gerapporteerd. Elke verwijzing naar CHECKDB in dit artikel geldt ook voor DBCC CHECKTABLE en CHECKFILEGROUP tenzij specifiek vermeld.

Oorzaak


DBCC CHECKDB controleert de fysieke en logische consistentie van de database-pagina's, rijen toewijzing van pagina's, index relaties, systeemproblemen tabel referentiële integriteit en andere controles structuur. Als een van deze controles mislukt (afhankelijk van de opties die u hebt gekozen), worden fouten gerapporteerd als onderdeel van de opdracht.

De oorzaak van deze problemen kan variëren van een beschadigd bestandssysteem, de onderliggende problemen met uw systeem hardware, stuurprogramma problemen, beschadigde pagina's in geheugen, of problemen met de SQL Server-Engine. Lees het gedeelte ' Oplossing ' voor meer informatie over het zoeken naar de oorzaak van fouten die zijn gerapporteerd.

Oplossing


De eerste, de beste oplossing als DBCC CHECKDB consistentiefouten worden gemeld, is van een goede reservekopie terugzetten. Echter, als u niet vanaf een back-up terugzetten, vervolgens CHECKDB bevat een functie om fouten te herstellen. Als het niveau problemen met het systeem zoals het bestandssysteem of de hardware kunnen worden veroorzaakt door deze problemen, is het raadzaam dat u corrigeert deze eerste voor het terugzetten of herstellen.

Bij het uitvoeren van DBCC CHECKDB een aanbeveling om aan te geven wat de minimale hersteloptie die nodig is om alle fouten herstellen wordt geleverd. Deze berichten kunnen er bijvoorbeeld als volgt uitzien:

CHECKDB 0 toewijzingsfouten in de en 15 consistentie in database 'mijndb' gevonden.repair_allow_data_loss is het niveau van de minimale herstellen fouten gevonden door DBCC CHECKDB (mijndb

Aanbeveling van de reparatie is het minimumniveau van de reparatie te proberen op te lossen alle fouten uit CHECKDB. Dit betekent niet dat deze hersteloptie wordt daadwerkelijk alle fouten gecorrigeerd. Bovendien mogelijk niet alle fouten die dit niveau van herstel de fout op te lossen. Dit betekent dat niet alle fouten die door CHECKDB wanneer repair_allow_data_loss wordt aanbevolen in verlies van gegevens resulteren zal. Reparatie moet worden uitgevoerd om te bepalen als de resolutie in een fout in gegevensverlies resulteren. Een techniek waarmee een smalle af wat het niveau van de reparatie voor elke tabel worden is DBCC CHECKTABLE gebruiken voor elke tabel een foutmelding. Hier ziet welke het minimumniveau van de reparatie voor een bepaalde tabel.

Als u wilt zoeken naar de oorzaak van waarom database consistentie-fouten zijn opgetreden, kunt u deze methoden:

  • Controleer het logboek voor systeemgebeurtenissen van Windows voor een systeemniveau, een stuurprogramma of een schijf gerelateerde fouten
  • Controleer de integriteit van het bestandssysteem met de opdracht chkdsk.
  • Voer alle diagnostische gegevens die door de fabrikanten van de hardware voor de computer en/of het schijfsysteem.
  • Werken met uw hardwareleverancier of fabrikant van het apparaat om ervoor te zorgen:
    • De hardware en de configuratie wordt bevestigd aan de i/o-vereisten voor SQL Server
    • De stuurprogramma's en andere ondersteunende software-onderdelen van alle apparaten in het i/o-pad worden bijgewerkt.
  • Overweeg het gebruik van een hulpprogramma zoals SQLIOSim op hetzelfde station als de databases die de consistentiefouten gerapporteerd. SQLIOSim is een onafhankelijk van de SQL Server-Engine om te testen of het oppervlak van I/O voor het schijfsysteem. Houd er rekening mee dat SQLIOSim wordt geleverd met SQL Server 2008 en niet afzonderlijk worden gedownload hoeft.
  • Controleren op eventuele andere fouten die door SQL Server bijvoorbeeld toegangsfouten of verklaringen.
  • Controleer dat uw databases met behulp van de optie PAGE_VERIFY CONTROLESOM. Als de checksumfouten worden gerapporteerd, zijn indicatoren die de consistentie-fouten zijn opgetreden nadat SQL Server heeft geschreven pagina's naar de schijf zodat uw schijfsysteem grondig moet worden gecontroleerd. Zie problemen oplossen met Msg 824 in SQL Server voor meer informatie over controlesomfouten.
  • Msg 832 fouten zoeken in het FOUTENLOGBOEK. Deze indicatoren die pagina's mei zijn beschadigd in de cache naar schijf worden geschreven. Zie problemen oplossen met Msg 832 in SQL Server voor meer informatie.
  • Proberen te herstellen van een reservekopie van de database die u dat weet "schone" (geen fouten van CHECKDB) en transactielogboekback-ups die u weet omvatten de tijd waarop de fout is opgetreden. Als u kunt 'replay' Dit probleem door zich herstellen van een 'schone' database back-up en de transactie vervolgens Neem contact op met technische ondersteuning van Microsoft.
  • Gegevensfouten zuiverheid is een probleem met de toepassing invoegen of bijwerken van ongeldige gegevens in een SQL Server-tabellen. Fouten Zie voor meer informatie over het oplossen van de zuiverheid van de gegevens het volgende artikel: problemen met DBCC fout 2570 in SQL server 2005

Meer informatie


Lees voor meer informatie over de syntaxis van DBCC CHECKDB en informatieopties over het uitvoeren van de opdracht het SQL Server Books Online onderwerp over de DBCC-opdracht CHECKDB.

Als er fouten zijn gevonden door CHECKDB, worden extra berichten als volgt voor de toepassing van het rapporteren van fouten gemeld in het FOUTENLOGBOEK:

Datum/tijd dbghelp.dll' spid53 met' versie '4.0.5'Datum/tijd -spid53 ** Dump thread - spid = 0, EG = 0x00000000855F5EB0Datum/tijd spid53 *** Stack Dump wordt verzonden naarDatum/tijd -spid53 FilePath\FileName* ***Datum/tijd -spid53 *Datum/tijd -spid53 * BEGIN STACKDUMP:Datum/tijd -spid53 * Datum/tijd spid 53Datum/tijd -spid53 *Datum/tijd -spid53 * databasebeschadiging DBCCDatum/tijd -spid53 *Datum/tijd -spid53 * Input Buffer 84 bytes -Datum/tijd -spid53 * dbcc checkdb(mydb)Datum/tijd -spid53 * spid53 Datum/tijd * ***Datum/tijd -spid53 *---Datum/tijd -spid53 * korte StackdumpDatum/tijd spid53 Stack handtekening voor de dump is 0x00000000000001E8Datum/tijd spid53 externe dump proces-retourcode 0x20002001.De foutinformatie is ingediend bij de Watson-fouten melden.

De bestanden die worden gebruikt voor het rapporteren van fouten bevatten een SQLDump < nnn > .txt-bestand. Dit bestand is handig voor historische doeleinden als het bevat een lijst van de fouten van CHECKDB gevonden in een XML-indeling.

Tijdens de laatste keer dat het DBCC CHECKDB zonder fouten gevonden voor een database (het laatste bekende schoon CHECKDB uitvoeren), kijk het FOUTENLOGBOEK van SQL Server voor een bericht als volgt voor de database of de systeemdatabase (dit bericht is geschreven als een informatie-niveau bericht in het gebeurtenislogboek van Windows Application met gebeurtenis-id = 17573):

Datum/tijd spid7s CHECKDB voor database 'master' voltooid zonder fouten op Datum/tijd -22:11:11.417 (lokale tijd). Dit is een informatief bericht. Er is geen actie van de gebruiker vereist