DBCC CHECKDB: Complete gids voor MS SQL Server Databasegezondheid (2025)

Corruptie van databases is overal SQL Server De nachtmerrie van elke beheerder. Wanneer kritieke bedrijfsgegevens ontoegankelijk of onbetrouwbaar worden,ost kan verwoestend zijn. Deze uitgebreide gids behandelt alles wat u moet weten over het gebruik van DBCC CHECKDB om de database gezond te houden en corruptie te voorkomen, plus geavanceerde hersteloplossingen voor wanneer standaardtools niet volstaan.

1. Belangrijkheid van SQL Server Database Gezondheid

1.1 Wat is databasecorruptie Costs Bedrijven

Vandaag, most Bedrijven slaan hun kritieke gegevens op in databases. Wanneer er sprake is van databasecorruptie, zijn de gevolgen catastrofaal:

• Financiële verliezen gemiddeld $ 2.3 miljoen per jaar als gevolg van gegevensverlies, waarbij hardwarestoringen en corruptie de belangrijkste oorzaken zijn (EMC Corporation)
• Bedrijfssluitingspercentages tonen aan dat 50% van de kleine bedrijven die te maken krijgen met dataverlies door hardwarestoringen binnen twee jaar failliet gaan, terwijl 94% van de bedrijven met catastrofaal dataverlies helemaal niet overleeft.
• Frequentie van gegevenscorruptie treft jaarlijks 20% van de bedrijfskritische applicaties en veroorzaakt verstoringen van de bedrijfscontinuïteit (Gartner-onderzoek)
• Hardwaregerelateerde corruptie is verantwoordelijk voor 67% van alle incidenten met gegevensverlies door crashes van harde schijven en systeemstoringen, waarbij 40% van het gegevensverlies rechtstreeks te wijten is aan hardwarestoringen
• Software corruptie costs De schade kan variëren van duizenden tot miljoenen dollars, afhankelijk van de ernst en omvang, waarbij 82% van de bedrijven te maken kreeg met ongeplande uitval waarbij corruptie een belangrijke oorzaak was.

1.2 Waarom regelmatige gezondheidscontroles cruciaal zijn

Mensen hebben regelmatige gezondheidscontroles nodig om mogelijke ziekten vroegtijdig op te sporen. Ook databases hebben regelmatige gezondheidscontroles nodig:

1. Signaleer mogelijke corruptie vroegtijdig en pak het direct aan. Zo voorkomt u dat problemen ernstig en wijdverspreid worden, wat catastrofale gevolgen voor de onderneming zou kunnen hebben.
2. Zorg ervoor dat de database optimaal functioneert.
3. de cost Het rendement van proactieve database-gezondheidscontroles ligt veel lager dan dat van reactief gegevensherstel nadat een databaseramp heeft plaatsgevonden.

1.3 Inleiding tot database-integriteitsopdrachten

SQL Server biedt verschillende ingebouwde opdrachten voor het onderhouden van de databasegezondheid, met DBCC CONTROLEERDB dienend als de most Uitgebreide tool voor integriteitscontrole beschikbaar. Deze opdrachten werken samen om verschillende aspecten van uw databasestructuur te verifiëren, van individuele tabellen tot de consistentie van de gehele database, en vormen zo een complete onderhoudsstrategie die uw gegevens veilig en toegankelijk houdt.

2. Wat is DBCC CHECKDB

DBCC CONTROLEERDB is SQL Server's belangrijkste hulpmiddel voor het verifiëren van database-integriteit en het identificeren van corruptieproblemen.

• Het is een T-SQL-instructie, geen GUI-tool.
• U kunt het uitvoeren via gangbare methoden, zoals SQL Server Management Studio (SSMS), SQL Server Agent, SQLCMD, enz.

2.1 Wat CHECKDB daadwerkelijk controleert in uw database

Wanneer u DBCC CHECKDB uitvoert, voert de opdracht meerdere validatielagen uit in uw databasestructuur:

• Verificatie van paginacontrolesommen om fysieke corruptie en hardwaregerelateerde problemen op te sporen
• Validatie van indexconsistentie om een ​​correcte gegevensophaling en queryprestaties te garanderen
• Controles op de toewijzingsstructuur om nauwkeurig ruimtegebruik en paginatoewijzing te bevestigen
• Referentieel integriteitsonderzoek tussen gerelateerde tabellen en relaties tussen vreemde sleutels
• Validatie van systeemtabelconsistentie te zorgen SQL ServerDe interne metadata van 's blijft betrouwbaar
• Verificatie van de koppeling van gegevenspagina's om de juiste integriteit van de paginaketen te bevestigen
• Consistentie van databaseschema's om objectdefinities en afhankelijkheden te valideren

Deze uitgebreide controles omvatten zowel gebruikersgegevens als systeemstructuren en bieden u volledig inzicht in de gezondheidsstatus van uw database.

3. DBCC CHECKDB uitvoeren: stap voor stap

3.1 Vereisten

Hieronder vindt u de checklist voordat u een DBCC CHECKDB-bewerking uitvoert:

• Volledige databaseback-up – Maak een volledige back-up voordat u integriteitscontroles uitvoert. Deze dient als vangnet voor het geval dat er corruptie wordt ontdekt of reparaties noodzakelijk zijn.
• Juiste rechten – U hebt sysadmin- of db_owner-machtigingen nodig om DBCC CHECKDB-opdrachten uit te voeren
• Voldoende systeembronnen:
  • Geheugen: 25% van de databasegrootte
  • Tempdb-ruimte: 10-15% van de databasegrootte
  • CPU: 50-70% beschikbaarheid tijdens onderhoud
  • I/O: Verwacht zware leesbewerkingen
• Toegankelijkheid van de database – Controleer of uw database toegankelijk is en zich niet in een beperkte staat bevindt, aangezien CHECKDB leesrechten vereist voor alle databasepagina's

3.2 Basiscommando

De most De basis DBCC CHECKDB-opdracht omvat drie veelvoorkomende variaties:

(1) Controleer de huidige database (geen parameters):

DBCC CHECKDB

(2) Controleer een database op naam:

DBCC CHECKDB ('YourDatabaseName')

(3) Controleer een database op ID:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Deze fundamentele opdracht voert een volledige integriteitscontrole uit van de opgegeven database, waarbij alle tabellen, indexen en systeemstructuren worden onderzocht. Voor databases met standaardnamen die geen spaties bevatten, kunt u de aanhalingstekens weglaten. De opdracht wordt uitgevoerd tot deze voltooid is en geeft voortgangsberichten en eindresultaten weer. Deze basissyntaxis werkt perfect voor kleinere databases of wanneer u voldoende tijd voor onderhoud beschikbaar hebt.

Hieronder ziet u een schermafbeelding van het uitvoeren van DBCC CHECKDB in SQL Server Managementstudio (SSMS):

3.3 Volledige opties

Hieronder vindt u de volledige opties voor DBCC CHECKDB:

Categorie	Keuze	Beschrijving	DBCC CHECKDB-voorbeeld
Reparatie opties	REPAIR_REBUILD	Reparaties zonder gegevensverlies (bijvoorbeeld indexherbouw)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Geen reparatie. Alleen achterwaartse compatibiliteit.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Herstelt alle fouten (kan leiden tot gegevensverlies)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Scopecontrole	NOINDEX	Slaat niet-geclusterde indexcontroles over	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Controleert alleen de fysieke opslagintegriteit (pagina's/records)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Controleert op logische kolomwaardefouten (bijvoorbeeld ongeldige datums)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Diepe logische controles (geïndexeerde weergaven, XML/ruimtelijke indexen)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Uitgangscontrole	ALL_ERRORMSGS	Toont alle fouten (standaard: 200 per object)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Verbergt informatieve berichten	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Prestatie	TABLOCK	Gebruikt tabelvergrendelingen (vermindert TempDB-gebruik, maar blokkeert schrijfbewerkingen)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Overschrijft parallellisme-instellingen	DBCC CHECKDB ('MyDB', MAXDOP = 2)
utility	ESTIMATEONLY	Schat de benodigde TempDB-ruimte. (geen daadwerkelijke controle)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Uw resultaten begrijpen

DBCC CHECKDB levert verschillende resultaten op, afhankelijk van of de uitvoering succesvol is of niet. We leggen ze in detail uit.

4.1 CHECKDB-uitvoering is succesvol voltooid

Als de uitvoering van DBCC CHECKDB succesvol wordt voltooid, worden er verschillende typen resultaten gerapporteerd, afhankelijk van de gezondheidsstatus van uw database.

4.1.1 Geen problemen gevonden

Als DBCC CHECKDB geen problemen vindt, ziet u uitvoer die hierop lijkt:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Dit resultaat geeft aan dat uw database een perfecte integriteit behoudt in alle gecontroleerde structuren.

4.1.2 Corruptiefouten gevonden

Wanneer DBCC CHECKDB een corruptiefout detecteert, wordt een foutbericht met de volgende structuur weergegeven:
Gids voor ernstniveau:

• Level 16-19: Door de gebruiker te corrigeren fouten, vaak kleine beschadigingen
• Level 20-24: Systeemfouten, ernstige corruptie die onmiddellijke aandacht vereist
• Niveau 25: Fatale fouten, database is mogelijk niet toegankelijk

Veelvoorkomende fouten zijn:

• Pagina checksum mislukt (bericht 824)
• Toewijzingsfouten (bericht 8928)
• Problemen met indexconsistentie (bericht 8964)

Inzicht in de berichtstructuur helpt bij het prioriteren van responsacties en het bepalen van geschikte herstelstrategieën.

4.1.3 Algemene informatie- en waarschuwingsberichten

Niet alle DBCC CHECKDB-uitvoer geeft ernstige problemen aan. Er kunnen ook informatieve en waarschuwingsberichten verschijnen, waaronder:

• Reparatieverklaringen – Berichten die reparatieopdrachten voorstellen voor het oplossen van kleine problemen
• Toewijzingswaarschuwingen – Waarschuwingen over ruimtetoewijzing die geen invloed hebben op de toegang tot gegevens
• Prestatie-aanbevelingen – Suggesties voor indexonderhoud en -optimalisatie
• Informatieve mededelingen – Algemene statusberichten die geen onmiddellijke actie vereisen

Deze berichten bieden waardevolle richtlijnen voor onderhoud, waarbij onderscheid wordt gemaakt tussen kritieke corrupties die onmiddellijke actie vereisen en kleine problemen die tijdens de reguliere onderhoudsvensters kunnen worden opgelost.

Voorbeeld van een waarschuwingsbericht:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 CHECKDB-uitvoering wordt afgebroken

Als CHECKDB tijdens de uitvoering om verschillende redenen wordt afgebroken, wordt er een foutmelding weergegeven en wordt er een foutenlogboek toegevoegd met de onderstaande statuscode:

Land	Beschrijving
0	Foutnummer 8930 is opgetreden. Dit duidt op een corruptie in de metadata, waardoor de DBCC-opdracht werd beëindigd.
1	Foutnummer 8967 is opgetreden. Er was een interne DBCC-fout.
2	Er is een fout opgetreden tijdens het databaseherstel in de noodmodus.
3	Dit geeft aan dat er een corruptie in de metagegevens is opgetreden, waardoor de DBCC-opdracht is beëindigd.
4	Er is een assert- of access-schending gedetecteerd.
5	Er is een onbekende fout opgetreden waardoor de DBCC-opdracht is beëindigd.

Voorbeeld foutmelding:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

of

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Voorbeeld van een foutenlogboek:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

In zo'n geval kunt u alternatieve geavanceerde opties proberen, zoals DataNumen SQL Recovery om de corruptie in uw database te herstellen.

5. Corruptiefouten oplossen

5.1 Back-up en herstel: de veiligste oplossing

Wanneer DBCC CHECKDB corruptiefouten identificeert, is het herstellen vanaf een schone back-up de veiligste en meest efficiënte manier.ost Betrouwbare oplossing. Deze aanpak garandeert de integriteit van de gegevens en elimineert tegelijkertijd de onderliggende oorzaken van datacorruptie. Controleer vóór het herstellen de integriteit van de back-up met behulp van HERSTEL ALLEEN VERIFICATIE opdrachten en overweeg point-in-time herstelopties om gegevensverlies te minimaliseren. Documenteer de details van de corruptie voor een analyse van de hoofdoorzaak, aangezien hardwareproblemen of softwarefouten mogelijk extra aandacht vereisen om herhaling te voorkomen.

5.2 Oplossingen voor corruptie op paginaniveau

Voor geïsoleerde paginacorruptie die kleine gegevensgedeelten beïnvloedt, SQL Server Enterprise Edition biedt paginaherstelmogelijkheden waarmee specifieke beschadigde pagina's kunnen worden hersteld zonder volledige databaseherstel. Deze geavanceerde techniek vereist een volledig herstelmodel en actuele logback-ups.

Stapsgewijs paginaherstelproces:

1. Identificeer de beschadigde pagina van CHECKDB-foutmelding (bijv. pagina 1:256)
2. Maak een actuele logback-up om recente transacties vast te leggen:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. Herstel de beschadigde pagina van de most recente volledige back-up:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. Differentiële back-up toepassen (indien beschikbaar):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. Alle logback-ups toepassen in volgorde, inclusief de zojuist gemaakte:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Maak een laatste logback-up en herstel om de pagina actueel te maken:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Alternatief voor niet-kritieke gegevens: Als de beschadiging niet-kritieke gegevens betreft, kunt u de niet-beïnvloede rijen exporteren naar nieuwe tabellen voordat u de beschadigde structuren opnieuw opbouwt:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Snelle oplossingen voor indexcorruptie

Indexbeschadiging reageert vaak goed op herbouwbewerkingen waarmee indexstructuren opnieuw worden gemaakt zonder dat de onderliggende tabelgegevens worden beïnvloed:

ALTER INDEX ALL ON YourTable REBUILD

Deze aanpak werkt vooral goed bij niet-geclusterde indexbeschadiging, omdat bij het opnieuw opbouwen de indexpagina's opnieuw worden gegenereerd op basis van de brontabelgegevens. Zo wordt beschadiging effectief voorkomen en blijven alle oorspronkelijke gegevens behouden.

6. Gebruik REPAIR_REBUILD en REPAIR_ALLOW_DATA_LOSS

Als alle voorgaande methoden mislukken of niet haalbaar zijn, kunt u de opties REPAIR_REBUILD en REPAIR_ALLOW_DATA_LOSS gebruiken om de database te repareren.

6.1 REPAIR_REBUILD (veiligere optie):

• Gebruik voor: Indexcorruptie en kleine toewijzingsfouten
• Gegevensbeveiliging: Probeert corruptie te herstellen zonder gegevens te verwijderen
• Risico niveau: Laag – geen dataverlies verwacht
• Typische scenario's: Corruptie van niet-geclusterde index, kleine metadataproblemen
• Voorbeeldopdracht: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Laatste redmiddel):

• Gebruik voor: Ernstige corruptie wanneer back-ups niet beschikbaar zijn
• Gegevensbeveiliging: Kan beschadigde gegevens verwijderen om de databasefunctionaliteit te herstellen
• Risico niveau: Hoog – permanent gegevensverlies mogelijk
• Typische scenario's: Corruptie van pagina's, schade aan systeemtabellen, fouten in de toewijzingsketen
• Voorbeeldopdracht: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Aanbevolen werkwijzen voor deze opties:

• Test altijd herstelbewerkingen op databasekopieën wanneer mogelijk
• Maak altijd een back-up voordat u deze opties uitvoert
• Documenteer alle wijzigingen voor nalevings- en probleemoplossingsdoeleinden
• Database instellen op modus voor één gebruiker voordat u reparatiewerkzaamheden uitvoert

Normaal gesproken zouden we moeten proberen REPARATIE_HERBOUWEN optie eerst. Als het mislukt, probeer het dan REPAIR_ALLOW_DATA_LOSS .

6.4 REPAIR_ALLOW_DATA_LOSS Resultaten

6.4.1 Herstel slaagt met gegevensverlies

Soms het REPAIR_ALLOW_DATA_LOSS optie zal slagen, maar sommige gegevens zijn lost na de reparatie.

Hieronder vindt u enkele voorbeeldberichten:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Dit komt doordat DBCC CHECKDB de database herstelt door enkele beschadigde records te verlaten, maar in werkelijkheid, most van hen kan nog steeds worden teruggevorderd via DataNumen SQL Recovery.

Voorbeeld bestanden:

SQL Server versie	Beschadigd MDF-bestand	MDF-bestand opgelost door DataNumen SQL Recovery
SQL Server 2014	Fout10_1.mdf (Msg 8909 gevolgd door Msg 8939) (600 records lost met REPAIR_ALLOW_DATA_LOSS)	Fout10_1_fixed.mdf (Geen record lost)
SQL Server 2014	Fout10_2.mdf (Msg 8909 gevolgd door Msg 8939) (6000 records (50%) lost met REPAIR_ALLOW_DATA_LOSS)	Fout10_2_fixed.mdf (Slechts 100 records lost)
SQL Server 2014	Error7.mdf (100 platen lost met REPAIR_ALLOW_DATA_LOSS)	Fout7_fixed.mdf (Slechts één record lost)

6.4.2 Reparatie mislukt – Overweeg een professionele oplossing

If REPAIR_ALLOW_DATA_LOSS mislukt, zal het een of meerdere foutmeldingen geven.

Hieronder volgen enkele voorbeelden:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

In deze scenario's moet u een professionele oplossing gebruiken, zoals DataNumen SQL Recovery om uw database te repareren.

Voorbeeld bestanden

SQL Server versie	Beschadigd MDF-bestand	MDF-bestand opgelost door DataNumen SQL Recovery
SQL Server 2014	Fout1_3.mdf (Enkel bericht 824)	Fout1_3_fixed.mdf
SQL Server 2014	Fout1_1.mdf (Continue Msg 824-fouten)	Fout1_1_vast.mdf
SQL Server 2014	Fout1_2.mdf ((Bericht 824 gevolgd door bericht 7909)	Fout1_2_fixed.mdf
SQL Server 2014	Fout4_1.mdf (Bericht 8992 gevolgd door bericht 3852)	Fout4_1_fixed.mdf
SQL Server 2014	Fout4_2.mdf (Bericht 8992 gevolgd door bericht 3852)	Fout4_2_fixed.mdf
SQL Server 2014	Fout5.mdf (Bericht 8945)	Fout5_fixed.mdf
SQL Server 2014	Fout6.mdf (Bericht 2510)	Fout6_fixed.mdf
SQL Server 2014	Fout2.mdf (Bericht 2575)	Fout2_fixed.mdf
SQL Server 2014	Fout11.mdf (Bericht 8905)	Fout11_fixed.mdf
SQL Server 2014	Fout3.mdf (Bericht 5028)	Fout3_fixed.mdf
SQL Server 2014	Error8.mdf (Bericht 5125)	Error8_vast.mdf
SQL Server 2014	Fout9.mdf (Bericht 3313)	Fout9_fixed.mdf

7. Beste praktijken

7.1 Regelmatige CHECKDB-bewerkingen plannen

Implementeer wekelijkse DBCC CHECKDB-uitvoering voor kritieke productiedatabases, met dagelijkse controles voor systemen met veel transacties. Plan bewerkingen tijdens perioden met weinig gebruik om de prestatie-impact te minimaliseren en overweeg om te roteren tussen volledige controles en PHYSICAL_ONLY-opties op basis van databasegrootte en onderhoudsintervallen. Geautomatiseerde planning via SQL Server Agent zorgt voor consistente uitvoering en biedt gecentraliseerde bewakings- en waarschuwingsmogelijkheden.

7.2 Prestatie-impactmanagement

DBCC CHECKDB-bewerkingen verbruiken aanzienlijke systeembronnen, wat mogelijk van invloed is op gelijktijdige gebruikersactiviteiten. Houd CPU-gebruik, geheugengebruik en schijf-I/O in de gaten tijdens controles om inzicht te krijgen in de impact op de prestaties. Overweeg het gebruik van NOINDEX-opties voor routinecontroles en reserveer volledige validatie voor maandelijkse onderhoudsperiodes. Implementeer query-time-outuitbreidingen en strategieën voor gebruikerscommunicatie om de verwachtingen tijdens integriteitscontroles te beheren.

7.3 Planning van onderhoudsvensters

Coördineer de planning van DBCC CHECKDB met andere onderhoudsactiviteiten, zoals back-upbewerkingen, het herbouwen van indexen en het bijwerken van statistieken. Vermijd overlappende resource-intensieve bewerkingen die prestatievermindering of time-outproblemen kunnen veroorzaken. Plan onderhoudsvensters op basis van verwachte groei van de databasegrootte, zodat er voldoende tijd is voor een volledige integriteitsverificatie naarmate de datavolumes toenemen.

7.4 Geautomatiseerde monitoring en waarschuwingen

Configure SQL Server Agentwaarschuwingen om beheerders onmiddellijk te waarschuwen wanneer DBCC CHECKDB corruptie vaststelt. Implementeer logparsing-oplossingen die resultaten van integriteitscontroles extraheren en categoriseren, wat trendanalyse en proactieve probleemidentificatie mogelijk maakt. Creëer escalatieprocedures die responstermijnen en verantwoordelijk personeel definiëren voor verschillende niveaus van corruptie-ernst.

8. DBCC CHECKTABLE: Het lichtgewicht alternatief

8.1 Wanneer CHECKTABLE gebruiken in plaats van CHECKDB

DBCC CHECKTABLE biedt gerichte integriteitscontroles voor individuele tabellen, waardoor het ideaal is voor tarGeted-probleemoplossing en onderhoud van specifieke databaseobjecten. Gebruik CHECKTABLE bij het onderzoeken van prestatieproblemen met specifieke tabellen, het valideren van kritieke bedrijfstabellen tussen volledige databasecontroles, of wanneer tijdsbeperkingen volledige databasevalidatie verhinderen. Deze aanpak is vooral waardevol in grote databases waar volledige CHECKDB-bewerkingen de beschikbare onderhoudsvensters overschrijden.

8.2 DBCC CHECKTABLE-syntaxis en voorbeelden

De basisopdracht CHECKTABLE tarkrijgt specifieke tabellen:

DBCC CHECKTABLE('YourTable')

Net als CHECKDB ondersteunt CHECKTABLE diverse opties, waaronder NOINDEX voor prestatieoptimalisatie en reparatieparameters voor het oplossen van corruptie. U kunt ook schemanamen opgeven voor nauwkeurige tabelidentificatie:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Deze tarDe Geted-aanpak maakt een gedetailleerde integriteitsverificatie mogelijk, terwijl de systeemprestaties tijdens kantooruren behouden blijven.

8.3 Prestatievoordelen voor grote databases

CHECKTABLE-bewerkingen worden aanzienlijk sneller voltooid dan volledige databasecontroles, waardoor frequentere integriteitscontroles van kritieke tabellen mogelijk zijn. Deze aanpak maakt dagelijkse validatie van essentiële bedrijfstabellen mogelijk, terwijl uitgebreide CHECKDB-bewerkingen worden gereserveerd voor wekelijkse of maandelijkse schema's. Het verminderde resourceverbruik maakt CHECKTABLE geschikt voor uitvoering in een productieomgeving met minimale impact op de gebruiker.

9. Wanneer CHECKDB faalt

DBCC CHECKDB kan in verschillende scenario's mislukken, waaronder:

• DBCC CHECKDB-uitvoering eindigt abnormaal
• De uitvoering van DBCC CHECKDB is succesvol voltooid, maar de reparatieopties kan de database niet herstellen.

In deze gevallen hebben we een professionelere tool nodig om de fouten in de database te verhelpen.

9.1 Inleiding tot DataNumen SQL Recovery

DataNumen SQL Recovery biedt meer geavanceerde mogelijkheden:

• Beste herstelpercentage in de industrie.
• Herstel ernstig beschadigde databasebestanden.
• Herstel alle databaseobjecten, inclusief tabellen, indexen, weergaven, triggers, regels en standaardinstellingen.
• Herstel opgeslagen procedures, scalaire functies, inline tabelwaardefuncties en multistatement tabelwaardefuncties.
• Herstel permanent verwijderde records.
• Versleutelde objecten ontsleutelen in SQL Server databases.
• Herstel MDF-bestanden in batch.
• Uitgebreide reparatiemogelijkheden.
• Geavanceerde logging en rapportage.
• Ondersteuning voor iedereen SQL Server versies.
• Beschikbaarheid van technische ondersteuning
• Regelmatige updates en verbeteringen

9.2 Vergelijking van succespercentages

De succespercentages van herstel zijn aanzienlijk verschillend:

• DBCC CHECKDB & CHECKTABLE: 1.27% gemiddelde herstelsnelheid
• DataNumen: 92.6% herstelpercentage

Hieronder vindt u een volledige vergelijking met de concurrentie:

9.3 Herstel van ernstige corruptie

Geavanceerde mogelijkheden voor ernstige gevallen:

• Herstel van fysiek beschadigde opslag
• Herstel van geformatteerde schijven of gecrashte systemen
• Herstellen van schijfkopieën, back-upbestanden, schijfbestanden van virtuele machines, temporary-bestanden, enz.

9.4 Wanneer u professionele oplossingen moet overwegen

• Geen recente back-up beschikbaar
• DBCC CHECKDB mislukt
• Ernstige corruptiescenario's
• Omgaan met kritieke bedrijfsgegevens
• Als tijd cruciaal is
• Wanneer maximaal herstel essentieel is

10. Veelgestelde vragen

11. Conclusie

11.1 Samenvatting van de belangrijkste punten

11.1.1 Samenvatting van essentiële DBCC CHECKDB-opdrachten

Beheers de basissyntaxis van DBCC CHECKDB voor uitgebreide databasecontrole, gebruik de opties NOINDEX en PHYSICAL_ONLY voor prestatieoptimalisatie en begrijp CHECKTABLE voor tarGeted-tabelverificatie. Deze fundamentele opdrachten vormen de basis van proactief databaseonderhoud en maken vroege corruptiedetectie en systematische integriteitsbewaking mogelijk.

11.1.2 Herinnering aan kritische best practices

Zorg altijd voor actuele back-ups voordat u integriteitscontroles uitvoert, plan regelmatige CHECKDB-bewerkingen op basis van de criticaliteit van de database en implementeer geautomatiseerde monitoring voor directe waarschuwingen over corruptie. Houd er rekening mee dat preventie door middel van regelmatige monitoring reactieve benaderingen overstijgt, en dat professionele hersteloplossingen waardevolle back-upopties bieden wanneer standaardtools onvoldoende blijken te zijn.

11.2 Wanneer DBCC CHECKDB gebruiken versus geavanceerde oplossingen

Gebruik DBCC CHECKDB voor routinematige integriteitsmonitoring en het oplossen van kleine beschadigingen, terwijl u professionele hersteltools reserveert voor ernstige beschadigingen die de ingebouwde herstelmogelijkheden te boven gaan. Het beslissingskader moet rekening houden met de beschikbaarheid van back-ups, de criticaliteit van de gegevens, tijdsbeperkingen en de ernst van de beschadiging. Succesvolle databasebeheerders combineren regelmatige CHECKDB-monitoring met uitgebreide back-upstrategieën en kennis van geavanceerde herstelopties wanneer standaardbenaderingen ontoereikend blijken.

12. Referenties

1. Microsoft Learn. “DBCC CHECKDB (Transact-SQL).” SQL Server Documentatie. Microsoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. “Los databaseconsistentiefouten op die worden gerapporteerd door DBCC CHECKDB.” SQL Server Documentatie. Microsoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors