DBCC CHECKDB: Komplett guide till MS SQL Server Databashälsa (2025)

DBCC CHECKDB är SQL Servers huvudsakliga databasintegritetsverktyg. Lär dig hur du använder det med exempel, åtgärdar korruption och optimerar prestanda.

3. Köra DBCC CHECKDB: Steg för steg

3.1 Förutsättningar

Nedan följer checklistan innan du kör någon DBCC CHECKDB-operation:

• Fullständig säkerhetskopiering av databasen – Skapa en fullständig säkerhetskopia innan du kör integritetskontroller som ditt skyddsnät om korruption upptäcks eller reparationer blir nödvändiga.
• Rätt behörigheter – Du behöver sysadmin- eller db_owner-behörighet för att köra DBCC CHECKDB-kommandon
• Tillräckliga systemresurser:
  • Minne: 25 % av databasens storlek
  • Tempdb-utrymme: 10–15 % av databasens storlek
  • CPU: 50–70 % tillgänglighet under underhåll
  • I/O: Förvänta dig tunga läsoperationer
• Databastillgänglighet – Kontrollera att din databas är tillgänglig och inte i ett begränsat tillstånd, eftersom CHECKDB kräver läsåtkomst till alla databassidor

3.2 Grundläggande kommando

Den most grundläggande DBCC CHECKDB-kommando inkluderar tre vanliga varianter:

(1) Kontrollera den aktuella databasen (inga parametrar):

DBCC CHECKDB

(2) Kontrollera en databas efter namn:

DBCC CHECKDB ('YourDatabaseName')

Lagring Kontrollera en databas efter ID:

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

Detta grundläggande kommando utför en fullständig integritetskontroll av den angivna databasen och undersöker alla tabeller, index och systemstrukturer. För databaser med standardnamn utan mellanslag kan du utelämna citattecken. Kommandot körs tills det är klart och visar förloppsmeddelanden och slutresultat. Denna grundläggande syntax fungerar perfekt för mindre databaser eller när du har gott om underhållstid tillgänglig.

Nedan visas en skärmdump av hur man kör DBCC CHECKDB i SQL Server Management Studio (SSMS):

3.3 Kompletta alternativ

Nedan följer de fullständiga alternativen för DBCC CHECKDB:

Kategori	Alternativet	BESKRIVNING	DBCC CHECKDB-exempel
Reparationsalternativ	REPAIR_REBUILD	Reparationer utan dataförlust (t.ex. ombyggnad av index)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Ingen reparation. Endast bakåtkompatibilitet.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Reparerar alla fel (kan orsaka dataförlust)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Omfattningskontroll	NOINDEX	Hoppar över icke-klustrade indexkontroller	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Kontrollerar endast den fysiska lagringens integritet (sidor/poster)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Kontrollerar logiska kolumnvärdesfel (t.ex. ogiltiga datum)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Djupgående logiska kontroller (indexerade vyer, XML/spatiala index)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Utgångskontroll	ALL_ERRORMSGS	Visar alla fel (standard: 200 per objekt)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Döljer informationsmeddelanden	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Prestanda	TABLOCK	Använder tabelllås (minskar TempDB-användning men blockerar skrivningar)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Åsidosätter parallellitetsinställningar	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Verktyget	ESTIMATEONLY	Uppskattar behovet av TempDB-utrymme. (ingen faktisk kontroll)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Förstå dina resultat

DBCC CHECKDB kommer att producera olika resultat baserat på om dess körning slutförs korrekt eller inte. Låt oss förklara dem i detalj.

4.1 CHECKDB-körningen slutfördes

Om DBCC CHECKDB-körningen slutförs korrekt kommer den att rapportera olika typer av resultat beroende på databasens hälsostatus.

4.1.1 Inga problem hittades

Om DBCC CHECKDB inte hittar några problem ser du utdata som liknar:

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

Detta resultat indikerar att din databas upprätthåller perfekt integritet över alla kontrollerade strukturer.

4.1.2 Upptäckta korruptionsfel

Närhelst DBCC CHECKDB upptäcker ett korruptionsfel rapporterar den ett felmeddelande med följande struktur:
Guide för allvarlighetsgrad:

• Nivå 16-19: Användarkorrigerbara fel, ofta mindre korruptioner
• Nivå 20-24: Systemfel, allvarliga korruptioner som kräver omedelbar uppmärksamhet
• Nivå 25: Allvarliga fel, databasen kan vara oåtkomlig

Vanliga fel inkluderar:

• Fel på sidans kontrollsumma (meddelande 824)
• Allokeringsfel (meddelande 8928)
• Problem med indexkonsistens (meddelande 8964)

Att förstå meddelandestrukturen hjälper till att prioritera responsåtgärder och bestämma lämpliga återställningsstrategier.

4.1.3 Vanliga informations- och varningsmeddelanden

Inte all DBCC CHECKDB-utdata indikerar allvarliga problem. Den kan också visa informations- och varningsmeddelanden, inklusive:

• Reparationsutlåtanden – Meddelanden som föreslår reparationskommandon för att åtgärda mindre problem
• Tilldelningsvarningar – Varningar om utrymmesallokering som inte påverkar dataåtkomst
• Prestandarekommendationer – Förslag på indexunderhåll och optimering
• Informationsmeddelanden – Allmänna statusmeddelanden som inte kräver omedelbar åtgärd

Dessa meddelanden ger värdefull vägledning om underhåll samtidigt som de skiljer mellan kritiska problem som kräver omedelbara åtgärder och mindre problem som kan åtgärdas under regelbundna underhållsfönster.

Exempel på varningsmeddelande:

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-körning avbryts

Om CHECKDB avbryts under körningen av olika anledningar, rapporterar den ett felmeddelande och lägger till en fellogg med tillståndskoden nedan:

Ange	BESKRIVNING
0	Felnummer 8930 uppstod. Detta indikerar en skada i metadata som avslutade DBCC-kommandot.
1	Felnummer 8967 uppstod. Ett internt DBCC-fel uppstod.
2	Ett fel uppstod under databasreparation i nödläge.
3	Detta indikerar en skada i metadata som avslutade DBCC-kommandot.
4	Ett intrång i systemet eller ett åtkomstfel upptäcktes.
5	Ett okänt fel inträffade som avslutade DBCC-kommandot.

Exempel på felmeddelande:

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

Exempel på fellogg:

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ådant fall kan du prova alternativa avancerade alternativ som t.ex. DataNumen SQL Recovery för att åtgärda skadan i din databas.

5. Åtgärda korruptionsfel

5.1 Säkerhetskopiering och återställning: Den säkraste lösningen

När DBCC CHECKDB identifierar korruptionsfel är återställning från ren säkerhetskopia det säkraste och mest effektiva alternativet.ost pålitlig lösning. Denna metod garanterar dataintegritet samtidigt som den eliminerar underliggande orsaker till korruption. Innan du återställer, verifiera säkerhetskopians integritet med hjälp av ÅTERSTÄLL ENDAST VERIFIERING kommandon och överväg alternativ för återställning vid tidpunkten för att minimera dataförlust. Dokumentera detaljerna om korruptionen för rotorsaksanalys, eftersom hårdvaruproblem eller programvarufel kan kräva ytterligare uppmärksamhet för att förhindra återfall.

5.2 Lösningar mot korruption på sidnivå

För isolerade sidkorruptioner som påverkar små datadelar, SQL Server Enterprise Edition erbjuder funktioner för återställning av sidor som reparerar specifika skadade sidor utan fullständig databasåterställning. Denna avancerade teknik kräver en fullständig återställningsmodell och aktuella loggbackuper.

Steg-för-steg-process för återställning av sidan:

1. Identifiera den skadade sidan från CHECKDB-felmeddelandet (t.ex. sida 1:256)
2. Ta en säkerhetskopia av den aktuella loggen för att registrera de senaste transaktionerna:

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

3. Återställ den skadade sidan från most senaste fullständiga säkerhetskopian:

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

4. Tillämpa differentiell backup (om tillgänglig):

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

5. Tillämpa alla loggsäkerhetskopior i sekvens, inklusive den som just skapades:

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 slutlig säkerhetskopia och återställ loggfilen för att uppdatera sidan:

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

Alternativ för icke-kritiska data: Om korruption påverkar icke-kritiska data kan du exportera opåverkade rader till nya tabeller innan du återskapar korrupta 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 Snabba lösningar på indexkorruption

Indexkorruption svarar ofta bra på ombyggnadsåtgärder som återskapar indexstrukturer utan att påverka underliggande tabelldata:

ALTER INDEX ALL ON YourTable REBUILD

Den här metoden fungerar särskilt bra för icke-klustrade indexkorruptioner, eftersom ombyggnaden återskapar indexsidor från källtabelldata, vilket effektivt eliminerar korruption samtidigt som all originalinformation bevaras.

6. Använd REPAIR_REBUILD och REPAIR_ALLOW_DATA_LOSS

Om de föregående metoderna misslyckas eller inte är genomförbara kan du använda alternativen REPAIR_REBUILD och REPAIR_ALLOW_DATA_LOSS för att reparera databasen.

6.1 REPAIR_REBUILD (Säkrare alternativ):

• Använda för: Indexkorruption och mindre allokeringsfel
• Datasäkerhet: Försöker åtgärda korruption utan att radera data
• Risknivå: Låg – ingen dataförlust förväntas
• Typiska scenarier: Icke-klustrade indexkorruptioner, mindre metadataproblem
• Kommandoexempel: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Sista utvägen):

• Använda för: Allvarlig korruption när säkerhetskopior inte är tillgängliga
• Datasäkerhet: Kan ta bort skadad data för att återställa databasens funktionalitet
• Risknivå: Hög – permanent dataförlust möjlig
• Typiska scenarier: Sidkorruption, systemtabellskada, allokeringskedjefel
• Kommandoexempel: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Bästa praxis för dessa alternativ:

• Test alltid reparationsåtgärder på databaskopior när det är möjligt
• Säkerhetskopiera alltid innan du kör dessa alternativ
• Dokumentera alla ändringar för efterlevnad och felsökning
• Ställ in databasen på enanvändarläge innan reparationsarbeten påbörjas

Normalt sett borde vi försöka REPARERA_ÅTERBYGG alternativ först. Om det misslyckas, försök REPAIR_ALLOW_DATA_LOSS alternativ.

6.4 REPAIR_ALLOW_DATA_LOSS-resultat

6.4.1 Reparationen lyckas även med dataförlust

Ibland är det REPAIR_ALLOW_DATA_LOSS alternativet kommer att lyckas, men en del data är obefintligaost efter reparationen.

Nedan följer några exempelmeddelanden:

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.

Detta beror på att DBCC CHECKDB fixar databasen genom att överge vissa skadade poster, men i själva verket, most av dem kan fortfarande återställas via DataNumen SQL Recovery.

Exempelfiler:

SQL Server version	Skadad MDF-fil	MDF-fil fixad av DataNumen SQL Recovery
SQL Server 2014	Fel10_1.mdf (Meddelande 8909 följt av Meddelande 8939) (600 poster lost med REPAIR_ALLOW_DATA_LOSS)	Fel10_1_fixed.mdf (Ingen post lost)
SQL Server 2014	Fel10_2.mdf (Meddelande 8909 följt av meddelande 8939) (6000 poster (50%) lost med REPAIR_ALLOW_DATA_LOSS)	Fel10_2_fixed.mdf (Endast 100 poster lost)
SQL Server 2014	Error7.mdf (100 poster lost med REPAIR_ALLOW_DATA_LOSS)	Fel7_fixed.mdf (Endast en post lost)

6.4.2 Reparationsmisslyckanden – Överväg professionell lösning

If REPAIR_ALLOW_DATA_LOSS misslyckas, kommer den att ge ut ett eller flera felmeddelanden.

Nedan följer några exempel:

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 dessa scenarier behöver du använda en professionell lösning som t.ex. DataNumen SQL Recovery för att fixa din databas.

Exempelfiler

SQL Server version	Skadad MDF-fil	MDF-fil fixad av DataNumen SQL Recovery
SQL Server 2014	Fel1_3.mdf (Enkelt meddelande 824)	Fel1_3_fixed.mdf
SQL Server 2014	Fel1_1.mdf (Kontinuerliga meddelande 824-fel)	Fel1_1_fixed.mdf
SQL Server 2014	Fel1_2.mdf ((Meddelande 824 följt av meddelande 7909)	Fel1_2_fixed.mdf
SQL Server 2014	Fel4_1.mdf (Meddelande 8992 följt av meddelande 3852)	Fel4_1_fixed.mdf
SQL Server 2014	Fel4_2.mdf (Meddelande 8992 följt av meddelande 3852)	Fel4_2_fixed.mdf
SQL Server 2014	Fel5.mdf (Meddelande 8945)	Fel5_fixed.mdf
SQL Server 2014	Fel6.mdf (Meddelande 2510)	Fel6_fixed.mdf
SQL Server 2014	Fel2.mdf (Meddelande 2575)	Fel2_fixed.mdf
SQL Server 2014	Fel11.mdf (Meddelande 8905)	Fel11_fixed.mdf
SQL Server 2014	Fel3.mdf (Meddelande 5028)	Fel3_fixed.mdf
SQL Server 2014	Error8.mdf (Meddelande 5125)	Error8_fixed.mdf
SQL Server 2014	Fel9.mdf (Meddelande 3313)	Fel9_fixed.mdf

7. Bästa metoder

7.1 Schemalägga regelbundna CHECKDB-operationer

Implementera veckovis DBCC CHECKDB-körning för kritiska produktionsdatabaser, med dagliga kontroller för system med hög transaktionsfrekvens. Schemalägg operationer under perioder med låg användning för att minimera prestandapåverkan och överväg att växla mellan fullständiga kontroller och alternativ för PHYSICAL_ONLY baserat på databasens storlek och underhållsfönster. Automatiserad schemaläggning genom SQL Server Agenten säkerställer konsekvent körning samtidigt som den tillhandahåller centraliserade övervaknings- och varningsfunktioner.

7.2 Hantering av prestandapåverkan

DBCC CHECKDB-åtgärder förbrukar betydande systemresurser, vilket potentiellt påverkar samtidig användaraktivitet. Övervaka CPU-användning, minnesförbrukning och disk-I/O under kontroller för att förstå prestandapåverkansmönster. Överväg att använda NOINDEX-alternativ för rutinkontroller och reservera fullständig validering för månatliga underhållsfönster. Implementera timeout-tillägg för frågor och strategier för användarkommunikation för att hantera förväntningar under integritetskontrollperioder.

7.3 Planering av underhållsfönster

Koordinera DBCC CHECKDB-schemaläggningen med andra underhållsaktiviteter som säkerhetskopiering, indexåteruppbyggnad och statistikuppdateringar. Undvik överlappande resurskrävande operationer som kan orsaka prestandaförsämring eller timeout-problem. Planera underhållsfönster baserat på prognoser för databasens storlekstillväxt och säkerställ tillräcklig tid för fullständig integritetsverifiering allt eftersom datavolymerna ökar.

7.4 Automatiserad övervakning och varningar

Inställd SQL Server Agentaviseringar för att omedelbart meddela administratörer när DBCC CHECKDB identifierar korruption. Implementera loggparsningslösningar som extraherar och kategoriserar resultat av integritetskontroller, vilket möjliggör trendanalys och proaktiv problemidentifiering. Skapa eskaleringsprocedurer som definierar tidsramar för svar och ansvarig personal för olika allvarlighetsgrader av korruption.

8. DBCC CHECKTABLE: Det lättare alternativet

8.1 När ska CHECKTABLE användas istället för CHECKDB

DBCC CHECKTABLE erbjuder fokuserad integritetskontroll för enskilda tabeller, vilket gör den idealisk för tarfelsökning och underhåll av specifika databasobjekt. Använd CHECKTABLE när du undersöker prestandaproblem med specifika tabeller, validerar kritiska affärstabeller mellan fullständiga databaskontroller eller när tidsbegränsningar förhindrar fullständig databasvalidering. Denna metod visar sig vara särskilt värdefull i stora databaser där fullständiga CHECKDB-operationer överskrider tillgängliga underhållsfönster.

8.2 DBCC CHECKTABLE-syntax och exempel

Det grundläggande CHECKTABLE-kommandot tarhämtar specifika tabeller:

DBCC CHECKTABLE('YourTable')

Precis som CHECKDB stöder CHECKTABLE olika alternativ, inklusive NOINDEX för prestandaoptimering och reparationsparametrar för att åtgärda korruption. Du kan också ange schemanamn för exakt tabellidentifiering:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Detta targeted-metoden möjliggör detaljerad integritetsverifiering samtidigt som systemets prestanda bibehålls under kontorstid.

8.3 Prestandafördelar för stora databaser

CHECKTABLE-operationer slutförs betydligt snabbare än fullständiga databaskontroller, vilket möjliggör mer frekvent integritetsverifiering av kritiska tabeller. Denna metod möjliggör daglig validering av viktiga affärstabeller samtidigt som omfattande CHECKDB-operationer reserveras för veckovisa eller månatliga scheman. Den minskade resursförbrukningen gör CHECKTABLE lämplig för körning i produktionsmiljöer med minimal användarpåverkan.

9. När CHECKDB misslyckas

DBCC CHECKDB kommer att misslyckas i olika scenarier, inklusive:

• DBCC CHECKDB-körning avslutas onormalt
• DBCC CHECKDB-körningen slutfördes utan problem, men reparationsalternativ misslyckas med att reparera databasen.

I dessa scenarier behöver vi ett mer professionellt verktyg som hjälper oss att åtgärda felen i databasen.

9.1 Introduktion till DataNumen SQL Recovery

DataNumen SQL Recovery erbjuder mer avancerade funktioner:

• Bästa återvinningsgrad inom industrin.
• Återställ allvarligt skadade databasfiler.
• Återställ alla databasobjekt, inklusive tabeller, index, vyer, utlösare, regler och standardvärden.
• Återställ lagrade procedurer, skalära funktioner, inline-tabellvärdade funktioner och flerstatstabellvärderade funktioner.
• Återställ permanent raderade poster.
• Dekryptera krypterade objekt i SQL Server databaser.
• Reparera MDF-filer i batch.
• Omfattande reparationsalternativ.
• Avancerad loggning och rapportering.
• Stöd för alla SQL Server versioner.
• Tillgänglighet för teknisk support
• Regelbundna uppdateringar och förbättringar

9.2 Jämförelse av framgångsfrekvens

Framgångsfrekvensen för återhämtning skiljer sig markant:

• DBCC CHECKDB & CHECKTABELL: 1.27% genomsnittlig återvinningsgrad
• DataNumen: 92.6% återhämtningsfart

Nedan är en komplett konkurrensjämförelse:

9.3 Återhämtning från allvarlig korruption

Avancerade funktioner för svåra fall:

• Återställning från fysiskt skadad lagring
• Återställning från formaterade enheter eller kraschade system
• Återställ från diskbilder, säkerhetskopieringsfiler, virtuella maskindiskfiler, temporary filer osv.

9.4 När man bör överväga professionella lösningar

• Ingen tillgänglighet för nyligen genomförda säkerhetskopior
• DBCC CHECKDB misslyckas
• Allvarliga korruptionsscenarier
• Hantera kritisk affärsdata
• När tiden är kritisk
• När maximal återhämtning är nödvändig

10. Vanliga frågor

11. Slutsats

11.1 Sammanfattning av nyckelpunkter

11.1.1 Sammanfattning av viktiga DBCC CHECKDB-kommandon

Behärska den grundläggande DBCC CHECKDB-syntaxen för omfattande databaskontroll, använd NOINDEX- och PHYSICAL_ONLY-alternativen för prestandaoptimering och förstå CHECKTABLE för tarverifiering av geted-tabellen. Dessa grundläggande kommandon utgör grunden för proaktivt databasunderhåll, vilket möjliggör tidig upptäckt av korruption och systematisk integritetsövervakning.

11.1.2 Påminnelse om viktiga bästa praxis

Ha alltid aktuella säkerhetskopior innan du kör integritetskontroller, schemalägg regelbundna CHECKDB-operationer baserat på databasens kritiska karaktär och implementera automatiserad övervakning för omedelbara korruptionsvarningar. Kom ihåg att förebyggande åtgärder genom regelbunden övervakning överträffar reaktiva metoder, och professionella återställningslösningar ger värdefulla säkerhetskopieringsalternativ när standardverktyg visar sig otillräckliga.

11.2 När ska man använda DBCC CHECKDB kontra avancerade lösningar

Använd DBCC CHECKDB för rutinmässig integritetsövervakning och mindre korruptionsåtgärder, samtidigt som professionella återställningsverktyg reserveras för allvarliga korruptionsscenarier utöver inbyggda reparationsmöjligheter. Beslutsramverket bör beakta tillgänglighet av säkerhetskopior, datakritikalitet, tidsbegränsningar och korruptionens allvarlighetsgrad. Framgångsrika databasadministratörer kombinerar regelbunden CHECKDB-övervakning med omfattande säkerhetskopieringsstrategier och medvetenhet om avancerade återställningsalternativ när standardmetoder visar sig otillräckliga.

11.3 Snabb daglig hälsochecklista för databaserade administratörer

Utöver att köra DBCC CHECKDB, bibehåll optimal databashälsa med dessa viktiga dagliga rutiner:

1. Verifiera säkerhetskopians integritet

• Bekräfta att schemalagda säkerhetskopior har slutförts
• Använd RESTORE VERIFYONLY för att verifiera läsbarheten av säkerhetskopian
• Se till att externa kopior är synkroniserade och tillgängliga

Du kan också få mer information från vår omfattande guide om SQL Server säkerhetskopiering.

2. Granska konsekvensstatus

• Kontrollera automatiserade DBCC CHECKDB-resultat från körningar över natten
• Övervaka SQL Server felloggar för korruptionsvarningar
• Undersök eventuella integritetsbrister omedelbart

3. Övervaka serverns hälsa

• Kontrollera CPU, minne och disk-I/O-värden
• Verifiera tillgängligt tempdb-utrymme
• Identifiera blockerade processer och långvariga frågor

4. Spåra dödlägesaktivitet

• Granska dödlägesdiagram från systemhälsohändelser
• Identifiera problematiska frågor och optimera med utvecklingsteam
• Övervaka antalet offer för dödlägen och deras påverkan på verksamheten

Viktiga påminnelser

• Undvik frekvent databaskrympning – det ökar fragmenteringen och försämrar prestandan. Krymp bara efter större databorttagningar när det verkligen är nödvändigt.
• Automatisera övervakningsuppgifter med hjälp av SQL Server Agentjobb eller underhållsplaner med aviseringar om kritiska problem.
• Testa katastrofåterställningsprocedurer varje vecka för att säkerställa att säkerhetskopior kan återställas och att återställningsmålen förblir uppnåeliga.

Genom att kombinera denna dagliga checklista med regelbundna DBCC CHECKDB-åtgärder skapar du ett omfattande skydd för din databasmiljö genom proaktiv övervakning och snabb problemhantering.

12. Referenser

1. 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
2. Microsoft Learn. ”Felsök databaskonsistensfel som rapporterats av DBCC CHECKDB.” SQL Server DokumentationMicrosoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors