DBCC CHECKDB: Komplett guide til MS SQL Server Databasehelse (2025)

Databasekorrupsjon er alt SQL Server administratorens mareritt. Når kritiske forretningsdata blir utilgjengelige eller upålitelige, vil cost kan være ødeleggende. Denne omfattende veiledningen dekker alt du trenger å vite om bruk av DBCC CHECKDB for å opprettholde databasehelse og forhindre korrupsjon, pluss avanserte gjenopprettingsløsninger for når standardverktøy ikke er nok.

1. Viktigheten av SQL Server Databasetilstand

1.1 Hvilken databasekorrupsjon Costs Bedrifter

I dag, most Bedrifter lagrer kritiske data i databaser. Når databasekorrupsjon oppstår, er konsekvensene katastrofale:

• Økonomiske tap gjennomsnittlig 2.3 millioner dollar årlig på grunn av datatap, med maskinvarefeil og korrupsjon som hovedårsaker (EMC Corporation)
• Antall nedleggelser av bedrifter viser at 50 % av små bedrifter som opplever datatap på grunn av maskinvarefeil går konkurs innen to år, mens 94 % av bedrifter med katastrofalt datatap ikke overlever i det hele tatt.
• Frekvens av datakorrupsjon påvirker 20 % av forretningskritiske applikasjoner årlig, noe som forårsaker forstyrrelser i forretningskontinuiteten (Gartner-undersøkelse)
• Maskinvarerelatert korrupsjon står for 67 % av alle datataphendelser gjennom harddiskkrasj og systemfeil, hvor 40 % av datatapet er direkte knyttet til maskinvarefeil.
• Programvarekorrupsjon costs varierer fra tusenvis til millioner av dollar avhengig av alvorlighetsgrad og omfang, med 82 % av bedriftene som opplever uplanlagte driftsavbrudd der korrupsjon var en ledende årsak

1.2 Hvorfor regelmessige helsesjekker er avgjørende

Folk trenger regelmessige helsesjekker for å oppdage potensielle sykdommer tidlig. På samme måte trenger også databaser regelmessige helsesjekker:

1. Oppdag potensiell korrupsjon tidlig og håndter den raskt, for å forhindre at problemene blir alvorlige og utbredte, noe som kan føre til katastrofale konsekvenser for virksomheten.
2. Sørg for at databasen fungerer med optimal ytelse.
3. Cost Antall proaktive databasehelsekontroller er mye lavere enn antall reaktive datagjenoppretting etter at en databasekatastrofe har inntruffet.

1.3 Introduksjon til databaseintegritetskommandoer

SQL Server tilbyr flere innebygde kommandoer for å opprettholde databasetilstand, med DBCC CHECKDB tjener som most et omfattende verktøy for integritetskontroll tilgjengelig. Disse kommandoene samarbeider for å verifisere ulike aspekter ved databasestrukturen, fra individuelle tabeller til fullstendig databasekonsistens, og danner en komplett vedlikeholdsstrategi som holder dataene dine trygge og tilgjengelige.

2. Hva er DBCC CHECKDB

DBCC CHECKDB is SQL Servers primære verktøy for å verifisere databaseintegritet og identifisere korrupsjonsproblemer.

• Det er en T-SQL-setning, ikke et GUI-verktøy.
• Du kan utføre det via vanlige metoder, som for eksempel SQL Server Ledelsestudio (SSMS), SQL Server Agent, SQLCMD, osv.

2.1 Hva CHECKDB faktisk sjekker i databasen din

Når du kjører DBCC CHECKDB, utfører kommandoen flere valideringslag på tvers av databasestrukturen:

• Verifisering av sidesjekksummer for å oppdage fysisk korrupsjon og maskinvarerelaterte problemer
• Validering av indekskonsistens for å sikre riktig datainnhenting og spørringsytelse
• Kontroller av allokeringsstruktur for å bekrefte nøyaktig plassbruk og sideallokering
• Undersøkelse av referanseintegritet mellom relaterte tabeller og fremmednøkkelrelasjoner
• Validering av konsistens i systemtabeller for å sikre SQL Servers interne metadata forblir pålitelige
• Verifisering av kobling til datasider for å bekrefte riktig sidekjedeintegritet
• Konsistens i databaseskjemaer for å validere objektdefinisjoner og avhengigheter

Disse omfattende kontrollene dekker både brukerdata og systemstrukturer, og gir fullstendig innsikt i databasens helsestatus.

3. Kjøre DBCC CHECKDB: Steg for steg

3.1 Forutsetninger

Nedenfor er sjekklisten før du utfører en DBCC CHECKDB-operasjon:

• Fullstendig sikkerhetskopiering av databasen – Lag en fullstendig sikkerhetskopi før du kjører integritetskontroller, som et sikkerhetsnett hvis det oppdages korrupsjon eller reparasjoner blir nødvendige.
• Riktige tillatelser – Du trenger sysadmin- eller db_owner-tillatelser for å kjøre DBCC CHECKDB-kommandoer
• Tilstrekkelige systemressurser:
  • Minne: 25 % av databasestørrelsen
  • Tempdb-plass: 10–15 % av databasestørrelsen
  • CPU: 50–70 % tilgjengelighet under vedlikehold
  • I/O: Forvent tunge leseoperasjoner
• Databasetilgjengelighet – Bekreft at databasen din er tilgjengelig og ikke i en begrenset tilstand, ettersom CHECKDB krever lesetilgang til alle databasesider

3.2 Grunnleggende kommando

Most Den grunnleggende DBCC CHECKDB-kommandoen inkluderer tre vanlige varianter:

(1) Sjekk gjeldende database (ingen parametere):

DBCC CHECKDB

(2) Sjekk en database etter navn:

DBCC CHECKDB ('YourDatabaseName')

(3) Sjekk en database etter ID:

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

Denne grunnleggende kommandoen utfører en fullstendig integritetssjekk av den angitte databasen, og undersøker alle tabeller, indekser og systemstrukturer. For databaser med standardnavn uten mellomrom, kan du utelate anførselstegn. Kommandoen vil kjøre til den er fullført, og vise fremdriftsmeldinger og endelige resultater. Denne grunnleggende syntaksen fungerer perfekt for mindre databaser eller når du har god vedlikeholdstid tilgjengelig.

Nedenfor er et skjermbilde av kjøring av DBCC CHECKDB i SQL Server Management Studio (SSMS):

3.3 Komplette alternativer

Nedenfor finner du de komplette alternativene for DBCC CHECKDB:

Kategori	Alternativ	Beskrivelse	DBCC CHECKDB-eksempel
Reparasjonsalternativer	REPAIR_REBUILD	Reparasjoner uten datatap (f.eks. gjenoppbygging av indekser)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Ingen reparasjon. Kun bakoverkompatibilitet.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Reparerer alle feil (kan forårsake datatap)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Omfangskontroll	NOINDEX	Hopper over ikke-klyngede indekskontroller	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Kontrollerer kun integriteten til fysisk lagring (sider/poster)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Sjekker for logiske kolonneverdifeil (f.eks. ugyldige datoer)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Dype logiske kontroller (indekserte visninger, XML/spatiale indekser)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Utgangskontroll	ALL_ERRORMSGS	Viser alle feil (standard: 200 per objekt)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Skjuler informasjonsmeldinger	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Ytelse	TABLOCK	Bruker tabelllåser (reduserer TempDB-bruk, men blokkerer skriving)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Overstyrer parallellitetsinnstillinger	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Utility	ESTIMATEONLY	Estimerer behovet for TempDB-plass. (ingen faktisk sjekk)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Forstå resultatene dine

DBCC CHECKDB vil produsere forskjellige resultater basert på om utførelsen fullføres eller ikke. La oss forklare dem i detalj.

4.1 CHECKDB-kjøringen er fullført

Hvis DBCC CHECKDB-kjøringen fullføres, vil den rapportere forskjellige typer resultater avhengig av databasens helsestatus.

4.1.1 Ingen problemer funnet

Hvis DBCC CHECKDB ikke finner noen problemer, vil du se utdata som ligner på:

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 resultatet indikerer at databasen din opprettholder perfekt integritet på tvers av alle kontrollerte strukturer.

4.1.2 Funnet korrupsjonsfeil

Når DBCC CHECKDB oppdager en korrupsjonsfeil, vil den rapportere en feilmelding med følgende struktur:
Veiledning for alvorlighetsnivå:

• Nivå 16-19: Brukerkorrigerbare feil, ofte mindre korrupsjon
• Nivå 20-24: Systemfeil, alvorlig korrupsjon som krever umiddelbar oppmerksomhet
• Nivå 25: Fatale feil, databasen kan være utilgjengelig

Vanlige feil inkluderer:

• Feil med sidesjekksum (melding 824)
• Allokeringsfeil (melding 8928)
• Problemer med indekskonsistens (melding 8964)

Å forstå meldingsstrukturen hjelper med å prioritere responstiltak og bestemme passende gjenopprettingsstrategier.

4.1.3 Vanlige informasjons- og advarselsmeldinger

Ikke all DBCC CHECKDB-utdata indikerer alvorlige problemer. Den kan også sende ut informasjons- og advarselsmeldinger, inkludert:

• Reparasjonserklæringer – Meldinger som foreslår reparasjonskommandoer for å fikse mindre problemer
• Tildelingsvarsler – Advarsler om plasstildeling som ikke påvirker datatilgang
• Ytelsesanbefalinger – Forslag til vedlikehold og optimalisering av indekser
• Informasjonsmeldinger – Generelle statusmeldinger som ikke krever umiddelbar handling

Disse meldingene gir verdifull vedlikeholdsveiledning, samtidig som de skiller mellom kritisk korrupsjon som krever umiddelbar handling og mindre problemer som kan løses i løpet av vanlige vedlikeholdsvinduer.

Eksempel på advarselsmelding:

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-kjøring avbrytes

Hvis CHECKDB avbrytes under kjøringen av ulike årsaker, vil den rapportere en feilmelding og legge til en feillogg med tilstandskoden nedenfor:

Tilstand	Beskrivelse
0	Feilnummer 8930 ble oppstått. Dette indikerer en feil i metadataene som avsluttet DBCC-kommandoen.
1	Feilnummer 8967 ble oppstått. Det oppsto en intern DBCC-feil.
2	Det oppsto en feil under reparasjon av databasen i nødmodus.
3	Dette indikerer en feil i metadataene som avsluttet DBCC-kommandoen.
4	Det ble oppdaget et påstands- eller tilgangsbrudd.
5	Det oppsto en ukjent feil som avsluttet DBCC-kommandoen.

Eksempel på feilmelding:

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.

or

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å feillogg:

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 slike tilfeller kan du prøve alternative avanserte alternativer som DataNumen SQL Recovery for å fikse feilen i databasen din.

5. Retting av korrupsjonsfeil

5.1 Sikkerhetskopiering og gjenoppretting: Den sikreste løsningen

Når DBCC CHECKDB identifiserer korrupsjonsfeil, er gjenoppretting fra en ren sikkerhetskopi det sikreste og mest effektive alternativet.ost pålitelig løsning. Denne tilnærmingen garanterer dataintegritet samtidig som den eliminerer underliggende årsaker til korrupsjon. Før gjenoppretting, bekreft sikkerhetskopiens integritet ved hjelp av GJENOPPRETT KUN VERIFY kommandoer, og vurder alternativer for gjenoppretting på et gitt tidspunkt for å minimere datatap. Dokumenter korrupsjonsdetaljene for rotårsaksanalyse, da maskinvareproblemer eller programvarefeil kan kreve ekstra oppmerksomhet for å forhindre gjentakelse.

5.2 Løsninger for korrupsjon på sidenivå

For isolert sidekorrupsjon som påvirker små datadeler, SQL Server Enterprise Edition tilbyr funksjoner for sidegjenoppretting som reparerer spesifikke skadede sider uten fullstendig databasegjenoppretting. Denne avanserte teknikken krever en fullstendig gjenopprettingsmodell og sikkerhetskopier av gjeldende loggfiler.

Steg-for-steg-prosess for gjenoppretting av siden:

1. Identifiser den ødelagte siden fra CHECKDB-feilmelding (f.eks. side 1:256)
2. Ta en sikkerhetskopi av en gjeldende logg for å registrere nylige transaksjoner:

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

3. Gjenopprett den ødelagte siden fra most nylig full sikkerhetskopi:

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

4. Bruk differensiell sikkerhetskopiering (hvis tilgjengelig):

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

5. Bruk alle sikkerhetskopier av loggfiler i rekkefølge, inkludert den som nettopp ble opprettet:

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. Ta en siste sikkerhetskopi og gjenopprett loggfiler for å gjøre siden oppdatert:

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

Alternativ for ikke-kritiske data: Hvis korrupsjon påvirker ikke-kritiske data, kan du eksportere upåvirkede rader til nye tabeller før du gjenoppbygger ødelagte 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 Hurtigløsninger på indekskorrupsjon

Indekskorrupsjon responderer ofte bra på gjenoppbygging av operasjoner som gjenskaper indeksstrukturer uten å påvirke underliggende tabelldata:

ALTER INDEX ALL ON YourTable REBUILD

Denne tilnærmingen fungerer spesielt bra for ikke-klyngede indekskorrupsjoner, ettersom gjenoppbygging regenererer indekssider fra kildetabelldata, noe som effektivt eliminerer korrupsjon samtidig som all originalinformasjon bevares.

6. Bruk REPAIR_REBUILD og REPAIR_ALLOW_DATA_LOSS

Hvis de foregående metodene mislykkes eller ikke er gjennomførbare, kan du bruke alternativene REPAIR_REBUILD og REPAIR_ALLOW_DATA_LOSS for å reparere databasen.

6.1 REPARASJON_OMBYGGING (Tryggere alternativ):

• Bruke til: Indekskorrupsjon og mindre allokeringsfeil
• Datasikkerhet: Forsøker å rette opp korrupsjon uten å slette data
• Risikonivå: Lav – ingen datatap forventet
• Typiske scenarioer: Ikke-klynget indekskorrupsjon, mindre metadataproblemer
• Kommandoeksempel: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Siste utvei):

• Bruke til: Alvorlig korrupsjon når sikkerhetskopier ikke er tilgjengelige
• Datasikkerhet: Kan slette ødelagte data for å gjenopprette databasefunksjonaliteten
• Risikonivå: Høy – permanent datatap mulig
• Typiske scenarioer: Sidekorrupsjon, skade på systemtabell, feil i allokeringskjeden
• Kommandoeksempel: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Beste praksis for disse alternativene:

• Test alltid reparasjonsoperasjoner på databasekopier når det er mulig
• Ta alltid sikkerhetskopi før du kjører disse alternativene
• Dokumenter alle endringer for samsvar og feilsøking
• Sett databasen til enkeltbrukermodus før du utfører reparasjonsarbeid

Normalt sett burde vi prøve REPARASJON_OMBYGGING alternativet først. Hvis det mislykkes, prøv REPAIR_ALLOW_DATA_LOSS alternativet.

6.4 REPAIR_ALLOW_DATA_LOSS-resultater

6.4.1 Reparasjon lykkes med datatap

Noen ganger er REPAIR_ALLOW_DATA_LOSS alternativet vil lykkes, men noen data er ikkeost etter reparasjonen.

Nedenfor er noen eksempelmeldinger:

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 er fordi DBCC CHECKDB fikser databasen ved å forlate noen skadede poster, men faktisk, most av dem kan fortsatt gjenopprettes via DataNumen SQL Recovery.

Eksempelfiler:

SQL Server versjon	Korrupt MDF-fil	MDF-fil fikset av DataNumen SQL Recovery
SQL Server 2014	Error10_1.mdf (Melding 8909 etterfulgt av melding 8939) (600 poster lost med REPAIR_ALLOW_DATA_LOSS)	Error10_1_fixed.mdf (Ingen registrering lost)
SQL Server 2014	Error10_2.mdf (Melding 8909 etterfulgt av melding 8939) (6000 poster (50 %) lost med REPAIR_ALLOW_DATA_LOSS)	Error10_2_fixed.mdf (Kun 100 poster lost)
SQL Server 2014	Error7MDF (100 poster lost med REPAIR_ALLOW_DATA_LOSS)	Error7_fixed.mdf (Bare én post lost)

6.4.2 Reparasjonsfeil – vurder profesjonell løsning

If REPAIR_ALLOW_DATA_LOSS mislykkes, vil den sende ut én eller flere feilmeldinger.

Nedenfor er noen 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 slike tilfeller må du bruke en profesjonell løsning, som f.eks. DataNumen SQL Recovery for å fikse databasen din.

Eksempelfiler

SQL Server versjon	Korrupt MDF-fil	MDF-fil fikset av DataNumen SQL Recovery
SQL Server 2014	Error1_3.mdf (Enkeltmelding 824)	Error1_3_fixed.mdf
SQL Server 2014	Error1_1.mdf (Kontinuerlige meldingsfeil 824)	Feil1_1_fixed.mdf
SQL Server 2014	Error1_2.mdf ((Melding 824 etterfulgt av melding 7909)	Error1_2_fixed.mdf
SQL Server 2014	Error4_1.mdf (Melding 8992 etterfulgt av melding 3852)	Error4_1_fixed.mdf
SQL Server 2014	Error4_2.mdf (Melding 8992 etterfulgt av melding 3852)	Error4_2_fixed.mdf
SQL Server 2014	Feil5.mdf (Melding 8945)	Error5_fixed.mdf
SQL Server 2014	Feil6.mdf (Melding 2510)	Error6_fixed.mdf
SQL Server 2014	Feil2.mdf (Melding 2575)	Error2_fixed.mdf
SQL Server 2014	Feil11.mdf (Melding 8905)	Error11_fixed.mdf
SQL Server 2014	Feil3.mdf (Melding 5028)	Error3_fixed.mdf
SQL Server 2014	Error8MDF (Melding 5125)	Error8_fixed.mdf
SQL Server 2014	Feil9.mdf (Melding 3313)	Error9_fixed.mdf

7. Beste praksis

7.1 Planlegging av regelmessige CHECKDB-operasjoner

Implementer ukentlig DBCC CHECKDB-kjøring for kritiske produksjonsdatabaser, med daglige kontroller for systemer med høy transaksjon. Planlegg operasjoner i perioder med lav bruk for å minimere ytelsespåvirkning, og vurder å veksle mellom fullstendige kontroller og PHYSICAL_ONLY-alternativer basert på databasestørrelse og vedlikeholdsvinduer. Automatisert planlegging gjennom SQL Server Agenten sikrer konsekvent utførelse samtidig som den tilbyr sentraliserte overvåkings- og varslingsfunksjoner.

7.2 Styring av ytelsespåvirkning

DBCC CHECKDB-operasjoner bruker betydelige systemressurser, noe som potensielt påvirker samtidig brukeraktivitet. Overvåk CPU-utnyttelse, minneforbruk og disk-I/O under kontroller for å forstå ytelsespåvirkningsmønstre. Vurder å bruke NOINDEX-alternativer for rutinekontroller, og reserver full validering for månedlige vedlikeholdsvinduer. Implementer tidsavbruddsutvidelser for spørringer og strategier for brukerkommunikasjon for å håndtere forventninger under integritetskontrollperioder.

7.3 Planlegging av vedlikeholdsvindu

Koordiner DBCC CHECKDB-planleggingen med andre vedlikeholdsaktiviteter som sikkerhetskopiering, gjenoppbygging av indekser og statistikkoppdateringer. Unngå overlappende ressurskrevende operasjoner som kan forårsake ytelsesforringelse eller problemer med tidsavbrudd. Planlegg vedlikeholdsvinduer basert på prognoser for databasestørrelsesvekst, og sørg for tilstrekkelig tid til fullstendig integritetsverifisering etter hvert som datavolumene øker.

7.4 Automatisert overvåking og varsling

Konfigurer SQL Server Agentvarsler for å varsle administratorer umiddelbart når DBCC CHECKDB identifiserer korrupsjon. Implementer loggparseringsløsninger som trekker ut og kategoriserer resultater av integritetssjekker, noe som muliggjør trendanalyse og proaktiv problemidentifisering. Opprett eskaleringsprosedyrer som definerer tidsrammer for respons og ansvarlig personell for ulike alvorlighetsgrader av korrupsjon.

8. DBCC CHECKTABLE: Det lette alternativet

8.1 Når skal CHECKTABLE brukes i stedet for CHECKDB

DBCC CHECKTABLE tilbyr fokusert integritetskontroll for individuelle tabeller, noe som gjør den ideell for tarfeilsøking og vedlikehold av spesifikke databaseobjekter. Bruk CHECKTABLE når du undersøker ytelsesproblemer med bestemte tabeller, validerer kritiske forretningstabeller mellom fullstendige databasekontroller, eller når tidsbegrensninger forhindrer fullstendig databasevalidering. Denne tilnærmingen viser seg å være spesielt verdifull i store databaser der fullstendige CHECKDB-operasjoner overskrider tilgjengelige vedlikeholdsvinduer.

8.2 DBCC CHECKTABLE-syntaks og eksempler

Den grunnleggende CHECKTABLE-kommandoen tarfår spesifikke tabeller:

DBCC CHECKTABLE('YourTable')

I likhet med CHECKDB støtter CHECKTABLE diverse alternativer, inkludert NOINDEX for ytelsesoptimalisering og reparasjonsparametere for korrupsjonsløsning. Du kan også angi skjemanavn for presis tabellidentifikasjon:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Dette targeted-tilnærmingen tillater detaljert integritetsverifisering samtidig som systemytelsen opprettholdes i arbeidstiden.

8.3 Ytelsesfordeler for store databaser

CHECKTABLE-operasjoner fullføres betydelig raskere enn fullstendige databasekontroller, noe som muliggjør hyppigere integritetsverifisering av kritiske tabeller. Denne tilnærmingen tillater daglig validering av viktige forretningstabeller samtidig som omfattende CHECKDB-operasjoner reserveres for ukentlige eller månedlige tidsplaner. Det reduserte ressursforbruket gjør CHECKTABLE egnet for utførelse i produksjonsmiljøer med minimal brukerpåvirkning.

9. Når CHECKDB mislykkes

DBCC CHECKDB vil mislykkes i ulike scenarier, inkludert:

• DBCC CHECKDB-utførelse avsluttes unormalt
• DBCC CHECKDB-kjøringen er fullført, men reparasjonsalternativer klarer ikke å reparere databasen.

I slike tilfeller trenger vi et mer profesjonelt verktøy som kan hjelpe oss med å fikse feilene i databasen.

9.1 Introduksjon til DataNumen SQL Recovery

DataNumen SQL Recovery tilbyr mer avanserte funksjoner:

• Beste utvinningsgrad i bransjen.
• Gjenopprett alvorlig ødelagte databasefiler.
• Gjenopprett alle databaseobjekter, inkludert tabeller, indekser, visninger, utløsere, regler og standardinnstillinger.
• Gjenopprett lagrede prosedyrer, skalarfunksjoner, innebygde funksjoner med tabellverdi og flersetningstabellverdier.
• Gjenopprett permanent slettede poster.
• Dekrypter krypterte objekter i SQL Server databaser.
• Reparer MDF-filer i batch.
• Omfattende reparasjonsmuligheter.
• Avansert logging og rapportering.
• Støtte for alle SQL Server versjoner.
• Tilgjengelighet av teknisk støtte
• Regelmessige oppdateringer og forbedringer

9.2 Sammenligning av suksessrate

Suksessrater for gjenoppretting varierer betydelig:

• DBCC SJEKKDB OG SJEKKTABELL: 1.27% gjennomsnittlig utvinningsgrad
• DataNumen: 92.6% utvinningsgrad

Nedenfor er en komplett konkurransesammenligning:

9.3 Gjenoppretting fra alvorlig korrupsjon

Avanserte funksjoner for alvorlige tilfeller:

• Gjenoppretting fra fysisk skadet lagring
• Gjenoppretting fra formaterte stasjoner eller krasjet systemer
• Gjenopprett fra diskbilder, sikkerhetskopifiler, virtuelle maskindiskfiler, temporary filer osv.

9.4 Når bør man vurdere profesjonelle løsninger

• Ingen nylig sikkerhetskopiering tilgjengelig
• DBCC CHECKDB mislykkes
• Alvorlige korrupsjonsscenarier
• Håndtering av kritiske forretningsdata
• Når tiden er kritisk
• Når maksimal restitusjon er avgjørende

10. Vanlige spørsmål

11. konklusjon

11.1 Sammendrag av nøkkelpunkter

11.1.1 Oppsummering av viktige DBCC CHECKDB-kommandoer

Mestre den grunnleggende DBCC CHECKDB-syntaksen for omfattende databasesjekk, bruk NOINDEX- og PHYSICAL_ONLY-alternativene for ytelsesoptimalisering, og forstå CHECKTABLE for tarverifisering av geted-tabellen. Disse grunnleggende kommandoene danner grunnlaget for proaktivt databasevedlikehold, og muliggjør tidlig oppdagelse av korrupsjon og systematisk integritetsovervåking.

11.1.2 Viktig påminnelse om beste praksis

Sørg alltid for oppdaterte sikkerhetskopier før du kjører integritetskontroller, planlegg regelmessige CHECKDB-operasjoner basert på databasekritikkalitet, og implementer automatisert overvåking for umiddelbare varsler om korrupsjon. Husk at forebygging gjennom regelmessig overvåking overgår reaktive tilnærminger, og profesjonelle gjenopprettingsløsninger gir verdifulle sikkerhetskopieringsalternativer når standardverktøy viser seg å være utilstrekkelige.

11.2 Når skal man bruke DBCC CHECKDB kontra avanserte løsninger

Bruk DBCC CHECKDB for rutinemessig integritetsovervåking og mindre korrupsjonsløsninger, samtidig som du reserverer profesjonelle gjenopprettingsverktøy for alvorlige korrupsjonsscenarier utover innebygde reparasjonsmuligheter. Beslutningsrammeverket bør vurdere tilgjengelighet av sikkerhetskopier, datakritiskhet, tidsbegrensninger og alvorlighetsgrad av korrupsjon. Suksessrike databaseadministratorer kombinerer regelmessig CHECKDB-overvåking med omfattende sikkerhetskopieringsstrategier og bevissthet om avanserte gjenopprettingsalternativer når standardmetoder viser seg å være utilstrekkelige.

12. Referanser

1. Microsoft Learn. «DBCC CHECKDB (Transact-SQL).» SQL Server Teknisk dokumentasjonMicrosoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. «Feilsøk databasekonsistensfeil rapportert av DBCC CHECKDB.» SQL Server Teknisk dokumentasjonMicrosoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors