DBCC CHECKDB: išsamus MS vadovas SQL Server Duomenų bazės būklė (2025 m.)

Duomenų bazės sugadinimas yra kiekvienas SQL Server administratoriaus košmaras. Kai svarbūs verslo duomenys tampa nepasiekiami arba nepatikimi, cost gali būti pražūtinga. Šiame išsamiame vadove pateikiama viskas, ką reikia žinoti apie DBCC CHECKDB naudojimą duomenų bazės sveikatai palaikyti ir apsaugai nuo gedimų, taip pat pateikiami pažangūs atkūrimo sprendimai, kai standartinių įrankių nepakanka.

1. Svarba SQL Server Duomenų bazės sveikata

1.1 Kas yra duomenų bazės sugadinimas Costs Įmonės

Šiandien, m.ost Įmonės saugo savo svarbiausius duomenis duomenų bazėse. Duomenų bazių sugadinimo pasekmės yra katastrofiškos:

• Finansiniai nuostoliai vidutiniškai 2.3 mln. USD per metus dėl duomenų praradimo, o pagrindinės priežastys yra aparatinės įrangos gedimai ir korupcija („EMC Corporation“)
• Įmonių uždarymo rodikliai rodo, kad 50 % mažų įmonių, patiriančių duomenų praradimą dėl aparatinės įrangos gedimų, bankrutuoja per dvejus metus, o 94 % įmonių, patyrusių katastrofišką duomenų praradimą, visiškai neišgyvena.
• Duomenų korupcijos dažnis kasmet paveikia 20 % itin svarbių programų ir sukelia verslo tęstinumo sutrikimų („Gartner“ tyrimai)
• Su aparatine įranga susijusi korupcija sudaro 67 % visų duomenų praradimo atvejų dėl standžiųjų diskų gedimų ir sistemos gedimų, o 40 % duomenų praradimo tiesiogiai siejama su aparatinės įrangos gedimais.
• Programinės įrangos korupcija costs svyruoja nuo tūkstančių iki milijonų dolerių, priklausomai nuo sunkumo ir masto, o 82 % įmonių patiria neplanuotų sutrikimų, kurių pagrindinė priežastis buvo korupcija.

1.2 Kodėl reguliarūs sveikatos patikrinimai yra labai svarbūs

Žmonėms reikia reguliariai tikrintis sveikatą, kad būtų galima anksti nustatyti galimas ligas. Panašiai ir duomenų bazėms reikia reguliariai tikrintis sveikatą:

1. Anksti aptikti galimą korupciją ir nedelsiant ją spręsti, užkertant kelią problemoms tapti rimtoms ir plačiai paplitusioms, kurios galėtų sukelti katastrofiškų pasekmių verslui.
2. Užtikrinkite, kad duomenų bazė veiktų optimaliu našumu.
3. Cost Proaktyvių duomenų bazės sveikatos patikrinimų atlikimas yra daug mažesnis nei reaktyvaus duomenų atkūrimo po duomenų bazės katastrofos.

1.3 Įvadas į duomenų bazės vientisumo komandas

SQL Server pateikia keletą integruotų komandų duomenų bazės sveikatos palaikymui, su DBCC CHECKDB tarnauja kaip most Išsami vientisumo tikrinimo priemonė. Šios komandos veikia kartu, kad patikrintų skirtingus jūsų duomenų bazės struktūros aspektus – nuo ​​atskirų lentelių iki visos duomenų bazės nuoseklumo, ir sukurtų visapusišką priežiūros strategiją, kuri užtikrina jūsų duomenų saugumą ir prieinamumą.

2. Kas yra DBCC CHECKDB?

DBCC CHECKDB is SQL Serveryra pagrindinė priemonė duomenų bazės vientisumui tikrinti ir gedimų problemoms nustatyti.

• Tai T-SQL sakinys, o ne grafinės sąsajos įrankis.
• Galite tai padaryti naudodami įprastus metodus, pvz. SQL Server Vadybos studija (SSMS), SQL Server Agentas, SQLCMD ir kt.

2.1 Ką CHECKDB iš tikrųjų tikrina jūsų duomenų bazėje

Paleidus DBCC CHECKDB, komanda atlieka kelis patvirtinimo sluoksnius visoje jūsų duomenų bazės struktūroje:

• Puslapio kontrolinių sumų patikrinimas aptikti fizinę korupciją ir su aparatine įranga susijusias problemas
• Indekso nuoseklumo patvirtinimas siekiant užtikrinti tinkamą duomenų paiešką ir užklausų našumą
• Paskirstymo struktūros patikrinimai siekiant patvirtinti tikslų vietos panaudojimą ir puslapių paskirstymą
• Referencinio vientisumo tyrimas tarp susijusių lentelių ir išorinių raktų ryšių
• Sistemos lentelės nuoseklumo patvirtinimas užtikrinti SQL Servervidiniai metaduomenys išlieka patikimi
• Duomenų puslapio susiejimo patvirtinimas patvirtinti tinkamą puslapio grandinės vientisumą
• Duomenų bazės schemos nuoseklumas patvirtinti objektų apibrėžimus ir priklausomybes

Šie išsamūs patikrinimai apima tiek naudotojų duomenis, tiek sistemos struktūras, suteikdami visišką jūsų duomenų bazės sveikatos būklės matomumą.

3. DBCC CHECKDB vykdymas: žingsnis po žingsnio

3.1 Būtinos sąlygos

Žemiau pateikiamas kontrolinis sąrašas prieš vykdant bet kokią DBCC CHECKDB operaciją:

• Visiška duomenų bazės atsarginė kopija – Prieš atlikdami vientisumo patikrinimus, sukurkite pilną atsarginę kopiją – tai apsaugos priemonė, jei būtų aptikta duomenų klaida arba prireiktų taisymo.
• Tinkami leidimai – Norint vykdyti DBCC CHECKDB komandas, reikia sistemos administratoriaus arba db_owner teisių.
• Pakankami sistemos ištekliai:
  • Atmintis: 25 % duomenų bazės dydžio
  • Laikinosios duomenų bazės erdvė: 10–15 % duomenų bazės dydžio
  • CPU: 50–70 % prieinamumas techninės priežiūros metu
  • Įvestis/išvestis: Tikėtini intensyvūs skaitymo darbai
• Duomenų bazės prieinamumas – Patikrinkite, ar jūsų duomenų bazė yra prieinama ir nėra apribotoje būsenoje, nes CHECKDB reikalauja skaitymo prieigos prie visų duomenų bazės puslapių.

3.2 Pagrindinė komanda

Most Pagrindinė DBCC CHECKDB komanda apima tris dažniausiai pasitaikančius variantus:

(1) Patikrinkite dabartinę duomenų bazę (be parametrų):

DBCC CHECKDB

(2) Patikrinkite duomenų bazę pagal pavadinimą:

DBCC CHECKDB ('YourDatabaseName')

(3) Patikrinkite duomenų bazę pagal ID:

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

Ši pagrindinė komanda atlieka išsamų nurodytos duomenų bazės vientisumo patikrinimą, išnagrinėdama visas lenteles, indeksus ir sistemos struktūras. Duomenų bazėms su standartiniais pavadinimais be tarpų galite praleisti kabutes. Komanda bus vykdoma iki pabaigos, rodant eigos pranešimus ir galutinius rezultatus. Ši pagrindinė sintaksė puikiai veikia mažesnėse duomenų bazėse arba kai turite pakankamai laiko priežiūrai.

Žemiau pateikta ekrano kopija, kurioje parodyta, kaip veikia DBCC CHECKDB SQL Server Valdymo studija (SSMS):

3.3 Visos parinktys

Žemiau pateikiamos visos DBCC CHECKDB parinktys:

Kategorija	pasirinkimas	Aprašymas	DBCC CHECKDB pavyzdys
Remonto parinktys	REPAIR_REBUILD	Remontas neprarandant duomenų (pvz., indeksų atkūrimas)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Neremontuojama. Tik atgalinis suderinamumas.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Ištaiso visas klaidas (gali prarasti duomenis)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Apimties valdymas	NOINDEX	Praleidžia neklasterinių indeksų patikrinimus	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Tikrina tik fizinio saugojimo vientisumą (puslapius / įrašus)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Tikrina, ar nėra loginių stulpelių reikšmių klaidų (pvz., negaliojančių datų)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Gilūs loginiai patikrinimai (indeksuoti rodiniai, XML/erdviniai indeksai)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Išvesties valdymas	ALL_ERRORMSGS	Rodo visas klaidas (numatytoji reikšmė: 200 vienam objektui)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Slepia informacinius pranešimus	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
spektaklis	TABLOCK	Naudoja lentelių užraktus (sumažina „TempDB“ naudojimą, bet blokuoja rašymą)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Perrašo lygiagretumo nustatymus	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Naudingumas	ESTIMATEONLY	Įvertina reikalingą „TempDB“ erdvę. (tikrinimo nereikia)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Rezultatų supratimas

DBCC CHECKDB pateiks skirtingus rezultatus, priklausomai nuo to, ar jos vykdymas sėkmingas, ar ne. Paaiškinkime juos išsamiau.

4.1 CHECKDB vykdymas sėkmingai užbaigtas

Jei DBCC CHECKDB vykdymas bus sėkmingai baigtas, bus pateikti skirtingų tipų rezultatai, priklausomai nuo jūsų duomenų bazės sveikatos būsenos.

4.1.1 Nerasta jokių problemų

Jei DBCC CHECKDB neranda jokių problemų, matysite panašią išvestį:

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 rezultatas rodo, kad jūsų duomenų bazė išlaiko nepriekaištingą vientisumą visose patikrintose struktūrose.

4.1.2 Rasta korupcijos klaidų

Kai DBCC CHECKDB aptinka sugadinimo klaidą, ji pateikia klaidos pranešimą su tokia struktūra:
Sunkumo lygio vadovas:

• 16–19 lygis: Vartotojo ištaisomos klaidos, dažnai nedidelės iškraipymo priežastys
• 20–24 lygis: Sistemos klaidos, rimta korupcija, reikalaujanti nedelsiant atkreipti dėmesį
• Lygis 25: Lemtingos klaidos, duomenų bazė gali būti nepasiekiama

Įprastos klaidos apima:

• Puslapio kontrolinės sumos klaidos (824 pranešimas)
• Paskirstymo klaidos (pranešimas 8928)
• Indekso nuoseklumo problemos (pranešimas 8964)

Žinutės struktūros supratimas padeda nustatyti reagavimo veiksmų prioritetus ir tinkamas atkūrimo strategijas.

4.1.3 Dažniausiai pasitaikantys informaciniai ir įspėjamieji pranešimai

Ne visa DBCC CHECKDB išvestis rodo rimtas problemas. Ji taip pat gali išvesti informacinius ir įspėjamuosius pranešimus, įskaitant:

• Remonto pareiškimai – Pranešimai, kuriuose siūlomos taisymo komandos nedidelėms problemoms išspręsti
• Paskirstymo įspėjimai – Įspėjimai apie vietos paskirstymą, kurie neturi įtakos prieigai prie duomenų
• Našumo rekomendacijos – Pasiūlymai dėl indekso priežiūros ir optimizavimo
• Informaciniai pranešimai – Bendri būsenos pranešimai, nereikalaujantys skubių veiksmų

Šie pranešimai teikia vertingas priežiūros gaires, kartu atskirdami kritinius gedimus, kuriems reikia nedelsiant imtis veiksmų, nuo nedidelių problemų, kurias galima išspręsti įprastų priežiūros laikotarpių metu.

Įspėjamojo pranešimo pavyzdys:

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 vykdymo nutraukimai

Jei CHECKDB vykdymo metu dėl įvairių priežasčių nutraukiamas darbas, pateikiamas klaidos pranešimas ir pridedamas klaidų žurnalas su toliau nurodytu būsenos kodu:

Valstybės	Aprašymas
0	Buvo iškelta klaida Nr. 8930. Tai rodo metaduomenų sugadinimą, kuris nutraukė DBCC komandą.
1	Buvo iškelta klaida Nr. 8967. Įvyko vidinė DBCC klaida.
2	Avarinio režimo duomenų bazės taisymo metu įvyko klaida.
3	Tai rodo metaduomenų sugadinimą, kuris nutraukė DBCC komandą.
4	Aptiktas teiginio arba prieigos pažeidimas.
5	Įvyko nežinoma klaida, kuri nutraukė DBCC komandą.

Klaidos pranešimo pavyzdys:

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

Klaidų žurnalo pavyzdys:

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.

Tokiu atveju galite išbandyti alternatyvias išplėstines parinktis, pvz. DataNumen SQL Recovery kad ištaisytumėte duomenų bazės sugadinimą.

5. Korupcijos klaidų taisymas

5.1 Atsarginių kopijų kūrimas ir atkūrimas: saugiausias sprendimas

Kai DBCC CHECKDB aptinka korupcijos klaidas, atkūrimas iš švarios atsarginės kopijos yra saugiausias ir veiksmingiausias būdas.ost patikimas sprendimas. Šis metodas garantuoja duomenų vientisumą ir pašalina pagrindines gedimo priežastis. Prieš atkurdami patikrinkite atsarginės kopijos vientisumą naudodami ATSTATYTI TIK PATVIRTINTI komandas ir apsvarstykite atkūrimo konkrečiu momentu parinktis, kad sumažintumėte duomenų praradimą. Dokumentuokite gedimo detales, kad būtų galima atlikti pagrindinių priežasčių analizę, nes aparatinės įrangos ar programinės įrangos klaidoms gali prireikti papildomo dėmesio, kad būtų išvengta pasikartojimo.

5.2 Puslapio lygio iškraipymų sprendimai

Esant pavieniams puslapio iškraipymams, paveikiantiems mažas duomenų dalis, SQL Server „Enterprise Edition“ siūlo puslapių atkūrimo galimybes, kurios pataiso konkrečius pažeistus puslapius neatkuriant visos duomenų bazės. Šiam pažangiam metodui reikalingas visiškas atkūrimo modelis ir naujausios žurnalų atsarginės kopijos.

Žingsnis po žingsnio puslapio atkūrimo procesas:

1. Sugadinto puslapio nustatymas iš CHECKDB klaidos pranešimo (pvz., 1:256 puslapis)
2. Padarykite dabartinę žurnalo atsarginę kopiją norint užfiksuoti naujausius sandorius:

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

3. Atkurti sugadintą puslapį nuo m.ost Naujausia pilna atsarginė kopija:

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

4. Taikyti diferencinę atsarginę kopiją (jei galima):

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

5. Taikyti visas žurnalų atsargines kopijas iš eilės, įskaitant ką tik sukurtą:

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. Padarykite galutinę žurnalo atsarginę kopiją ir atkurkite kad puslapis būtų aktualus:

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

Alternatyva nekritiniams duomenims: Jei sugadinimas paveikia nekritinius duomenis, prieš atkurdami sugadintas struktūras, galite eksportuoti nepažeistas eilutes į naujas lenteles:

-- 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 Greiti indekso sugadinimo pataisymai

Indekso sugadinimas dažnai gerai reaguoja į atkūrimo operacijas, kurios atkuria indekso struktūras nepaveikdamos pagrindinių lentelių duomenų:

ALTER INDEX ALL ON YourTable REBUILD

Šis metodas ypač gerai veikia esant nesugrupuotam indekso sugadinimui, nes atkuriant indekso puslapius iš šaltinio lentelės duomenų, efektyviai pašalinant sugadinimą ir išsaugant visą originalią informaciją.

6. Naudokite REPAIR_REBUILD ir REPAIR_ALLOW_DATA_LOSS

Jei visi ankstesni metodai nepavyksta arba yra neįgyvendinami, galite naudoti parinktis REPAIR_REBUILD ir REPAIR_ALLOW_DATA_LOSS, kad pataisytumėte duomenų bazę.

6.1 REPAIR_REBUILD (saugesnis variantas):

• Naudojimas: Indekso sugadinimas ir nedidelės paskirstymo klaidos
• Duomenų sauga: Bandoma ištaisyti korupciją neištrinant duomenų
• Rizikos lygis: Žemas – duomenų praradimo nenumatoma
• Tipiniai scenarijai: Nesusieto indekso sugadinimas, nedidelės metaduomenų problemos
• Komandos pavyzdys: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Paskutinė priemonė):

• Naudojimas: Didelis duomenų korupcijos lygis, kai atsarginės kopijos nepasiekiamos.
• Duomenų sauga: Gali ištrinti sugadintus duomenis, kad būtų atkurtas duomenų bazės funkcionalumas
• Rizikos lygis: Aukštas – galimas negrįžtamas duomenų praradimas
• Tipiniai scenarijai: Puslapio sugadinimas, sistemos lentelės pažeidimas, paskirstymo grandinės klaidos
• Komandos pavyzdys: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Geriausia šių variantų praktika:

• Visada išbandykite duomenų bazės kopijų taisymo operacijos, kai įmanoma
• Visada kurkite atsargines kopijas prieš paleisdami šias parinktis
• Dokumentuokite visus pakeitimus atitikties ir trikčių šalinimo tikslais
• Nustatyti duomenų bazę vieno vartotojo režimu prieš pradedant remonto darbus

Paprastai turėtume pabandyti REMONTAS_PERSTATYMAS pirmiausia parinktį. Jei nepavyksta, pabandykite REPAIR_ALLOW_DATA_LOSS pasirinkimas.

6.4 REPAIR_ALLOW_DATA_LOSS rezultatai

6.4.1 Sėkmingas taisymas, praradus duomenis

Kartais REPAIR_ALLOW_DATA_LOSS parinktis bus sėkminga, bet kai kurie duomenys yra lost po remonto.

Žemiau pateikiami keli pavyzdiniai pranešimai:

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.

Taip yra todėl, kad DBCC CHECKDB pataiso duomenų bazę atsisakydama kai kurių sugadintų įrašų, bet iš tikrųjų, most iš jų vis dar galima susigrąžinti per DataNumen SQL Recovery.

Pavyzdiniai failai:

SQL Server versija	Sugadintas MDF failas	MDF failas pataisytas DataNumen SQL Recovery
SQL Server 2014	Klaida10_1.mdf (Žinutė 8909, po kurios seka žinutė 8939) (600 įrašų)ost su REPAIR_ALLOW_DATA_LOSS)	Klaida10_1_fixed.mdf (Nėra įrašų lost)
SQL Server 2014	Klaida10_2.mdf (Žinutė 8909, po kurios seka žinutė 8939) (6000 įrašų (50 %) lost su REPAIR_ALLOW_DATA_LOSS)	Klaida10_2_fixed.mdf (Tik 100 įrašų)ost)
SQL Server 2014	Error7.mdf (100 įrašų lost su REPAIR_ALLOW_DATA_LOSS)	Error7_fixed.mdf (Tik vienas įrašas lost)

6.4.2 Remontas nepavyksta – apsvarstykite profesionalų sprendimą

If REPAIR_ALLOW_DATA_LOSS nepavyksta, bus pateiktas vienas ar keli klaidos pranešimai.

Žemiau pateikiami keli pavyzdžiai:

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.

Tokiais atvejais turite kreiptis į profesionalų sprendimą, pvz. DataNumen SQL Recovery kad sutvarkytumėte savo duomenų bazę.

Pavyzdiniai failai

SQL Server versija	Sugadintas MDF failas	MDF failas pataisytas DataNumen SQL Recovery
SQL Server 2014	Klaida1_3.mdf (Vienkartinė žinutė 824)	Klaida1_3_fixed.mdf
SQL Server 2014	Klaida1_1.mdf (Nuolatinės klaidos pranešime 824)	Klaida1_1_fixed.mdf
SQL Server 2014	Klaida1_2.mdf ((Žinutė 824, po kurios seka Žinutė 7909)	Klaida1_2_fixed.mdf
SQL Server 2014	Klaida4_1.mdf (Žinutė 8992, po kurios seka Žinutė 3852)	Klaida4_1_fixed.mdf
SQL Server 2014	Klaida4_2.mdf (Žinutė 8992, po kurios seka Žinutė 3852)	Klaida4_2_fixed.mdf
SQL Server 2014	Klaida5.mdf (Žinutė 8945)	Error5_fixed.mdf
SQL Server 2014	Klaida6.mdf (Žinutė 2510)	Error6_fixed.mdf
SQL Server 2014	Klaida2.mdf (Žinutė 2575)	Error2_fixed.mdf
SQL Server 2014	Klaida11.mdf (Žinutė 8905)	Error11_fixed.mdf
SQL Server 2014	Klaida3.mdf (Žinutė 5028)	Error3_fixed.mdf
SQL Server 2014	Error8.mdf (Žinutė 5125)	Error8_fixed.mdf
SQL Server 2014	Klaida9.mdf (Žinutė 3313)	Error9_fixed.mdf

7. Geriausia praktika

7.1 Įprastų CHECKDB operacijų planavimas

Įdiegti savaitinį DBCC CHECKDB vykdymą kritinėms gamybinėms duomenų bazėms, atliekant kasdienius patikrinimus didelės operacijų apimties sistemose. Planuoti operacijas mažai naudojamomis laikotarpiais, kad sumažintumėte poveikį našumui, ir apsvarstyti galimybę kaitalioti išsamius patikrinimus ir PHYSICAL_ONLY parinktis, atsižvelgiant į duomenų bazės dydį ir priežiūros laikotarpius. Automatinis planavimas naudojant SQL Server Agentas užtikrina nuoseklų vykdymą ir kartu teikia centralizuotas stebėjimo bei įspėjimų galimybes.

7.2 Veiklos poveikio valdymas

DBCC CHECKDB operacijos sunaudoja didelius sistemos išteklius, o tai gali turėti įtakos vienalaikiam vartotojų aktyvumui. Stebėkite procesoriaus naudojimą, atminties naudojimą ir disko įvesties/išvesties operacijas patikrų metu, kad suprastumėte našumo poveikio modelius. Apsvarstykite galimybę naudoti NOINDEX parinktis įprastiems patikrinimams, o visišką patvirtinimą rezervuokite mėnesiniams priežiūros langams. Įdiekite užklausų skirtojo laiko plėtinius ir vartotojų bendravimo strategijas, kad valdytumėte lūkesčius vientisumo tikrinimo laikotarpių metu.

7.3 Techninės priežiūros langų planavimas

Koordinuokite DBCC CHECKDB planavimą su kita priežiūros veikla, pvz., atsarginių kopijų kūrimu, indeksų atkūrimu ir statistikos atnaujinimais. Venkite daug išteklių reikalaujančių operacijų, kurios gali sukelti našumo pablogėjimą arba skirtojo laiko problemas. Planuokite priežiūros laikotarpius pagal duomenų bazės dydžio augimo prognozes, užtikrindami pakankamai laiko visiškam vientisumo patikrinimui, didėjant duomenų kiekiams.

7.4 Automatinis stebėjimas ir įspėjimai

Nustatyti SQL Server Agento įspėjimai, skirti nedelsiant informuoti administratorius, kai DBCC CHECKDB aptinka pažeidimus. Įdiegti žurnalų analizės sprendimus, kurie išgauna ir suskirsto vientisumo patikros rezultatus į kategorijas, taip įgalinant tendencijų analizę ir proaktyvų problemų identifikavimą. Sukurti eskalavimo procedūras, kurios apibrėžtų reagavimo terminus ir atsakingus darbuotojus, atsižvelgiant į skirtingus pažeidimo sunkumo lygius.

8. DBCC CHECKTABLE: lengvesnė alternatyva

8.1 Kada naudoti CHECKTABLE vietoj CHECKDB

DBCC CHECKTABLE teikia tikslinį vientisumo patikrinimą atskiroms lentelėms, todėl idealiai tinka tarGautas konkrečių duomenų bazės objektų trikčių šalinimas ir priežiūra. Naudokite CHECKTABLE, kai tiriate našumo problemas su konkrečiomis lentelėmis, tikrinate kritines verslo lenteles tarp išsamių duomenų bazės patikrinimų arba kai laiko apribojimai neleidžia visiškai patikrinti duomenų bazės. Šis metodas ypač vertingas didelėse duomenų bazėse, kuriose išsamios CHECKDB operacijos viršija galimus priežiūros laikotarpius.

8.2 DBCC CHECKTABLE sintaksė ir pavyzdžiai

Pagrindinė CHECKTABLE komanda targauna konkrečias lenteles:

DBCC CHECKTABLE('YourTable')

Kaip ir CHECKDB, CHECKTABLE palaiko įvairias parinktis, įskaitant NOINDEX našumo optimizavimui ir taisymo parametrus gedimų šalinimui. Taip pat galite nurodyti schemų pavadinimus, kad tiksliai identifikuotumėte lenteles:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

tai tar„geted“ metodas leidžia atlikti detalų vientisumo patikrinimą, išlaikant sistemos našumą darbo valandomis.

8.3 Didelių duomenų bazių našumo pranašumai

CHECKTABLE operacijos atliekamos žymiai greičiau nei pilnos duomenų bazės patikros, todėl galima dažniau tikrinti kritinių lentelių vientisumą. Šis metodas leidžia kasdien tikrinti esmines verslo lenteles, o išsamias CHECKDB operacijas rezervuoti savaitės ar mėnesio tvarkaraščiams. Sumažintas išteklių sunaudojimas leidžia CHECKTABLE naudoti gamybinėje aplinkoje, o tai daro minimalų poveikį vartotojui.

9. Kai CHECKDB nepavyksta

DBCC CHECKDB nepavyks veikti įvairiais atvejais, įskaitant:

• DBCC CHECKDB vykdymas nutrūksta neįprastai
• DBCC CHECKDB vykdymas sėkmingai baigtas, bet remonto variantai nepavyko atkurti duomenų bazės.

Tokiais atvejais mums reikia profesionalesnio įrankio, kuris padėtų ištaisyti duomenų bazės klaidas.

9.1 Įvadas į DataNumen SQL Recovery

DataNumen SQL Recovery suteikia daugiau pažangių galimybių:

• Geriausias atkūrimo greitis pramonėje.
• Atkurti smarkiai sugadintus duomenų bazės failus.
• Atkurti visus duomenų bazės objektus, įskaitant lenteles, indeksus, rodinius, paleidiklius, taisykles ir numatytuosius nustatymus.
• Atkurti išsaugotas procedūras, skaliarines funkcijas, eilutines lentelės reikšmių funkcijas ir kelių teiginių lentelės vertės funkcijas.
• Atkurti visam laikui ištrintus įrašus.
• Iššifruoti užšifruotus objektus SQL Server duomenų bazės.
• MDF failų taisymas partijomis.
• Išsamios remonto galimybės.
• Išplėstinis registravimas ir ataskaitų teikimas.
• Parama visiems SQL Server versijos.
• Techninės pagalbos prieinamumas
• Reguliarūs atnaujinimai ir patobulinimai

9.2 Sėkmės rodiklio palyginimas

Atkūrimo sėkmės rodikliai labai skiriasi:

• DBCC CHECKDB ir CHECKTABLE: 1.27% vidutinis atkūrimo greitis
• DataNumen: 92.6% atkūrimo rodiklis

Žemiau pateikiamas išsamus konkurencinis palyginimas:

9.3 Atsigavimas po sunkios korupcijos

Išplėstinės galimybės sunkiais atvejais:

• Atkūrimas iš fiziškai pažeistos saugyklos
• Atkūrimas iš suformatuotų diskų arba sudužusių sistemų
• Atkurti iš disko vaizdų, atsarginių kopijų failų, virtualios mašinos disko failų, temporary failai ir kt.

9.4 Kada verta apsvarstyti profesionalius sprendimus

• Nėra neseniai prieinamų atsarginių kopijų
• DBCC CHECKDB nepavyksta
• Sunkūs korupcijos scenarijai
• Svarbiausių verslo duomenų tvarkymas
• Kai laikas yra kritinis
• Kai būtinas maksimalus atsigavimas

10. DUK

11. Išvada

11.1 Pagrindinių punktų santrauka

11.1.1 Svarbiausių DBCC CHECKDB komandų santrauka

Įsisavinti pagrindinę DBCC CHECKDB sintaksę išsamiam duomenų bazės tikrinimui, naudoti NOINDEX ir PHYSICAL_ONLY parinktis našumo optimizavimui ir suprasti CHECKTABLE. tarGautos lentelės patikrinimas. Šios pagrindinės komandos sudaro aktyvios duomenų bazės priežiūros pagrindą, leidžiantį anksti aptikti sugadinimus ir sistemingai stebėti vientisumą.

11.1.2 Svarbiausių geriausios praktikos pavyzdžių priminimas

Prieš atlikdami vientisumo patikrinimus, visada sukurkite naujausias atsargines kopijas, planuokite reguliarias CHECKDB operacijas pagal duomenų bazės kritiškumą ir įdiekite automatinį stebėjimą, kad gautumėte neatidėliotinus įspėjimus apie duomenų sugadinimą. Atminkite, kad prevencija reguliaraus stebėjimo būdu pranoksta reaktyvius metodus, o profesionalūs atkūrimo sprendimai suteikia vertingų atsarginių kopijų kūrimo galimybių, kai standartinių įrankių nepakanka.

11.2 Kada naudoti DBCC CHECKDB ir kada naudoti pažangius sprendimus

Naudokite DBCC CHECKDB įprastinei vientisumo stebėsenai ir nedideliems pažeidimams šalinti, o profesionalius atkūrimo įrankius pasilikite rimtiems pažeidimo scenarijams, viršijantiems integruotas taisymo galimybes. Sprendimų sistema turėtų atsižvelgti į atsarginių kopijų prieinamumą, duomenų kritiškumą, laiko apribojimus ir pažeidimo sunkumą. Sėkmingi duomenų bazių administratoriai derina reguliarų CHECKDB stebėjimą su išsamiomis atsarginių kopijų kūrimo strategijomis ir pažangių atkūrimo parinkčių žinojimu, kai standartiniai metodai pasirodo esą nepakankami.

12. Nuorodos

1. „Microsoft Learn“. „DBCC CHECKDB (Transact-SQL)“. SQL Server Dokumentacija„Microsoft“ korporacija.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. „Microsoft Learn“. „DBCC CHECKDB“ praneštų duomenų bazės nuoseklumo klaidų šalinimas.“ SQL Server Dokumentacija„Microsoft“ korporacija.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors