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:
- 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.
- Zorg ervoor dat de database optimaal functioneert.
- 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:
- Identificeer de beschadigde pagina van CHECKDB-foutmelding (bijv. pagina 1:256)
- Maak een actuele logback-up om recente transacties vast te leggen:
BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'
- Herstel de beschadigde pagina van de most recente volledige back-up:
RESTORE DATABASE YourDatabase PAGE = '1:256'
FROM DISK = 'C:\Backups\YourDB_Full.bak'
- Differentiële back-up toepassen (indien beschikbaar):
RESTORE DATABASE YourDatabase PAGE = '1:256'
FROM DISK = 'C:\Backups\YourDB_Diff.bak'
- 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'
- 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
10.1 Basisgebruikvragen
V: Hoe vaak moet ik DBCC CHECKDB uitvoeren?
A: Voer CHECKDB wekelijks uit voor kritieke productiedatabases. Overweeg voor systemen met veel transacties dagelijkse controles met de optie PHYSICAL_ONLY, met volledige controles wekelijks. Ontwikkelingsdatabases kunnen maandelijks worden gecontroleerd.
V: Kan ik DBCC CHECKDB uitvoeren op een live-productiedatabase?
A: Ja, DBCC CHECKDB kan op online databases draaien zonder gebruikers te blokkeren. Het verbruikt echter aanzienlijke bronnen, dus plan het tijdens periodes met weinig activiteit en controleer de systeemprestaties.
V: Wat is het verschil tussen CHECKDB en CHECKTABLE?
A: CHECKDB onderzoekt de gehele database, terwijl CHECKTABLE zich richt op individuele tabellen. Gebruik CHECKTABLE voor tarGeted-probleemoplossing of wanneer u specifieke tabellen moet controleren zonder de hele database te scannen.
10.2 Prestatie- en resourcevragen
V: Waarom duurt DBCC CHECKDB zo lang op mijn grote database?
A: De duur van CHECKDB is afhankelijk van de databasegrootte, hardwareprestaties en gebruikte opties. Gebruik PHYSICAL_ONLY voor snellere controles of NOINDEX om niet-geclusterde indexen over te slaan. Overweeg om deze uit te voeren tijdens onderhoudsvensters met toegewezen resources.
V: Hoeveel tempdb-ruimte heeft CHECKDB nodig?
A: Reserveer over het algemeen 10-15% van uw databasegrootte voor tempdb tijdens CHECKDB-bewerkingen. Gebruik de optie ESTIMATEONLY voor nauwkeurige schattingen: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY
V: Kan ik een lopende CHECKDB-bewerking annuleren?
A: Ja, u kunt CHECKDB annuleren met de opdracht KILL op de sessie-ID. Annuleren geeft echter geen informatie over de integriteit van de database en u moet het later opnieuw uitvoeren.
10.3 Vragen over foutbehandeling
V: CHECKDB heeft fouten gevonden. Moet ik in paniek raken?
A: Raak niet in paniek, maar handel snel. Bepaal eerst of CHECKDB succesvol is voltooid maar corruptie heeft gevonden, of dat CHECKDB zelf niet is uitgevoerd. Controleer of de fouten alleen betrekking hebben op niet-geclusterde indexen (minder kritisch) of tabelgegevens (ernstiger).
V: Wanneer moet ik REPAIR_ALLOW_DATA_LOSS gebruiken?
A: Alleen als absoluut laatste redmiddel, wanneer u geen bruikbare back-ups hebt en gegevensverlies acceptabel is in vergelijking met volledig databaseverlies. Probeer altijd eerst te herstellen vanaf een back-up, aangezien herstelbewerkingen permanent gegevensverlies kunnen veroorzaken.
V: Wat betekent “consistentiefouten in de database” versus “toewijzingsfouten”?
A: Toewijzingsfouten hebben invloed op hoe SQL Server Houdt het schijfruimtegebruik bij, terwijl consistentiefouten duiden op problemen met gegevens of indexstructuren. Beide vereisen aandacht, maar consistentiefouten hebben doorgaans een directere invloed op de toegankelijkheid van gegevens.
10.4 Vragen over back-up en herstel
V: Moet ik CHECKDB uitvoeren op mijn back-ups?
A: Absoluut! Voer CHECKDB uit na het terugzetten van back-ups naar testservers. Dit controleert de integriteit van de back-up en zorgt ervoor dat u daadwerkelijk kunt herstellen van corruptie. Automatiseer dit proces indien mogelijk.
V: Mijn backup is ook beschadigd – wat nu?
A: Probeer oudere back-ups totdat u een schone back-up vindt. Als er geen schone back-ups beschikbaar zijn, overweeg dan professionele hersteloplossingen zoals DataNumen SQL RecoveryLeg de corruptietijdlijn vast om toekomstige gevallen te voorkomen.
V: Kan paginaherstel corruptie herstellen zonder de database volledig te herstellen?
A: Ja, maar alleen in SQL Server Enterprise Edition met volledig herstelmodel en actuele logback-ups. Paginaherstel werkt bij geïsoleerde paginabeschadiging, maar vereist zorgvuldige uitvoering volgens de juiste procedures.
10.5 Problemen oplossen
V: CHECKDB geeft foutmeldingen over 'niet genoeg ruimte' – wat kan ik doen?
A: Maak tempdb-ruimte vrij, verplaats tempdb naar snellere opslag of gebruik de TABLOCK-optie om tempdb-gebruik te verminderen. Overweeg CHECKDB uit te voeren met NOINDEX of PHYSICAL_ONLY om de resourcevereisten te verminderen.
V: Hoe kan ik in de CHECKDB-uitvoer bepalen welke tabel corrupt is?
A: Zoek naar 'object-ID'-nummers in foutmeldingen en gebruik vervolgens: SELECT OBJECT_NAME(object_id)
om tabelnamen te vinden. Foutmeldingen bevatten ook pagina- en slotnummers voor nauwkeurige locatie-identificatie.
V: Kunnen hardwareproblemen ervoor zorgen dat CHECKDB valspositieve resultaten rapporteert?
A: Ja, defecte hardware (met name opslag) kan intermitterende corruptie veroorzaken die verschijnt en verdwijnt tussen CHECKDB-runs. Als de fouten inconsistent zijn, onderzoek dan uw I/O-subsysteem en voer meerdere controles uit om patronen te bevestigen.
10.6 Geavanceerde configuratievragen
V: Welke traceervlaggen kunnen de CHECKDB-prestaties verbeteren?
A: Traceflag 2562 kan de prestaties verbeteren door CHECKDB als één batch uit te voeren. Traceflag 2549 is nuttig wanneer databasebestanden zich op afzonderlijke schijven bevinden. Gebruik deze met zorg en test ze eerst in een niet-productieomgeving.
V: Hoe automatiseer ik de bewaking en waarschuwingen van CHECKDB?
A: Gebruik SQL Server Agentwaarschuwingen voor foutnummers 8930, 8939 en andere. Implementeer logparsing om CHECKDB-resultaten te extraheren en maak meldingen voor eventuele corruptiedetecties. Overweeg het gebruik van frameworks voor onderhoudsoplossingen zoals de scripts van Ola Hallengren.
V: Moet ik de optie EXTENDED_LOGICAL_CHECKS gebruiken?
A: Alleen als u complexe logische corruptie vermoedt en voldoende prestatieoverhead hebt. Deze optie voert extra controles uit op geïndexeerde weergaven, XML-indexen en ruimtelijke indexen, maar verhoogt de uitvoeringstijd aanzienlijk.
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
- 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 - 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