DBCC CHECKDB: MS SQL Server Vejledning til databasetilstand

Økonomiske tab gennemsnitligt 2.3 millioner dollars årligt på grund af datatab, hvor hardwarefejl og korruption er primære årsager (EMC Corporation)
Virksomhedslukningsrater viser, at 50 % af små virksomheder, der oplever datatab på grund af hardwarefejl, går konkurs inden for to år, mens 94 % af virksomheder med katastrofalt datatab slet ikke overlever.
Frekvens af datakorruption påvirker 20% af missionskritiske applikationer årligt og forårsager forstyrrelser i forretningskontinuiteten (Gartner-undersøgelse)
Hardware-relateret korruption tegner sig for 67% af alle datatabshændelser gennem harddisknedbrud og systemfejl, hvor 40% af datatabet er direkte forårsaget af hardwarefejl.
Softwarekorruption costs varierer fra tusinder til millioner af dollars afhængigt af alvor og omfang, hvor 82 % af virksomhederne oplever uplanlagte nedbrud, hvor korruption var en ledende årsag.

1.2 Hvorfor regelmæssige helbredstjek er afgørende

Folk har brug for regelmæssige helbredstjek for at opdage potentielle sygdomme tidligt. Ligeledes har databaser også brug for regelmæssige helbredstjek:

Opdag potentiel korruption tidligt og håndter den omgående, så problemer ikke bliver alvorlige og udbredte, hvilket kan føre til katastrofale konsekvenser for virksomheden.
Sørg for, at databasen fungerer med optimal ydeevne.
Cost Antallet af proaktive databasesundhedstjek er meget lavere end antallet af reaktive datagendannelser efter en databasekatastrofe.

1.3 Introduktion til databaseintegritetskommandoer

SQL Server indeholder adskillige indbyggede kommandoer til at vedligeholde databasetilstanden, med DBCC CHECKDB tjener som most et omfattende værktøj til integritetskontrol tilgængeligt. Disse kommandoer arbejder sammen for at verificere forskellige aspekter af din databasestruktur, fra individuelle tabeller til den samlede databasekonsistens, og danner dermed en komplet vedligeholdelsesstrategi, der holder dine data sikre og tilgængelige.

2. Hvad er DBCC CHECKDB

DBCC CHECKDB is SQL Server's primære værktøj til at verificere databaseintegritet og identificere problemer med korruption.

Det er en T-SQL-sætning, ikke et GUI-værktøj.
Du kan udføre det via almindelige metoder, som f.eks. SQL Server Management Studio (SSMS), SQL Server Agent, SQLCMD osv.

2.1 Hvad CHECKDB rent faktisk tjekker i din database

Når du kører DBCC CHECKDB, udfører kommandoen flere valideringslag på tværs af din databasestruktur:

Bekræftelse af sidechecksums til at opdage fysisk korruption og hardwarerelaterede problemer
Validering af indekskonsistens for at sikre korrekt datahentning og forespørgselsydelse
Kontrol af allokeringsstruktur for at bekræfte nøjagtig pladsudnyttelse og sideallokering
Undersøgelse af referentiel integritet mellem relaterede tabeller og relationer mellem fremmednøgler
Validering af systemtabelkonsistens at sikre SQL Servers interne metadata forbliver pålidelige
Bekræftelse af link til dataside for at bekræfte korrekt sidekædeintegritet
Konsistens i databaseskemaer at validere objektdefinitioner og afhængigheder

Disse omfattende kontroller dækker både brugerdata og systemstrukturer og giver fuldstændigt indblik i din databases sundhedsstatus.

3. Kørsel af DBCC CHECKDB: Trin for trin

3.1 forudsætninger

Nedenfor er tjeklisten før udførelse af enhver DBCC CHECKDB-operation:

Komplet databasebackup – Opret en fuld sikkerhedskopi, før du kører integritetstjek, som dit sikkerhedsnet, hvis der opdages korruption, eller hvis reparationer bliver nødvendige.
De korrekte tilladelser – Du skal have sysadmin- eller db_owner-tilladelser for at udføre DBCC CHECKDB-kommandoer
Tilstrækkelige systemressourcer:
- Hukommelse: 25% af databasestørrelse
- Tempdb-plads: 10-15% af databasestørrelsen
- CPU: 50-70% tilgængelighed under vedligeholdelse
- I/O: Forvent tunge læseoperationer
Databasetilgængelighed – Bekræft, at din database er tilgængelig og ikke i en begrænset tilstand, da CHECKDB kræver læseadgang til alle databasesider

3.2 Grundlæggende kommando

Most Den grundlæggende DBCC CHECKDB-kommando inkluderer tre almindelige variationer:

(1) Tjek den aktuelle database (ingen parametre):

DBCC CHECKDB

(2) Tjek en database efter navn:

DBCC CHECKDB ('YourDatabaseName')

(3) Tjek en database efter ID:

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

Denne grundlæggende kommando udfører en komplet integritetskontrol af den angivne database og undersøger alle tabeller, indekser og systemstrukturer. For databaser med standardnavne uden mellemrum kan du udelade anførselstegnene. Kommandoen kører indtil færdiggørelse og viser statusmeddelelser og endelige resultater. Denne grundlæggende syntaks fungerer perfekt til mindre databaser, eller når du har rigelig vedligeholdelsestid til rådighed.

Nedenfor er et skærmbillede af kørsel af DBCC CHECKDB i SQL Server Management Studio (SSMS):

3.3 Komplette muligheder

Nedenfor er de komplette muligheder for DBCC CHECKDB:

Kategori	Option	Beskrivelse	DBCC CHECKDB eksempel
Reparationsmuligheder	`REPAIR_REBUILD`	Reparationer uden datatab (f.eks. genopbygning af indeks)	`DBCC CHECKDB ('MyDB', REPAIR_REBUILD)`
	`REPAIR_FAST`	Ingen reparation. Kun bagudkompatibilitet.	`DBCC CHECKDB ('MyDB', REPAIR_FAST)`
	`REPAIR_ALLOW_DATA_LOSS`	Reparerer alle fejl (kan forårsage datatab)	`DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)`
Omfangskontrol	`NOINDEX`	Springer ikke-klyngede indekstjek over	`DBCC CHECKDB ('LargeDB', NOINDEX)`
	`PHYSICAL_ONLY`	Kontrollerer kun integriteten af fysisk lagring (sider/poster)	`DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)`
	`DATA_PURITY`	Kontrollerer for logiske kolonneværdifejl (f.eks. ugyldige datoer)	`DBCC CHECKDB ('OldDB', DATA_PURITY)`
	`EXTENDED_LOGICAL_CHECKS`	Dybdegående logiske kontroller (indekserede visninger, XML/spatiale indekser)	`DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)`
Output kontrol	`ALL_ERRORMSGS`	Viser alle fejl (standard: 200 pr. objekt)	`DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)`
Output kontrol	`NO_INFOMSGS`	Skjuler informationsmeddelelser	`DBCC CHECKDB ('MyDB', NO_INFOMSGS)`
Ydeevne	`TABLOCK`	Bruger tabellåse (reducerer TempDB-brug, men blokerer skrivninger)	`DBCC CHECKDB ('BigDB', TABLOCK)`
Ydeevne	`MAXDOP = number`	Tilsidesætter parallelitetsindstillinger	`DBCC CHECKDB ('MyDB', MAXDOP = 2)`
Utility	`ESTIMATEONLY`	Estimerer behovet for TempDB-plads. (ingen egentlig kontrol)	`DBCC CHECKDB ('MyDB', ESTIMATEONLY)`

4. Forståelse af dine resultater

DBCC CHECKDB vil producere forskellige resultater baseret på om dens udførelse fuldføres korrekt eller ej. Lad os forklare dem i detaljer.

4.1 CHECKDB-udførelsen er fuldført

Hvis DBCC CHECKDB-udførelsen fuldføres, vil den rapportere forskellige typer resultater afhængigt af din databases sundhedsstatus.

4.1.1 Ingen problemer fundet

Hvis DBCC CHECKDB ikke finder nogen problemer, vil du se output, der ligner:

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

Dette resultat indikerer, at din database opretholder perfekt integritet på tværs af alle kontrollerede strukturer.

4.1.2 Fundne korruptionsfejl

Når DBCC CHECKDB registrerer en korruptionsfejl, rapporterer den en fejlmeddelelse med følgende struktur:
Vejledning til sværhedsgrad:

Niveau 16-19: Brugerkorrigerbare fejl, ofte mindre beskadigelse
Niveau 20-24: Systemfejl, alvorlig korruption, der kræver øjeblikkelig opmærksomhed
Niveau 25: Fatale fejl, databasen er muligvis ikke tilgængelig

Almindelige fejl omfatter:

Fejl i sidekontrolsum (meddelelse 824)
Allokeringsfejl (meddelelse 8928)
Problemer med indekskonsistens (meddelelse 8964)

Forståelse af meddelelsesstrukturen hjælper med at prioritere handlinger og bestemme passende genopretningsstrategier.

4.1.3 Almindelige informations- og advarselsmeddelelser

Ikke alle DBCC CHECKDB-output indikerer alvorlige problemer. Det kan også vise nogle informations- og advarselsmeddelelser, herunder:

Reparationserklæringer – Meddelelser, der foreslår reparationskommandoer til at løse mindre problemer
Advarsler om tildeling – Advarsler om pladsallokering, der ikke påvirker dataadgang
Anbefalinger til ydeevne – Forslag til vedligeholdelse og optimering af indeks
Informationsmeddelelser – Generelle statusmeddelelser, der ikke kræver øjeblikkelig handling

Disse meddelelser giver værdifuld vejledning i vedligeholdelse, samtidig med at de skelner mellem kritisk korruption, der kræver øjeblikkelig handling, og mindre problemer, der kan løses i løbet af regelmæssige vedligeholdelsesvinduer.

Eksempel på advarselsmeddelelse:

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-udførelse afbrydes

Hvis CHECKDB afbrydes under udførelsen af forskellige årsager, rapporterer den en fejlmeddelelse og tilføjer en fejllog med nedenstående tilstandskoden:

Tilstand	Beskrivelse
`0`	Fejlnummer 8930 blev opstået. Dette indikerer en beskadigelse af metadata, der afsluttede DBCC-kommandoen.
`1`	Fejlnummer 8967 blev opstået. Der var en intern DBCC-fejl.
`2`	Der opstod en fejl under reparation af databasen i nødtilstand.
`3`	Dette indikerer en beskadigelse af metadataene, der afsluttede DBCC-kommandoen.
`4`	Der blev registreret en påstand eller adgangsbrud.
`5`	Der opstod en ukendt fejl, som afsluttede DBCC-kommandoen.

Eksempel på fejlmeddelelse:

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.

Eller

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

Eksempel på fejllog:

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.

I så fald kan du prøve alternative avancerede muligheder som f.eks. DataNumen SQL Recovery for at rette fejlen i din database.

5. Rettelse af korruptionsfejl

5.1 Sikkerhedskopiering og gendannelse: Den sikreste løsning

Når DBCC CHECKDB identificerer korruptionsfejl, er gendannelse fra en ren sikkerhedskopi den sikreste og mest effektive metode.ost pålidelig løsning. Denne tilgang garanterer dataintegritet, samtidig med at den fjerner underliggende årsager til korruption. Før gendannelse skal du verificere backupintegriteten ved hjælp af GENDANN KUN VERIFICERING kommandoer, og overvej tidspunktbaserede gendannelsesmuligheder for at minimere datatab. Dokumenter detaljerne om korruptionen til rodårsagsanalyse, da hardwareproblemer eller softwarefejl kan kræve yderligere opmærksomhed for at forhindre gentagelse.

5.2 Løsninger mod korruption på sideniveau

For isoleret sidekorruption, der påvirker små datadele, SQL Server Enterprise Edition tilbyder sidegendannelsesfunktioner, der reparerer specifikke beskadigede sider uden fuld databasegendannelse. Denne avancerede teknik kræver en fuld gendannelsesmodel og aktuelle logbackups.

Trin-for-trin sidegendannelsesproces:

Identificér den beskadigede side fra CHECKDB-fejlmeddelelsen (f.eks. side 1:256)
Tag en sikkerhedskopi af den aktuelle logfil for at registrere de seneste transaktioner:

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

Gendan den beskadigede side fra m'enost seneste fulde sikkerhedskopiering:

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

Anvend differentiel backup (hvis muligt):

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

Anvend alle logbackups i rækkefølge, inklusive den der lige er oprettet:

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'

Tag en sidste backup og gendan logfilen for at opdatere siden:

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

Alternativ til ikke-kritiske data: Hvis korruption påvirker ikke-kritiske data, kan du eksportere upåvirkede rækker til nye tabeller, før du genopbygger beskadigede strukturer:

-- 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 Hurtige løsninger på indekskorruption

Indekskorruption reagerer ofte godt på genopbygning af operationer, der genskaber indeksstrukturer uden at påvirke underliggende tabeldata:

ALTER INDEX ALL ON YourTable REBUILD

Denne tilgang fungerer særligt godt til ikke-klyngede indekskorruptioner, da genopbygning regenererer indekssider fra kildetabeldata, hvilket effektivt eliminerer korruption, samtidig med at alle originale oplysninger bevares.

6. Brug REPAIR_REBUILD og REPAIR_ALLOW_DATA_LOSS

Hvis de foregående metoder alle mislykkes eller ikke er mulige, kan du bruge mulighederne REPAIR_REBUILD og REPAIR_ALLOW_DATA_LOSS til at reparere databasen.

6.1 REPARATION_GENOPBYGNING (Sikkerere løsning):

Brugt til: Indekskorruption og mindre allokeringsfejl
Datasikkerhed: Forsøger at rette op på korruption uden at slette data
Risikoniveau: Lav – intet datatab forventes
Typiske scenarier: Ikke-klyngede indekskorruption, mindre metadataproblemer
Kommandoeksempel: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Sidste udvej):

Brugt til: Alvorlig korruption, når sikkerhedskopier ikke er tilgængelige
Datasikkerhed: Kan slette beskadigede data for at gendanne databasefunktionaliteten
Risikoniveau: Høj – permanent datatab muligt
Typiske scenarier: Sidebeskadigelse, systemtabelbeskadigelse, fejl i allokeringskæden
Kommandoeksempel: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Bedste praksis for disse muligheder:

Test altid reparationshandlinger på databasekopier, når det er muligt
Tag altid backup før du kører disse muligheder
Dokumentér alle ændringer til overholdelse af regler og fejlfinding
Indstil databasen til enkeltbrugertilstand før reparationsarbejdet påbegyndes

Normalt burde vi prøve REPARATION_GENOPBYGNING mulighed først. Hvis det mislykkes, så prøv REPAIR_ALLOW_DATA_LOSS valgmulighed.

6.4 REPAIR_ALLOW_DATA_LOSS Resultater

6.4.1 Reparation lykkes med datatab

Sommetider REPAIR_ALLOW_DATA_LOSS muligheden vil lykkes, men nogle data manglerost efter reparationen.

Nedenfor er nogle eksempler på beskeder:

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.

Dette skyldes, at DBCC CHECKDB reparerer databasen ved at efterlade nogle beskadigede poster, men faktisk most af dem kan stadig genvindes via DataNumen SQL Recovery.

Eksempelfiler:

SQL Server udgave	Korrupt MDF-fil	MDF-fil rettet af DataNumen SQL Recovery
SQL Server 2014	Fejl10_1.mdf (Meddelelse 8909 efterfulgt af Meddelelse 8939) (600 poster lost med REPAIR_ALLOW_DATA_LOSS)	Fejl10_1_fixed.mdf (Ingen optagelse lost)
SQL Server 2014	Fejl10_2.mdf (Meddelelse 8909 efterfulgt af Meddelelse 8939) (6000 poster (50%) lost med REPAIR_ALLOW_DATA_LOSS)	Fejl10_2_fixed.mdf (Kun 100 poster lost)
SQL Server 2014	Error7 .mdf (100 poster lost med REPAIR_ALLOW_DATA_LOSS)	Fejl7_fixed.mdf (Kun én post lost)

6.4.2 Reparationsfejl – Overvej professionel løsning

If REPAIR_ALLOW_DATA_LOSS fejler, vil den udstede en eller flere fejlmeddelelser.

Nedenfor er nogle eksempler:

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.

I disse scenarier skal du bruge en professionel løsning, som f.eks. DataNumen SQL Recovery at rette din database.

Eksempelfiler

SQL Server udgave	Korrupt MDF-fil	MDF-fil rettet af DataNumen SQL Recovery
SQL Server 2014	Fejl1_3.mdf (Enkelt besked 824)	Fejl1_3_fixed.mdf
SQL Server 2014	Fejl1_1.mdf (Kontinuerlige fejlmeddelelser 824)	Fejl1_1 _fixed.mdf
SQL Server 2014	Fejl1_2.mdf ((Meddelelse 824 efterfulgt af meddelelse 7909)	Fejl1_2_fixed.mdf
SQL Server 2014	Fejl4_1.mdf (Meddelelse 8992 efterfulgt af meddelelse 3852)	Fejl4_1_fixed.mdf
SQL Server 2014	Fejl4_2.mdf (Meddelelse 8992 efterfulgt af meddelelse 3852)	Fejl4_2_fixed.mdf
SQL Server 2014	Fejl5.mdf (Besked 8945)	Fejl5_fixed.mdf
SQL Server 2014	Fejl6.mdf (Besked 2510)	Fejl6_fixed.mdf
SQL Server 2014	Fejl2.mdf (Besked 2575)	Fejl2_fixed.mdf
SQL Server 2014	Fejl11.mdf (Besked 8905)	Fejl11_fixed.mdf
SQL Server 2014	Fejl3.mdf (Besked 5028)	Fejl3_fixed.mdf
SQL Server 2014	Error8 .mdf (Besked 5125)	Error8 _fixed.mdf
SQL Server 2014	Fejl9.mdf (Besked 3313)	Fejl9_fixed.mdf

7. Bedste praksis

7.1 Planlægning af regelmæssige CHECKDB-operationer

Implementer ugentlig DBCC CHECKDB-udførelse for kritiske produktionsdatabaser med daglige kontroller for systemer med høj transaktion. Planlæg operationer i perioder med lav brug for at minimere påvirkning af ydeevnen, og overvej at rotere mellem fulde kontroller og PHYSICAL_ONLY-muligheder baseret på databasestørrelse og vedligeholdelsesvinduer. Automatiseret planlægning gennem SQL Server Agenten sikrer ensartet udførelse, samtidig med at den leverer centraliserede overvågnings- og alarmfunktioner.

7.2 Styring af præstationspåvirkning

DBCC CHECKDB-operationer forbruger betydelige systemressourcer, hvilket potentielt påvirker samtidig brugeraktivitet. Overvåg CPU-udnyttelse, hukommelsesforbrug og disk-I/O under kontroller for at forstå mønstre for ydeevnepåvirkning. Overvej at bruge NOINDEX-indstillinger til rutinekontroller, og reserver fuld validering til månedlige vedligeholdelsesvinduer. Implementer timeout-udvidelser for forespørgsler og brugerkommunikationsstrategier for at styre forventninger under integritetskontrolperioder.

7.3 Planlægning af vedligeholdelsesvindue

Koordinér DBCC CHECKDB-planlægningen med andre vedligeholdelsesaktiviteter som backup-operationer, indeksgenopbygning og statistikopdateringer. Undgå overlappende ressourcekrævende operationer, der kan forårsage forringelse af ydeevnen eller timeout-problemer. Planlæg vedligeholdelsesvinduer baseret på prognoser for databasestørrelse, og sørg for tilstrækkelig tid til fuldstændig integritetsverifikation, efterhånden som datamængderne stiger.

7.4 Automatiseret overvågning og alarmering

Konfigurer SQL Server Agentadvarsler for at underrette administratorer med det samme, når DBCC CHECKDB identificerer korruption. Implementer logparsingløsninger, der udtrækker og kategoriserer resultater af integritetstjek, hvilket muliggør trendanalyse og proaktiv problemidentifikation. Opret eskaleringsprocedurer, der definerer tidsrammer for respons og ansvarligt personale for forskellige alvorlighedsgrader af korruption.

8. DBCC CHECKTABLE: Det lette alternativ

8.1 Hvornår skal CHECKTABLE bruges i stedet for CHECKDB

DBCC CHECKTABLE leverer fokuseret integritetskontrol af individuelle tabeller, hvilket gør den ideel til tarfejlfinding og vedligeholdelse af specifikke databaseobjekter. Brug CHECKTABLE, når du undersøger ydeevneproblemer med bestemte tabeller, validerer kritiske forretningstabeller mellem fulde databasekontroller, eller når tidsbegrænsninger forhindrer fuldstændig databasevalidering. Denne tilgang viser sig at være særligt værdifuld i store databaser, hvor fulde CHECKDB-operationer overstiger de tilgængelige vedligeholdelsesvinduer.

8.2 DBCC CHECKTABLE syntaks og eksempler

Den grundlæggende CHECKTABLE-kommando tarhenter specifikke tabeller:

DBCC CHECKTABLE('YourTable')

Ligesom CHECKDB understøtter CHECKTABLE forskellige muligheder, herunder NOINDEX til ydeevneoptimering og reparationsparametre til løsning af korruption. Du kan også angive skemanavne for præcis tabelidentifikation:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Denne targeted-tilgangen muliggør detaljeret integritetsverifikation, samtidig med at systemets ydeevne opretholdes i åbningstiden.

8.3 Ydelsesfordele for store databaser

CHECKTABLE-operationer udføres betydeligt hurtigere end komplette databasekontroller, hvilket muliggør hyppigere integritetsverifikation af kritiske tabeller. Denne tilgang muliggør daglig validering af vigtige forretningstabeller, samtidig med at omfattende CHECKDB-operationer reserveres til ugentlige eller månedlige tidsplaner. Det reducerede ressourceforbrug gør CHECKTABLE velegnet til udførelse i produktionsmiljøer med minimal brugerpåvirkning.

9. Når CHECKDB fejler

DBCC CHECKDB vil fejle i forskellige scenarier, herunder:

DBCC CHECKDB-udførelse ophører unormalt
DBCC CHECKDB-udførelsen er fuldført, men reparationsmuligheder kunne ikke reparere databasen.

I disse scenarier har vi brug for et mere professionelt værktøj til at hjælpe os med at rette fejlene i databasen.

9.1 Introduktion til DataNumen SQL Recovery

DataNumen SQL Recovery giver mere avancerede funktioner:

Bedste genvindingsgrad i branchen.
Gendan alvorligt beskadigede databasefiler.
Gendan alle databaseobjekter, herunder tabeller, indekser, visninger, triggere, regler og standardindstillinger.
Gendan lagrede procedurer, skalarfunktioner, inline-tabel-værdisatte funktioner og multistatement-tabel-værdisatte funktioner.
Gendan permanent slettede poster.
Dekrypter krypterede objekter i SQL Server databaser.
Reparer MDF-filer i batch.
Omfattende reparationsmuligheder.
Avanceret logning og rapportering.
Support til alle SQL Server versioner.
Tilgængelighed af teknisk support
Regelmæssige opdateringer og forbedringer

9.2 Sammenligning af succesrate

Succesraterne for gendannelse varierer betydeligt:

DBCC CHECKDB & CHECKTABLE: 1.27% gennemsnitlig genvindingsgrad
DataNumen: 92.6% genvindingsgrad

Nedenfor er en komplet konkurrencemæssig sammenligning:

9.3 Genopretning efter alvorlig korruption

Avancerede funktioner til svære tilfælde:

Genopretning fra fysisk beskadiget opbevaring
Gendannelse fra formaterede drev eller nedbrudte systemer
Gendan fra diskbilleder, backup-filer, virtuelle maskine-diskfiler, temporary filer osv.

9.4 Hvornår skal man overveje professionelle løsninger

Ingen nylig sikkerhedskopiering tilgængelig
DBCC CHECKDB fejler
Alvorlige korruptionsscenarier
Håndtering af kritiske forretningsdata
Når tiden er kritisk
Når maksimal restitution er afgørende

10. Ofte stillede spørgsmål

10.1 Grundlæggende brugsspørgsmål

Q: Hvor ofte skal jeg køre DBCC CHECKDB?

A: For kritiske produktionsdatabaser, kør CHECKDB ugentligt. For systemer med mange transaktioner, overvej daglige kontroller ved hjælp af PHYSICAL_ONLY-indstillingen, med fulde kontroller ugentlige. Udviklingsdatabaser kan kontrolleres månedligt.

Q: Kan jeg køre DBCC CHECKDB på en live produktionsdatabase?

A: Ja, DBCC CHECKDB kan køre på online databaser uden at blokere brugere. Det bruger dog betydelige ressourcer, så planlæg det i perioder med lav aktivitet og overvåg systemets ydeevne.

Q: Hvad er forskellen mellem CHECKDB og CHECKTABLE?

A: CHECKDB undersøger hele databasen, mens CHECKTABLE fokuserer på individuelle tabeller. Brug CHECKTABLE til tarfejlfinding eller når du har brug for at kontrollere specifikke tabeller uden at scanne hele databasen.

10.2 Spørgsmål om ydeevne og ressourcer

Q: Hvorfor tager DBCC CHECKDB så lang tid på min store database?

A: CHECKDB-varigheden afhænger af databasestørrelse, hardwareydelse og anvendte indstillinger. Brug PHYSICAL_ONLY til hurtigere kontroller eller NOINDEX til at springe ikke-klyngede indeks over. Overvej at køre under vedligeholdelsesvinduer med dedikerede ressourcer.

Q: Hvor meget tempdb-plads har CHECKDB brug for?

A: Generelt bør du afsætte 10-15% af din databasestørrelse til tempdb under CHECKDB-operationer. Brug ESTIMATEONLY-indstillingen for at få præcise estimater: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY

Q: Kan jeg annullere en kørende CHECKDB-handling?

A: Ja, du kan annullere CHECKDB ved hjælp af KILL-kommandoen på sessions-ID'et. Annullering giver dog ingen oplysninger om databaseintegriteten, og du skal køre den igen senere.

10.3 Spørgsmål om fejlhåndtering

Q: CHECKDB har fundet fejl – skal jeg gå i panik?

A: Gå ikke i panik, men handl hurtigt. Først skal du afgøre, om CHECKDB blev fuldført korrekt, men fandt fejl, eller om CHECKDB selv ikke kunne køre. Kontroller, om fejl kun påvirker ikke-klyngede indeks (mindre kritiske) eller tabeldata (mere alvorlige).

Q: Hvornår skal jeg bruge REPAIR_ALLOW_DATA_LOSS?

A: Kun som en absolut sidste udvej, når du ikke har brugbare sikkerhedskopier, og datatab er acceptabelt sammenlignet med totalt databasetab. Prøv altid at gendanne fra sikkerhedskopien først, da reparationshandlinger kan forårsage permanent datatab.

Q: Hvad betyder "konsistensfejl i databasen" kontra "allokeringsfejl"?

A: Allokeringsfejl påvirker hvordan SQL Server sporer diskpladsforbrug, mens konsistensfejl indikerer problemer med data eller indeksstrukturer. Begge kræver opmærksomhed, men konsistensfejl påvirker typisk datatilgængeligheden mere direkte.

10.4 Spørgsmål om sikkerhedskopiering og gendannelse

Q: Skal jeg køre CHECKDB på mine sikkerhedskopier?

A: Absolut! Kør CHECKDB efter gendannelse af sikkerhedskopier til testservere. Dette verificerer sikkerhedskopiens integritet og sikrer, at du rent faktisk kan gendanne fra beskadigelse. Automatiser denne proces, hvis det er muligt.

Q: Min backup er også beskadiget – hvad nu?

A: Prøv ældre sikkerhedskopier, indtil du finder en ren en. Hvis der ikke findes rene sikkerhedskopier, kan du overveje professionelle gendannelsesløsninger som f.eks. DataNumen SQL RecoveryDokumentér tidslinjen for korruption for at forhindre fremtidige hændelser.

Q: Kan sidegendannelse rette fejl uden fuld databasegendannelse?

A: Ja, men kun i SQL Server Enterprise Edition med fuld gendannelsesmodel og aktuelle logbackups. Sidegendannelse fungerer ved isoleret sidebeskadigelse, men kræver omhyggelig udførelse efter korrekte procedurer.

10.5 Fejlfindingsspørgsmål

Q: CHECKDB fejler med fejlen "ikke nok plads" – hvad kan jeg gøre?

A: Frigør plads i tempdb, flyt tempdb til hurtigere lagerplads, eller brug TABLOCK-indstillingen for at reducere tempdb-forbruget. Overvej at køre CHECKDB med NOINDEX eller PHYSICAL_ONLY for at reducere ressourcekravene.

Q: Hvordan kan jeg identificere, hvilken tabel der er beskadiget, ud fra CHECKDB-outputtet?

A: Søg efter "objekt-ID"-numre i fejlmeddelelser, og brug derefter: SELECT OBJECT_NAME(object_id) for at finde tabelnavne. Fejlmeddelelser inkluderer også side- og pladsnumre til præcis placeringsidentifikation.

Q: Kan hardwareproblemer få CHECKDB til at rapportere falske positiver?

A: Ja, fejlende hardware (især lager) kan forårsage periodisk fejl, der vises og forsvinder mellem CHECKDB-kørsler. Hvis fejlene er inkonsistente, skal du undersøge dit I/O-undersystem og køre flere kontroller for at bekræfte mønstre.

10.6 Spørgsmål om avanceret konfiguration

Q: Hvilke sporingsflag kan forbedre CHECKDB-ydeevnen?

A: Sporingsflag 2562 kan forbedre ydeevnen ved at køre CHECKDB som en enkelt batch. Sporingsflag 2549 er nyttigt, når databasefiler er på separate diske. Brug disse omhyggeligt, og test først i ikke-produktion.

Q: Hvordan automatiserer jeg CHECKDB-overvågning og -advarsler?

A: Brug SQL Server Agentadvarsler for fejlnumrene 8930, 8939 og andre. Implementer logparsing for at udtrække CHECKDB-resultater, og opret meddelelser for eventuelle opdagelser af korruption. Overvej at bruge vedligeholdelsesløsningsframeworks som Ola Hallengrens scripts.

Q: Skal jeg bruge EXTENDED_LOGICAL_CHECKS-indstillingen?

A: Kun hvis du har mistanke om kompleks logisk korruption og har tilstrækkelig ydeevneoverhead. Denne indstilling udfører yderligere kontroller af indekserede visninger, XML-indekser og spatiale indekser, men øger udførelsestiden betydeligt.

11. konklusion

11.1 Sammenfatning af nøglepunkter

11.1.1 Oversigt over vigtige DBCC CHECKDB-kommandoer

Behersk den grundlæggende DBCC CHECKDB-syntaks til omfattende databasekontrol, brug NOINDEX- og PHYSICAL_ONLY-indstillingerne til ydeevneoptimering og forstå CHECKTABLE til tarverifikation af geted-tabel. Disse grundlæggende kommandoer danner grundlaget for proaktiv databasevedligeholdelse, hvilket muliggør tidlig detektion af korruption og systematisk integritetsovervågning.

11.1.2 Påmindelse om kritiske bedste praksisser

Sørg altid for at have aktuelle sikkerhedskopier, før du kører integritetstjek, planlæg regelmæssige CHECKDB-operationer baseret på databasekritik, og implementer automatiseret overvågning for øjeblikkelige advarsler om korruption. Husk, at forebyggelse gennem regelmæssig overvågning overgår reaktive tilgange, og professionelle gendannelsesløsninger giver værdifulde backupmuligheder, når standardværktøjer viser sig at være utilstrækkelige.

11.2 Hvornår skal man bruge DBCC CHECKDB vs. avancerede løsninger

Brug DBCC CHECKDB til rutinemæssig integritetsovervågning og mindre korruptionsløsninger, mens du reserverer professionelle gendannelsesværktøjer til alvorlige korruptionsscenarier ud over indbyggede reparationsmuligheder. Beslutningsrammen bør tage hensyn til backuptilgængelighed, datakritikalitet, tidsbegrænsninger og korruptionsalvorlighed. Succesfulde databaseadministratorer kombinerer regelmæssig CHECKDB-overvågning med omfattende backupstrategier og bevidsthed om avancerede gendannelsesmuligheder, når standardmetoder viser sig at være utilstrækkelige.

11.3 Hurtig daglig sundhedstjekliste for databaseadministratorer

Udover at køre DBCC CHECKDB, skal du opretholde optimal databasetilstand med disse vigtige daglige rutiner:

1. Bekræft sikkerhedskopiens integritet

Bekræft, at planlagte sikkerhedskopier er gennemført
Brug RESTORE VERIFYONLY til at bekræfte læsbarheden af sikkerhedskopien
Sørg for, at eksterne kopier er synkroniserede og tilgængelige

Du kan også få flere oplysninger fra vores omfattende guide om SQL Server backup.

2. Gennemgå konsistensstatus

Tjek automatiserede DBCC CHECKDB-resultater fra kørsler natten over
Overvåg SQL Server fejllogge for advarsler om korruption
Undersøg eventuelle integritetsfejl med det samme

3. Overvåg serversundhed

Tjek CPU-, hukommelses- og disk-I/O-målinger
Bekræft tilgængelighed af tempdb-plads
Identificer blokerede processer og langvarige forespørgsler

4. Spor dødvandeaktivitet

Gennemgå deadlock-grafer fra systemtilstandshændelser
Identificer problematiske forespørgsler og optimer med udviklingsteams
Overvåg antallet af ofre for fastlåste situationer og deres indvirkning på forretningen

Vigtige påmindelser

Undgå hyppig databasekrympning – det øger fragmenteringen og forringer ydeevnen. Formindsk kun efter større datasletning, når det virkelig er nødvendigt.
Automatiser overvågningsopgaver ved brug af SQL Server Agentjob eller vedligeholdelsesplaner med advarsler om kritiske problemer.
Test af procedurer for genopretning efter katastrofe ugentligt for at sikre, at sikkerhedskopier kan gendannes, og at gendannelsesmålene forbliver opnåelige.

Ved at kombinere denne daglige tjekliste med regelmæssige DBCC CHECKDB-operationer, skaber du omfattende beskyttelse af dit databasemiljø gennem proaktiv overvågning og hurtig problemhåndtering.

12. Referencer

Microsoft Learn. “DBCC CHECKDB (Transact-SQL).” SQL Server DokumentationMicrosoft Corporation.
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
Microsoft Learn. "Fejlfinding af databasekonsistensfejl rapporteret af DBCC CHECKDB." SQL Server DokumentationMicrosoft Corporation.
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors

DBCC CHECKDB: Komplet guide til MS SQL Server Databasesundhed (2026)

1. Vigtigheden af SQL Server Databasesundhed

1.1 Hvilken databasekorruption CostVirksomheder