DBCC CHECKDB: Pilnīgs MS ceļvedis SQL Server Datu bāzes veselība (2025)

Datu bāzes korupcija ir ikviena SQL Server administratora murgs. Kad kritiski svarīgi biznesa dati kļūst nepieejami vai neuzticami, cost var būt postošas. Šajā visaptverošajā rokasgrāmatā ir apkopots viss, kas jums jāzina par DBCC CHECKDB izmantošanu, lai uzturētu datubāzes veselību un novērstu bojājumus, kā arī sniegti uzlaboti atkopšanas risinājumi gadījumiem, kad standarta rīki nav pietiekami.

1. Svarīgums SQL Server Datu bāzes veselība

1.1 Kas ir datubāzes bojājums C?ostUzņēmumi

Šodien, most Uzņēmumi glabā savus kritiski svarīgos datus datubāzēs. Datubāzu bojājuma sekas ir katastrofālas:

• Finansiālie zaudējumi vidēji 2.3 miljoni ASV dolāru gadā datu zuduma dēļ, un galvenie cēloņi ir aparatūras kļūmes un korupcija (EMC Corporation)
• Uzņēmumu slēgšanas rādītāji liecina, ka 50 % mazo uzņēmumu, kas piedzīvo datu zudumu aparatūras kļūmju dēļ, pārtrauc darbību divu gadu laikā, savukārt 94 % uzņēmumu, kas piedzīvo katastrofālus datu zudumus, vispār neizdzīvo.
• Datu korupcijas biežums katru gadu ietekmē 20 % no misijai kritiski svarīgām lietojumprogrammām, izraisot uzņēmējdarbības nepārtrauktības traucējumus (Gartner pētījums)
• Ar aparatūru saistīta korupcija veido 67% no visiem datu zuduma gadījumiem cieto disku avāriju un sistēmas kļūmju dēļ, un 40% datu zudumu ir tieši saistīti ar aparatūras darbības traucējumiem.
• Programmatūras korupcija costs svārstās no tūkstošiem līdz miljoniem dolāru atkarībā no nopietnības un apjoma, un 82 % uzņēmumu piedzīvoja neplānotus elektroenerģijas padeves pārtraukumus, kuros korupcija bija galvenais cēlonis.

1.2 Kāpēc regulāras veselības pārbaudes ir kritiski svarīgas

Cilvēkiem ir nepieciešamas regulāras veselības pārbaudes, lai laikus atklātu iespējamās slimības. Līdzīgi arī datubāzēm ir nepieciešamas regulāras veselības pārbaudes:

1. Savlaicīgi atklāt potenciālu korupciju un nekavējoties to risināt, novēršot problēmu nopietnību un izplatīšanos, kas varētu radīt katastrofālas sekas uzņēmumam.
2. Nodrošiniet, lai datubāze darbotos ar optimālu veiktspēju.
3. Cost Proaktīvu datubāzes veselības pārbaužu apjoms ir daudz zemāks nekā reaktīvās datu atkopšanas apjoms pēc datubāzes katastrofas.

1.3 Ievads datubāzes integritātes komandās

SQL Server nodrošina vairākas iebūvētas komandas datubāzes veselības uzturēšanai, ar DBCC PĀRBAUDE kalpo kā most pieejams visaptverošs integritātes pārbaudes rīks. Šīs komandas darbojas kopā, lai pārbaudītu dažādus jūsu datubāzes struktūras aspektus, sākot no atsevišķām tabulām līdz visas datubāzes konsekvencei, veidojot pilnīgu uzturēšanas stratēģiju, kas nodrošina jūsu datu drošību un pieejamību.

2. Kas ir DBCC CHECKDB?

DBCC PĀRBAUDE is SQL Servergalvenais rīks datubāzes integritātes pārbaudei un korupcijas problēmu identificēšanai.

• Tas ir T-SQL paziņojums, nevis GUI rīks.
• To var izpildīt, izmantojot parastas metodes, piemēram, SQL Server Vadības studija (SSMS), SQL Server Aģents, SQLCMD utt.

2.1 Ko CHECKDB faktiski pārbauda jūsu datubāzē

Palaižot DBCC CHECKDB, komanda veic vairākus validācijas slāņus visā jūsu datubāzes struktūrā:

• Lapas kontrolsummu pārbaude lai atklātu fizisku bojājumu un ar aparatūru saistītas problēmas
• Indeksa konsekvences validācija lai nodrošinātu pareizu datu izgūšanu un vaicājumu veiktspēju
• Sadalījuma struktūras pārbaudes lai apstiprinātu precīzu vietas izmantošanu un lappušu piešķiršanu
• Atsauces integritātes pārbaude starp saistītām tabulām un ārējās atslēgas attiecībām
• Sistēmas tabulas konsekvences validācija lai nodrošinātu SQL Serveriekšējie metadati joprojām ir uzticami
• Datu lapu saistīšanas pārbaude lai apstiprinātu pareizu lapas ķēdes integritāti
• Datu bāzes shēmas konsekvence lai validētu objektu definīcijas un atkarības

Šīs visaptverošās pārbaudes aptver gan lietotāju datus, gan sistēmas struktūras, nodrošinot pilnīgu pārskatu par jūsu datubāzes veselības stāvokli.

3. DBCC CHECKDB palaišana: soli pa solim

3.1 priekšnoteikumi

Zemāk ir kontrolsaraksts pirms jebkuras DBCC CHECKDB operācijas izpildes:

• Pilnīga datubāzes dublēšana – Pirms integritātes pārbaužu veikšanas izveidojiet pilnu dublējumu kā drošības tīklu, ja tiek atklāti bojājumi vai nepieciešamas remonta darbības.
• Pareizas atļaujas – Lai izpildītu DBCC CHECKDB komandas, nepieciešamas sistēmas administratora vai db_owner atļaujas.
• Pietiekami sistēmas resursi:
  • Atmiņa: 25% no datubāzes lieluma
  • Tempdb vieta: 10–15 % no datubāzes lieluma
  • CPU: 50–70 % pieejamība apkopes laikā
  • I/O: Sagaidāmas apjomīgas lasīšanas operācijas
• Datubāzes pieejamība – Pārliecinieties, vai jūsu datubāze ir pieejama un nav ierobežotā stāvoklī, jo CHECKDB ir nepieciešama lasīšanas piekļuve visām datubāzes lapām.

3.2. Pamata komanda

Most DBCC CHECKDB pamata komanda ietver trīs izplatītas variācijas:

(1) Pārbaudiet pašreizējo datubāzi (bez parametriem):

DBCC CHECKDB

(2) Pārbaudiet datubāzi pēc nosaukuma:

DBCC CHECKDB ('YourDatabaseName')

(3) Pārbaudiet datubāzi pēc ID:

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

Šī pamata komanda veic pilnīgu norādītās datubāzes integritātes pārbaudi, pārbaudot visas tabulas, indeksus un sistēmas struktūras. Datubāzēm ar standarta nosaukumiem, kas nesatur atstarpes, pēdiņas var izlaist. Komanda darbosies līdz pabeigšanai, parādot progresa ziņojumus un gala rezultātus. Šī pamata sintakse lieliski darbojas mazākām datubāzēm vai tad, ja ir pieejams pietiekami daudz laika apkopei.

Zemāk ir redzams ekrānuzņēmums, kurā redzama DBCC CHECKDB palaišana SQL Server Vadības studija (SSMS):

3.3 Pilnīgas opcijas

Tālāk ir norādītas visas DBCC CHECKDB opcijas:

Kategorija	izvēle	Apraksts	DBCC CHECKDB piemērs
Remonta iespējas	REPAIR_REBUILD	Remonts bez datu zuduma (piemēram, indeksu atjaunošana)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Nav remonta. Tikai atpakaļsaderība.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Novērš visas kļūdas (var izraisīt datu zudumu)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Darbības jomas kontrole	NOINDEX	Izlaiž neklasterizētu indeksu pārbaudes	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Pārbauda tikai fiziskās krātuves integritāti (lapas/ieraksti)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Pārbauda loģisko kolonnu vērtību kļūdas (piemēram, nederīgus datumus)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Dziļas loģiskās pārbaudes (indeksēti skati, XML/telpiskie indeksi)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Izvades kontrole	ALL_ERRORMSGS	Parāda visas kļūdas (pēc noklusējuma: 200 katram objektam)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Slēpj informatīvus ziņojumus	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Veiktspēja	TABLOCK	Izmanto tabulu bloķēšanu (samazina TempDB izmantošanu, bet bloķē rakstīšanu)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Pārraksta paralēlisma iestatījumus	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Lietderība	ESTIMATEONLY	Aprēķina nepieciešamo TempDB vietu. (faktiska pārbaude nav nepieciešama)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Rezultātu izpratne

DBCC CHECKDB sniegs atšķirīgus rezultātus atkarībā no tā, vai tā izpilde ir veiksmīgi pabeigta. Izskaidrosim tos sīkāk.

4.1 CHECKDB izpilde veiksmīgi pabeigta

Ja DBCC CHECKDB izpilde ir veiksmīgi pabeigta, tā ziņos par dažāda veida rezultātiem atkarībā no jūsu datubāzes veselības stāvokļa.

4.1.1 Nav atrastas problēmas

Ja DBCC CHECKDB neatrod nekādas problēmas, redzēsiet līdzīgu rezultātu:

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

Šis rezultāts norāda, ka jūsu datubāze saglabā nevainojamu integritāti visās pārbaudītajās struktūrās.

4.1.2 Atrastās korupcijas kļūdas

Ikreiz, kad DBCC CHECKDB atrod bojājuma kļūdu, tā ziņos kļūdas ziņojumu ar šādu struktūru:
Smaguma līmeņa ceļvedis:

• Līmenis 16–19: Lietotāja labojamas kļūdas, bieži vien nelielas korupcijas
• Līmenis 20–24: Sistēmas kļūdas, nopietni bojājumi, kam nepieciešama tūlītēja uzmanība
• 25. līmenis: Fatālas kļūdas, datubāze var nebūt pieejama

Biežākās kļūdas ir:

• Lapas kontrolsummas kļūmes (824. ziņojums)
• Piešķiršanas kļūdas (8928. ziņojums)
• Indeksa konsekvences problēmas (ziņojums 8964)

Ziņojuma struktūras izpratne palīdz noteikt prioritātes reaģēšanas darbībām un noteikt atbilstošas ​​atkopšanas stratēģijas.

4.1.3 Biežāk sastopamie informatīvie un brīdinājuma ziņojumi

Ne visa DBCC CHECKDB izvade norāda uz nopietnām problēmām. Tā var izvadīt arī dažus informatīvus un brīdinājuma ziņojumus, tostarp:

• Remonta paziņojumi – Ziņojumi, kas iesaka remonta komandas nelielu problēmu novēršanai
• Piešķiršanas brīdinājumi – Brīdinājumi par vietas piešķiršanu, kas neietekmē piekļuvi datiem
• Veiktspējas ieteikumi – Ieteikumi indeksa uzturēšanai un optimizācijai
• Informatīvi paziņojumi – Vispārīgi statusa ziņojumi, kuriem nav nepieciešama tūlītēja rīcība

Šie ziņojumi sniedz vērtīgus norādījumus par apkopi, vienlaikus nošķirot kritiskus bojājumus, kam nepieciešama tūlītēja rīcība, no nelielām problēmām, kuras var risināt regulāro apkopes periodu laikā.

Brīdinājuma ziņojuma piemērs:

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 izpildes pārtraukšana

Ja CHECKDB izpildes laikā dažādu iemeslu dēļ tiek pārtraukta darbība, tā ziņos par kļūdas ziņojumu un pievienos kļūdu žurnālu ar tālāk norādīto stāvokļa kodu:

Valsts	Apraksts
0	Radās kļūda ar numuru 8930. Tas norāda uz metadatu bojājumu, kas pārtrauca DBCC komandas darbību.
1	Radās kļūda ar numuru 8967. Radās iekšēja DBCC kļūda.
2	Avārijas režīma datubāzes labošanas laikā radās kļūme.
3	Tas norāda uz metadatu bojājumu, kas pārtrauca DBCC komandas darbību.
4	Tika konstatēts apgalvojums vai piekļuves pārkāpums.
5	Radās nezināma kļūda, kas pārtrauca DBCC komandas izpildi.

Kļūdas ziņojuma piemērs:

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

Kļūdu žurnāla piemērs:

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.

Šādā gadījumā varat izmēģināt alternatīvas papildu iespējas, piemēram, DataNumen SQL Recovery lai novērstu korupciju jūsu datubāzē.

5. Korupcijas kļūdu labošana

5.1 Dublēšana un atjaunošana: drošākais risinājums

Kad DBCC CHECKDB identificē korupcijas kļūdas, atjaunošana no tīras dublējuma ir drošākais un pieejamākais veids, kā to atjaunot.ost uzticams risinājums. Šī pieeja garantē datu integritāti, vienlaikus novēršot pamatā esošos korupcijas cēloņus. Pirms atjaunošanas pārbaudiet dublējuma integritāti, izmantojot ATJAUNOT TIKAI PĀRBAUDĪT komandas un apsveriet konkrēta laika punkta atkopšanas iespējas, lai samazinātu datu zudumu. Dokumentējiet bojājuma informāciju pamatcēloņa analīzei, jo aparatūras problēmām vai programmatūras kļūdām var būt nepieciešama papildu uzmanība, lai novērstu atkārtošanos.

5.2 Lapas līmeņa bojājumu risinājumi

Atsevišķu lapu bojājumu gadījumā, kas ietekmē nelielas datu daļas, SQL Server Enterprise Edition piedāvā lapu atjaunošanas iespējas, kas labo konkrētas bojātas lapas bez pilnīgas datubāzes atjaunošanas. Šī uzlabotā metode prasa pilnīgu atkopšanas modeli un aktuālas žurnālu dublējumkopijas.

Soli pa solim lapas atjaunošanas process:

1. Identificējiet bojāto lapu no CHECKDB kļūdas ziņojuma (piemēram, 1. lappuse: 256)
2. Veikt pašreizējā žurnāla dublējumu lai fiksētu nesenos darījumus:

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

3. Atjaunojiet bojāto lapu no most nesena pilna dublēšana:

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

4. Lietot diferenciālo dublēšanu (ja ir pieejama):

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

5. Lietot visas žurnālu dublējumkopijas secīgi, ieskaitot tikko izveidoto:

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. Izveidojiet pēdējo žurnāla dublējumu un atjaunojiet to Lai atjauninātu lapu:

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

Alternatīva nekritiskiem datiem: Ja bojājums ietekmē nekritiskus datus, pirms bojāto struktūru atjaunošanas varat eksportēt neietekmētās rindas uz jaunām tabulām:

-- 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 Indeksa bojājumu ātrie labojumi

Indeksa bojājumi bieži vien labi reaģē uz atjaunošanas darbībām, kas atjauno indeksa struktūras, neietekmējot pamatā esošos tabulas datus:

ALTER INDEX ALL ON YourTable REBUILD

Šī pieeja īpaši labi darbojas neklasterizētu indeksu bojājumu gadījumā, jo atjaunošanas laikā indeksu lapas tiek atjaunotas no avota tabulas datiem, efektīvi novēršot bojājumus, vienlaikus saglabājot visu sākotnējo informāciju.

6. Izmantojiet REPAIR_REBUILD un REPAIR_ALLOW_DATA_LOSS

Ja visas iepriekšējās metodes neizdodas vai nav iespējamas, varat izmantot opcijas REPAIR_REBUILD un REPAIR_ALLOW_DATA_LOSS, lai labotu datubāzi.

6.1 REPAIR_REBUILD (Drošāka opcija):

• Izmantot priekš: Indeksa bojājumi un nelielas piešķiršanas kļūdas
• Datu drošība: Mēģinājumi novērst korupciju bez datu dzēšanas
• Riska līmenis: Zems — datu zudums nav gaidāms
• Tipiski scenāriji: Neklasterizēta indeksa bojājums, nelielas metadatu problēmas
• Komandas piemērs: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Pēdējā iespēja):

• Izmantot priekš: Nopietna korupcija, ja dublējumkopijas nav pieejamas
• Datu drošība: Var dzēst bojātus datus, lai atjaunotu datubāzes funkcionalitāti
• Riska līmenis: Augsts — iespējams neatgriezenisks datu zudums
• Tipiski scenāriji: Lapas bojājumi, sistēmas tabulas bojājumi, piešķiršanas ķēdes kļūdas
• Komandas piemērs: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Best Practices for These Options:

• Vienmēr pārbaudiet ja iespējams, labot datubāzes kopijas
• Vienmēr veidojiet rezerves kopiju pirms šo opciju palaišanas
• Dokumentējiet visas izmaiņas atbilstības un problēmu novēršanas nolūkos
• Iestatīt datubāzi viena lietotāja režīmā pirms remonta darbu veikšanas

Normally, we should try REPAIR_REBUILD option first. If it fails, then try REPAIR_ALLOW_DATA_LOSS variants.

6.4 REPAIR_ALLOW_DATA_LOSS rezultāti

6.4.1 Remonts veiksmīgs, bet dati zaudēti

Dažreiz REPAIR_ALLOW_DATA_LOSS opcija būs veiksmīga, taču daži dati ir tost pēc remonta.

Below are some sample messages:

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.

This is because DBCC CHECKDB fixes the database by abandoning some damaged records, but actually, most of them can still be recovered via DataNumen SQL Recovery.

Sample files:

SQL Server versija	Bojāts MDF fails	MDF failu laboja DataNumen SQL Recovery
SQL Server 2014	Kļūda10_1.mdf (Msg 8909 followed by Msg 8939) (600 records lost ar REPAIR_ALLOW_DATA_LOSS)	Kļūda10_1_fiksēts.mdf (No record lost)
SQL Server 2014	Kļūda10_2.mdf (Msg 8909 followed by Msg 8939) (6000 records(50%) lost ar REPAIR_ALLOW_DATA_LOSS)	Kļūda10_2_fiksēts.mdf (Only 100 records lost)
SQL Server 2014	Error7.mdf (100 ieraksti lost ar REPAIR_ALLOW_DATA_LOSS)	Kļūda7_fixed.mdf (Tikai viens ieraksts lost)

6.4.2 Remonta kļūmes — apsveriet profesionāla risinājuma izmantošanu

If REPAIR_ALLOW_DATA_LOSS fails, it will output one or multiple error messages.

Tālāk ir sniegti daži piemēri.

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.

Šādos gadījumos jums jāizmanto profesionāls risinājums, piemēram, DataNumen SQL Recovery lai labotu savu datubāzi.

Parauga faili

SQL Server versija	Bojāts MDF fails	MDF failu laboja DataNumen SQL Recovery
SQL Server 2014	Kļūda1_3.mdf (Single Msg 824)	Kļūda1_3_fiksēts.mdf
SQL Server 2014	Kļūda1_1.mdf (Continuous Msg 824 errors)	Kļūda1_1_fiksēts.mdf
SQL Server 2014	Kļūda1_2.mdf ((Msg 824 followed by Msg 7909)	Kļūda1_2_fiksēts.mdf
SQL Server 2014	Kļūda4_1.mdf (Msg 8992 followed by Msg 3852)	Kļūda4_1_fiksēts.mdf
SQL Server 2014	Kļūda4_2.mdf (Msg 8992 followed by Msg 3852)	Kļūda4_2_fiksēts.mdf
SQL Server 2014	Kļūda5.mdf (Msg 8945)	Kļūda5_fixed.mdf
SQL Server 2014	Kļūda6.mdf (Msg 2510)	Kļūda6_fixed.mdf
SQL Server 2014	Kļūda2.mdf (Msg 2575)	Kļūda2_fixed.mdf
SQL Server 2014	Kļūda11.mdf (Msg 8905)	Kļūda11_fixed.mdf
SQL Server 2014	Kļūda3.mdf (Msg 5028)	Kļūda3_fixed.mdf
SQL Server 2014	Error8.mdf (Msg 5125)	Error8_fiksēts.mdf
SQL Server 2014	Kļūda9.mdf (Msg 3313)	Kļūda9_fixed.mdf

7. Labākā prakse

7.1 Regulāru CHECKDB darbību plānošana

Ieviesiet iknedēļas DBCC CHECKDB izpildi kritiski svarīgām ražošanas datubāzēm, veicot ikdienas pārbaudes sistēmām ar augstu transakciju skaitu. Ieplānojiet darbības zemas noslodzes periodos, lai samazinātu ietekmi uz veiktspēju, un apsveriet iespēju mainīt pilnas pārbaudes uz PHYSICAL_ONLY opcijām, pamatojoties uz datubāzes lielumu un apkopes periodiem. Automatizēta plānošana, izmantojot SQL Server Aģents nodrošina konsekventu izpildi, vienlaikus sniedzot centralizētas uzraudzības un brīdināšanas iespējas.

7.2 Veiktspējas ietekmes pārvaldība

DBCC CHECKDB operācijas patērē ievērojamus sistēmas resursus, potenciāli ietekmējot vienlaicīgu lietotāju aktivitāti. Pārbaužu laikā uzraugiet centrālā procesora noslodzi, atmiņas patēriņu un diska ievadizvadi, lai izprastu veiktspējas ietekmes modeļus. Apsveriet NOINDEX opciju izmantošanu regulārām pārbaudēm, rezervējot pilnīgu validāciju ikmēneša apkopes periodiem. Ieviesiet vaicājumu taimauta paplašinājumus un lietotāju saziņas stratēģijas, lai pārvaldītu cerības integritātes pārbaudes periodos.

7.3 Apkopes perioda plānošana

Koordinējiet DBCC CHECKDB plānošanu ar citām apkopes darbībām, piemēram, dublēšanas darbībām, indeksu atjaunošanu un statistikas atjauninājumiem. Izvairieties no resursu ietilpīgu darbību pārklāšanās, kas varētu izraisīt veiktspējas pasliktināšanos vai taimauta problēmas. Plānojiet apkopes periodus, pamatojoties uz datubāzes lieluma pieauguma prognozēm, nodrošinot pietiekamu laiku pilnīgai integritātes pārbaudei, palielinoties datu apjomam.

7.4 Automatizēta uzraudzība un brīdināšana

Konfigurēt SQL Server Aģenta brīdinājumi nekavējoties informē administratorus, ja DBCC CHECKDB konstatē korupciju. Ieviest žurnālu parsēšanas risinājumus, kas iegūst un kategorizē integritātes pārbaudes rezultātus, nodrošinot tendenču analīzi un proaktīvu problēmu identificēšanu. Izveidot eskalācijas procedūras, kas nosaka reaģēšanas laika grafikus un atbildīgo personālu dažādiem korupcijas smaguma līmeņiem.

8. DBCC CHECKTABLE: vieglā alternatīva

8.1 Kad CHECKTABLE lietot CHECKDB vietā

DBCC CHECKTABLE nodrošina mērķtiecīgu integritātes pārbaudi atsevišķām tabulām, padarot to ideāli piemērotu tarnodrošināta noteiktu datubāzes objektu problēmu novēršana un uzturēšana. Izmantojiet CHECKTABLE, izmeklējot veiktspējas problēmas ar konkrētām tabulām, validējot kritiskas biznesa tabulas starp pilnām datubāzes pārbaudēm vai ja laika ierobežojumi neļauj pilnībā validēt datubāzi. Šī pieeja ir īpaši vērtīga lielās datubāzēs, kur pilnas CHECKDB darbības pārsniedz pieejamos apkopes logus.

8.2 DBCC CHECKTABLE sintakse un piemēri

Pamata CHECKTABLE komanda tariegūst konkrētas tabulas:

DBCC CHECKTABLE('YourTable')

Tāpat kā CHECKDB, arī CHECKTABLE atbalsta dažādas opcijas, tostarp NOINDEX veiktspējas optimizācijai un labošanas parametrus bojājumu novēršanai. Varat arī norādīt shēmu nosaukumus precīzai tabulu identifikācijai:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

šis tarGeted pieeja ļauj veikt detalizētu integritātes pārbaudi, vienlaikus saglabājot sistēmas veiktspēju darba laikā.

8.3 Veiktspējas ieguvumi lielām datubāzēm

CHECKTABLE operācijas tiek pabeigtas ievērojami ātrāk nekā pilnas datubāzes pārbaudes, ļaujot biežāk pārbaudīt kritisko tabulu integritāti. Šī pieeja ļauj veikt svarīgu biznesa tabulu ikdienas validāciju, vienlaikus rezervējot visaptverošas CHECKDB operācijas nedēļas vai mēneša grafikiem. Samazinātais resursu patēriņš padara CHECKTABLE piemērotu izpildei ražošanas vidē ar minimālu ietekmi uz lietotāju.

9. Kad CHECKDB neizdodas

DBCC CHECKDB neizdosies dažādos scenārijos, tostarp:

• DBCC CHECKDB izpilde pārtraucas neparasti
• DBCC CHECKDB izpilde ir veiksmīgi pabeigta, bet remonta iespējas neizdodas labot datubāzi.

Šādos gadījumos mums ir nepieciešams profesionālāks rīks, kas palīdzētu novērst datubāzes bojājumus.

9.1 Ievads DataNumen SQL Recovery

DataNumen SQL Recovery nodrošina papildu iespējas:

• Labākais atgūšanas līmenis nozarē.
• Atgūt nopietni bojātus datubāzes failus.
• Atjaunot visus datubāzes objektus, tostarp tabulas, indeksus, skatus, trigerus, noteikumus un noklusējuma vērtības.
• Atkopt saglabātās procedūras, skalārās funkcijas, iekļautās tabulas vērtības funkcijas un vairāku paziņojumu tabulas vērtības funkcijas.
• Atgūt neatgriezeniski izdzēstos ierakstus.
• Atšifrēt šifrētus objektus SQL Server datubāzes.
• Remontējiet MDF failus partijās.
• Visaptverošas remonta iespējas.
• Uzlabota reģistrēšana un ziņošana.
• Atbalsts visiem SQL Server versijas.
• Tehniskā atbalsta pieejamība
• Regulāri atjauninājumi un uzlabojumi

9.2 Veiksmes rādītāju salīdzinājums

Atveseļošanās panākumu rādītāji ievērojami atšķiras:

• DBCC CHECKDB un CHECKTABLE: 1.27% vidējais atgūšanas ātrums
• DataNumen: 92.6% atgūšanas ātrums

Zemāk ir pilns konkurences salīdzinājums:

9.3. Atveseļošanās no smagas korupcijas

Uzlabotas iespējas smagos gadījumos:

• Atgūšana no fiziski bojātas krātuves
• Atkopšana no formatētiem diskdziņiem vai avarējušām sistēmām
• Atgūt no diska attēliem, dublējuma failiem, virtuālās mašīnas diska failiem, temparary faili utt.

9.4 Kad apsvērt profesionālus risinājumus

• Nav pieejamas nesenas rezerves kopijas
• DBCC CHECKDB neizdodas
• Smagi korupcijas scenāriji
• Kritisku biznesa datu apstrāde
• Kad laiks ir kritisks
• Kad maksimāla atveseļošanās ir būtiska

10. Bieži uzdotie jautājumi

11. secinājums

11.1. Galveno punktu kopsavilkums

11.1.1 Svarīgāko DBCC CHECKDB komandu kopsavilkums

Apgūt DBCC CHECKDB pamata sintaksi visaptverošai datubāzes pārbaudei, izmantot NOINDEX un PHYSICAL_ONLY opcijas veiktspējas optimizācijai un izprast CHECKTABLE tarIegūtās tabulas pārbaude. Šīs pamatkomandas veido proaktīvas datubāzes uzturēšanas pamatu, nodrošinot agrīnu bojājumu noteikšanu un sistemātisku integritātes uzraudzību.

11.1.2 Svarīgāko labākās prakses piemēru atgādinājums

Pirms integritātes pārbaužu veikšanas vienmēr uzturiet aktuālas dublējumkopijas, ieplānojiet regulāras CHECKDB darbības, pamatojoties uz datubāzes kritiskumu, un ieviesiet automatizētu uzraudzību, lai saņemtu tūlītējus brīdinājumus par bojājumiem. Atcerieties, ka profilakse, izmantojot regulāru uzraudzību, ir svarīgāka par reaģējošām pieejām, un profesionāli atkopšanas risinājumi nodrošina vērtīgas dublēšanas iespējas, ja standarta rīki izrādās nepietiekami.

11.2 Kad lietot DBCC CHECKDB salīdzinājumā ar uzlabotiem risinājumiem

Izmantojiet DBCC CHECKDB regulārai integritātes uzraudzībai un nelielu bojājumu novēršanai, vienlaikus rezervējot profesionālus atkopšanas rīkus nopietniem bojājumu scenārijiem, kas pārsniedz iebūvētās labošanas iespējas. Lēmumu pieņemšanas sistēmā jāņem vērā dublējumu pieejamība, datu kritiskums, laika ierobežojumi un bojājumu nopietnība. Veiksmīgi datubāzu administratori apvieno regulāru CHECKDB uzraudzību ar visaptverošām dublēšanas stratēģijām un izpratni par uzlabotām atkopšanas iespējām, ja standarta pieejas izrādās nepietiekamas.

12. Atsauces

1. Microsoft Learn. “DBCC CHECKDB (Transact-SQL).” SQL Server DokumentācijaMicrosoft korporācija.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. “Novērsiet DBCC CHECKDB ziņotās datubāzes konsekvences kļūdas.” SQL Server DokumentācijaMicrosoft korporācija.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors