DBCC CHECKDB: MS-ի ամբողջական ուղեցույց SQL Server Տվյալների բազայի առողջություն (2026)

DBCC CHECKDB-ն է SQL Server-ի տվյալների բազայի ամբողջականության հիմնական գործիքը: Սովորեք, թե ինչպես օգտագործել այն օրինակներով, շտկել վնասը և օպտիմալացնել կատարողականը:

3. DBCC CHECKDB-ի գործարկում. Քայլ առ քայլ

3.1 Նախապայմաններ

Ստորև ներկայացված է ստուգաթերթիկը՝ DBCC CHECKDB ցանկացած գործողություն կատարելուց առաջ.

• Ամբողջական տվյալների բազայի պահուստավորում – Ստեղծեք ամբողջական պահուստային պատճեն՝ ամբողջականության ստուգումներ կատարելուց առաջ, որպես ձեր անվտանգության ցանց, եթե վնաս հայտնաբերվի կամ վերանորոգման գործողություններ անհրաժեշտ լինեն։
• Համապատասխան թույլտվություններ – DBCC CHECKDB հրամանները կատարելու համար ձեզ անհրաժեշտ են sysadmin կամ db_owner թույլտվություններ։
• Բավարար համակարգային ռեսուրսներ.
  • Հիշողություն՝ տվյալների բազայի չափի 25%-ը
  • Tempdb տարածք՝ տվյալների բազայի չափի 10-15%-ը
  • CPU: 50-70% մատչելիություն սպասարկման ընթացքում
  • Մուտք/Ելք. Ակնկալվում են ծանրաբեռնված ընթերցման գործողություններ
• Տվյալների բազայի հասանելիություն – Ստուգեք, որ ձեր տվյալների բազան հասանելի է և սահմանափակված չէ, քանի որ CHECKDB-ն պահանջում է կարդալու հասանելիություն տվյալների բազայի բոլոր էջերին

3.2 Հիմնական հրաման

Մost DBCC CHECKDB հիմնական հրամանը ներառում է երեք տարածված տարբերակ՝

(1) Ստուգեք ներկայիս տվյալների բազան (առանց պարամետրերի):

DBCC CHECKDB

(2) Ստուգեք տվյալների բազան անունով.

DBCC CHECKDB ('YourDatabaseName')

(3) Ստուգեք տվյալների բազան ըստ ID-ի՝

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

Այս հիմնարար հրամանը կատարում է նշված տվյալների բազայի ամբողջականության ստուգում՝ ուսումնասիրելով բոլոր աղյուսակները, ինդեքսները և համակարգի կառուցվածքները: Բացատներ չպարունակող ստանդարտ անուններով տվյալների բազաների համար կարող եք բաց թողնել չակերտները: Հրամանը կգործի մինչև ավարտը՝ ցուցադրելով առաջընթացի հաղորդագրություններ և վերջնական արդյունքներ: Այս հիմնական շարահյուսությունը կատարյալ է աշխատում փոքր տվյալների բազաների համար կամ երբ դուք ունեք բավարար սպասարկման ժամանակ:

Ստորև ներկայացված է DBCC CHECKDB-ի գործարկման էկրանի նկարը։ SQL Server Կառավարման ստուդիա (SSMS):

3.3 Լրիվ տարբերակներ

Ստորև ներկայացված են DBCC CHECKDB-ի ամբողջական տարբերակները.

կատեգորիա	Տարբերակ	Նկարագրություն	DBCC CHECKDB օրինակ
Վերանորոգման ընտրանքներ	REPAIR_REBUILD	Վերականգնում առանց տվյալների կորստի (օրինակ՝ ինդեքսի վերակառուցում)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Վերանորոգում չի պահանջվում։ Միայն հետադարձ համատեղելիություն։	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Վերականգնում է բոլոր սխալները (կարող է հանգեցնել տվյալների կորստի)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Շրջանակի կառավարում	NOINDEX	Բաց է թողնում ոչ կլաստերային ինդեքսի ստուգումները	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Ստուգում է միայն ֆիզիկական պահեստի ամբողջականությունը (էջեր/գրառումներ)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Ստուգում է սյունակի արժեքի տրամաբանական սխալները (օրինակ՝ անվավեր ամսաթվեր)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Խորը տրամաբանական ստուգումներ (ինդեքսավորված տեսքեր, XML/տարածական ինդեքսներ)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Արդյունքների վերահսկում	ALL_ERRORMSGS	Ցուցադրում է բոլոր սխալները (նախնական՝ 200 յուրաքանչյուր օբյեկտի համար)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Թաքցնում է տեղեկատվական հաղորդագրությունները	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
Performance	TABLOCK	Օգտագործում է աղյուսակի կողպեքներ (նվազեցնում է TempDB-ի օգտագործումը, բայց արգելափակում է գրառումները)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Անտեսում է զուգահեռականության կարգավորումները	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Սպասարկող ծրագիր	ESTIMATEONLY	Գնահատում է TempDB-ի անհրաժեշտ տարածքը։ (իրական ստուգում չկա)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Ձեր արդյունքների ըմբռնումը

DBCC CHECKDB-ն կարտացոլի տարբեր արդյունքներ՝ կախված նրանից, թե արդյոք դրա կատարումը հաջողությամբ է ավարտվել, թե ոչ: Եկեք մանրամասն բացատրենք դրանք:

4.1 CHECKDB-ի կատարումը հաջողությամբ ավարտվեց

Եթե ​​DBCC CHECKDB-ի կատարումը հաջողությամբ ավարտվի, այն կհաղորդի տարբեր տեսակի արդյունքներ՝ կախված ձեր տվյալների բազայի առողջական վիճակից։

4.1.1 Խնդիրներ չեն հայտնաբերվել

Եթե ​​DBCC CHECKDB-ն որևէ խնդիր չի գտնում, կտեսնեք հետևյալին նման արդյունք՝

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

Այս արդյունքը ցույց է տալիս, որ ձեր տվյալների բազան պահպանում է կատարյալ ամբողջականություն բոլոր ստուգված կառուցվածքներում։

4.1.2 Հայտնաբերված կոռուպցիոն սխալներ

Երբ DBCC CHECKDB-ն հայտնաբերում է կոռուպցիայի սխալ, այն կհաղորդի սխալի հաղորդագրություն հետևյալ կառուցվածքով.
Ծանրության մակարդակի ուղեցույց.

• 16-19 մակարդակներ։ Օգտագործողի կողմից ուղղելի սխալներ, հաճախ աննշան վնասներ
• 20-24 մակարդակներ։ Համակարգային սխալներ, լուրջ կոռուպցիա, որը պահանջում է անհապաղ ուշադրություն
• Մակարդակ 25: Ճակատագրական սխալներ, տվյալների բազան կարող է անհասանելի լինել

Ընդհանուր սխալները ներառում են.

• Էջի ստուգման գումարի սխալներ (հաղորդագրություն 824)
• Բաշխման սխալներ (հաղորդագրություն 8928)
• Ինդեքսի համապատասխանության խնդիրներ (հաղորդագրություն 8964)

Հաղորդագրության կառուցվածքի ըմբռնումը օգնում է առաջնահերթություն տալ արձագանքման գործողություններին և որոշել համապատասխան վերականգնման ռազմավարություններ։

4.1.3 Հաճախակի տեղեկատվական և նախազգուշացնող հաղորդագրություններ

DBCC CHECKDB-ի բոլոր արդյունքները լուրջ խնդիրներ չեն ցույց տալիս։ Այն կարող է նաև արտածել որոշ տեղեկատվական և նախազգուշացնող հաղորդագրություններ, այդ թվում՝

• Վերանորոգման հայտարարություններ – Հաղորդագրություններ, որոնք առաջարկում են վերանորոգման հրամաններ՝ մանր խնդիրները շտկելու համար
• Բաշխման նախազգուշացումներ – Տարածքի բաշխման վերաբերյալ նախազգուշացումներ, որոնք չեն ազդում տվյալների հասանելիության վրա
• Արդյունավետության առաջարկություններ – Առաջարկություններ ինդեքսի պահպանման և օպտիմալացման համար
• Տեղեկատվական ծանուցումներ – Ընդհանուր կարգավիճակի հաղորդագրություններ, որոնք անհապաղ գործողություն չեն պահանջում

Այս հաղորդագրությունները տրամադրում են արժեքավոր սպասարկման ուղեցույց՝ միաժամանակ տարբերակելով անհապաղ գործողություններ պահանջող կրիտիկական կոռուպցիան և աննշան խնդիրները, որոնք կարող են լուծվել կանոնավոր սպասարկման պատուհանների ընթացքում։

Օրինակ՝ նախազգուշացնող հաղորդագրություն.

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 կատարման ընդհատումներ

Եթե ​​CHECKDB-ը դադարեցնի իր կատարումը տարբեր պատճառներով, այն կհաղորդի սխալի հաղորդագրություն և կավելացնի սխալի գրանցամատյան՝ ստորև նշված վիճակի կոդով.

պետական	Նկարագրություն
0	Հայտնաբերվել է 8930 սխալի համարը։ Սա ցույց է տալիս մետատվյալների վնասում, որը դադարեցրել է DBCC հրամանը։
1	Առաջ է քաշվել 8967 սխալի համարը։ Տեղի է ունեցել ներքին DBCC սխալ։
2	Արտակարգ ռեժիմում տվյալների բազայի վերանորոգման ընթացքում տեղի է ունեցել խափանում։
3	Սա ցույց է տալիս մետատվյալների վնասը, որը դադարեցրել է DBCC հրամանը։
4	Հայտնաբերվել է հաստատման կամ մուտքի խախտում։
5	Անհայտ սխալ է տեղի ունեցել, որը դադարեցրել է DBCC հրամանը։

Օրինակ սխալի հաղորդագրություն՝

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

Օրինակ սխալների գրանցամատյան.

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.

Այդ դեպքում կարող եք փորձել այլընտրանքային առաջադեմ տարբերակներ, ինչպիսիք են՝ DataNumen SQL Recovery ձեր տվյալների բազայի կոռուպցիան շտկելու համար։

5. Կոռուպցիայի հետ կապված սխալների շտկում

5.1 Պահուստավորում և վերականգնում. ամենաապահով լուծումը

Երբ DBCC CHECKDB-ն հայտնաբերում է կոռուպցիայի սխալներ, մաքուր պահուստային պատճենից վերականգնումը ներկայացնում է ամենաապահով և արդյունավետ տարբերակը։ost հուսալի լուծում: Այս մոտեցումը երաշխավորում է տվյալների ամբողջականությունը՝ միաժամանակ վերացնելով կոռուպցիայի հիմքում ընկած պատճառները: Վերականգնելուց առաջ ստուգեք պահուստային պատճենի ամբողջականությունը՝ օգտագործելով Վերականգնել միայն հաստատմամբ հրամաններ և դիտարկեք ժամանակի ընթացքում վերականգնման տարբերակները՝ տվյալների կորուստը նվազագույնի հասցնելու համար: Փաստաթղթավորեք վնասման մանրամասները՝ արմատական ​​​​պատճառի վերլուծության համար, քանի որ սարքային խնդիրները կամ ծրագրային սխալները կարող են լրացուցիչ ուշադրություն պահանջել՝ կրկնությունը կանխելու համար:

5.2 Էջի մակարդակի կոռուպցիայի լուծումներ

Էջի մեկուսացված վնասման համար, որը ազդում է տվյալների փոքր մասերի վրա, SQL Server Enterprise Edition-ը առաջարկում է էջերի վերականգնման հնարավորություններ, որոնք վերականգնում են որոշակի վնասված էջեր՝ առանց տվյալների բազայի լրիվ վերականգնման: Այս առաջադեմ տեխնիկան պահանջում է ամբողջական վերականգնման մոդել և ընթացիկ գրանցամատյանի պահուստավորում:

Քայլ առ քայլ էջի վերականգնման գործընթաց.

1. Ճանաչեք վնասված էջը CHECKDB սխալի հաղորդագրությունից (օրինակ՝ էջ 1:256)
2. Կատարեք ընթացիկ գրանցամատյանի պահուստային պատճենը վերջին գործարքները գրանցելու համար՝

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

3. Վերականգնել վնասված էջը մ-իցost Վերջերս կատարված լրիվ պահուստավորումը՝

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

4. Կիրառել դիֆերենցիալ պահուստավորում (Եթե առկա է):

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

5. Կիրառել բոլոր գրանցամատյանների պահուստավորումները հաջորդականությամբ, ներառյալ նոր ստեղծվածը.

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. Կատարեք գրանցամատյանի վերջնական պահուստային պատճենը և վերականգնեք այն էջը արդիականացնելու համար՝

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

Ոչ կարևոր տվյալների այլընտրանքային տարբերակը՝ Եթե ​​վնասը ազդում է ոչ կարևոր տվյալների վրա, դուք կարող եք չվնասված տողերը արտահանել նոր աղյուսակներ՝ վնասված կառուցվածքները վերականգնելուց առաջ։

-- 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 Ինդեքսի կոռուպցիայի արագ լուծումներ

Ինդեքսի վնասումը հաճախ լավ է արձագանքում վերակառուցման գործողություններին, որոնք վերստեղծում են ինդեքսի կառուցվածքները՝ առանց ազդելու հիմքում ընկած աղյուսակի տվյալների վրա։

ALTER INDEX ALL ON YourTable REBUILD

Այս մոտեցումը հատկապես լավ է աշխատում ոչ կլաստերային ինդեքսի վնասման դեպքում, քանի որ վերակառուցումը վերականգնում է ինդեքսի էջերը սկզբնաղբյուր աղյուսակի տվյալներից՝ արդյունավետորեն վերացնելով վնասը և պահպանելով ամբողջ սկզբնական տեղեկատվությունը։

6. Օգտագործեք REPAIR_REBUILD և REPAIR_ALLOW_DATA_LOSS

Եթե ​​նախորդ մեթոդները բոլորը ձախողվում են կամ անիրագործելի են, կարող եք օգտագործել REPAIR_REBUILD և REPAIR_ALLOW_DATA_LOSS տարբերակները՝ տվյալների բազան վերականգնելու համար։

6.1 REPAIR_REBUILD (Ավելի անվտանգ տարբերակ):

• Օգտագործման համար: Ինդեքսի վնասում և աննշան բաշխման սխալներ
• Տվյալների անվտանգություն. Կոռուպցիայի շտկման փորձեր՝ առանց տվյալների ջնջման
• Ռիսկի մակարդակ՝ Ցածր՝ տվյալների կորուստ չի սպասվում
• Տիպիկ սցենարներ՝ Ոչ կլաստերային ինդեքսի վնասում, աննշան մետատվյալների խնդիրներ
• Հրամանի օրինակ՝ DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOSS (Վերջին միջոց):

• Օգտագործման համար: Լուրջ կոռուպցիա, երբ պահուստային պատճենները անհասանելի են
• Տվյալների անվտանգություն. Կարող է ջնջել վնասված տվյալները՝ տվյալների բազայի ֆունկցիոնալությունը վերականգնելու համար
• Ռիսկի մակարդակ՝ Բարձր՝ հնարավոր է տվյալների մշտական ​​կորուստ
• Տիպիկ սցենարներ՝ Էջի վնասում, համակարգի աղյուսակի վնասում, բաշխման շղթայի սխալներ
• Հրամանի օրինակ՝ DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Այս տարբերակների լավագույն փորձը.

• Միշտ փորձարկել հնարավորության դեպքում տվյալների բազայի պատճենների վերանորոգման գործողություններ
• Միշտ պահուստավորել այս տարբերակները գործարկելուց առաջ
• Փաստաթղթավորեք բոլոր փոփոխությունները համապատասխանության և խնդիրների լուծման նպատակով
• Տվյալների բազան սահմանել մեկ օգտատիրոջ ռեժիմի վերանորոգման աշխատանքներ կատարելուց առաջ

Սովորաբար մենք պետք է փորձենք ՎԵՐԱՆՈՐՈԳՈՒՄ_ՎԵՐԱԿԱՌՈՒՑՈՒՄ առաջին տարբերակը։ Եթե այն ձախողվի, ապա փորձեք REPAIR_ALLOW_DATA_LOSS տարբերակ.

6.4 REPAIR_ALLOW_DATA_LOSS արդյունքներ

6.4.1 Վերականգնումը հաջողությամբ է ընթանում տվյալների կորստով

Երբեմն REPAIR_ALLOW_DATA_LOSS տարբերակը կհաջողվի, բայց որոշ տվյալներ l ենost վերանորոգումից հետո։

Ստորև բերված են մի քանի նմուշային հաղորդագրություններ.

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.

Սա պայմանավորված է նրանով, որ DBCC CHECKDB-ն շտկում է տվյալների բազան՝ հրաժարվելով որոշ վնասված գրառումներից, բայց իրականում, մost դրանցից դեռևս կարելի է վերականգնել՝ DataNumen SQL Recovery.

Նմուշային ֆայլեր՝

SQL Server տարբերակ	Կոռումպացված MDF ֆայլ	MDF ֆայլը ֆիքսված է DataNumen SQL Recovery
SQL Server 2014	Սխալ 10_1.mdf (Հաղորդագրություն 8909, որին հաջորդում է Հաղորդագրություն 8939) (600 գրառում lost REPAIR_ALLOW_DATA_LOSS-ով)	Սխալ 10_1_fixed.mdf (Գրառում չկա լost)
SQL Server 2014	Սխալ 10_2.mdf (Հաղորդագրություն 8909, որին հաջորդում է Հաղորդագրություն 8939) (6000 գրառում (50%) lost REPAIR_ALLOW_DATA_LOSS-ով)	Սխալ 10_2_fixed.mdf (Միայն 100 գրառում լost)
SQL Server 2014	Error7.մդֆ (100 գրառում լost REPAIR_ALLOW_DATA_LOSS-ով)	Սխալ 7_fixed.mdf (Միայն մեկ ձայնագրություն լost)

6.4.2 Վերանորոգման ձախողումներ – Դիտարկեք մասնագիտական ​​լուծումը

If REPAIR_ALLOW_DATA_LOSS ձախողման դեպքում այն ​​կարտացոլի մեկ կամ մի քանի սխալի հաղորդագրություններ։

Ստորև բերված են մի քանի օրինակներ՝

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.

Այս դեպքերում դուք պետք է օգտագործեք մասնագիտական ​​​​լուծում, ինչպիսիք են՝ DataNumen SQL Recovery ձեր տվյալների բազան շտկելու համար։

Նմուշային ֆայլեր

SQL Server տարբերակ	Կոռումպացված MDF ֆայլ	MDF ֆայլը ֆիքսված է DataNumen SQL Recovery
SQL Server 2014	Սխալ 1_3.mdf (Միայնակ հաղորդագրություն 824)	Սխալ 1_3_fixed.mdf
SQL Server 2014	Սխալ 1_1.mdf (Շարունակական 824 հաղորդագրության սխալներ)	Սխալ 1_1_ ֆիքսված.mdf
SQL Server 2014	Սխալ 1_2.mdf ((Հաղորդագրություն 824, որին հաջորդում է Հաղորդագրություն 7909)	Սխալ 1_2_fixed.mdf
SQL Server 2014	Սխալ 4_1.mdf (Հաղորդագրություն 8992, որին հաջորդում է Հաղորդագրություն 3852)	Սխալ 4_1_fixed.mdf
SQL Server 2014	Սխալ 4_2.mdf (Հաղորդագրություն 8992, որին հաջորդում է Հաղորդագրություն 3852)	Սխալ 4_2_fixed.mdf
SQL Server 2014	Սխալ 5.mdf (Հաղորդագրություն 8945)	Սխալ 5_fixed.mdf
SQL Server 2014	Սխալ 6.mdf (Հաղորդագրություն 2510)	Սխալ 6_fixed.mdf
SQL Server 2014	Սխալ 2.mdf (Հաղորդագրություն 2575)	Սխալ 2_fixed.mdf
SQL Server 2014	Սխալ 11.mdf (Հաղորդագրություն 8905)	Սխալ 11_fixed.mdf
SQL Server 2014	Սխալ 3.mdf (Հաղորդագրություն 5028)	Սխալ 3_fixed.mdf
SQL Server 2014	Error8.մդֆ (Հաղորդագրություն 5125)	Error8_ ֆիքսված.mdf
SQL Server 2014	Սխալ 9.mdf (Հաղորդագրություն 3313)	Սխալ 9_fixed.mdf

7. Լավագույն պրակտիկա

7.1 CHECKDB-ի կանոնավոր գործողությունների ժամանակացույց կազմելը

Կիրառել շաբաթական DBCC CHECKDB կատարումը կարևոր արտադրական տվյալների բազաների համար՝ ամենօրյա ստուգումներով բարձր գործարքային համակարգերի համար: Պլանավորել գործողությունները ցածր օգտագործման ժամանակահատվածներում՝ կատարողականի վրա ազդեցությունը նվազագույնի հասցնելու համար, և դիտարկել լրիվ ստուգումների և PHYSICAL_ONLY տարբերակների միջև հերթափոխը՝ հիմնվելով տվյալների բազայի չափի և սպասարկման պատուհանների վրա: Ավտոմատացված ժամանակացույց՝ SQL Server Գործակալը ապահովում է հետևողական կատարում՝ միաժամանակ ապահովելով կենտրոնացված մոնիթորինգի և ահազանգման հնարավորություններ։

7.2 Արդյունավետության վրա ազդեցության կառավարում

DBCC CHECKDB գործողությունները սպառում են զգալի համակարգային ռեսուրսներ, ինչը հնարավոր է ազդի օգտատիրոջ միաժամանակյա գործունեության վրա: Ստուգումների ընթացքում վերահսկում են CPU-ի օգտագործումը, հիշողության օգտագործումը և սկավառակի մուտքը/ելքը՝ արդյունավետության վրա ազդեցության օրինաչափությունները հասկանալու համար: Խորհուրդ է տրվում օգտագործել NOINDEX տարբերակները ռուտինային ստուգումների համար՝ լրիվ վավերացումը պահելով ամսական սպասարկման պատուհանների համար: Կիրառեք հարցումների ժամկետի ավարտի ընդլայնումներ և օգտատիրոջ հաղորդակցման ռազմավարություններ՝ ամբողջականության ստուգման ժամանակահատվածներում սպասելիքները կառավարելու համար:

7.3 Պատուհանների սպասարկման պլանավորում

Համակարգեք DBCC CHECKDB ժամանակացույցը այլ սպասարկման գործողությունների հետ, ինչպիսիք են պահուստավորման գործողությունները, ինդեքսի վերակառուցումը և վիճակագրության թարմացումները: Խուսափեք համընկնող ռեսուրսատար գործողություններից, որոնք կարող են առաջացնել կատարողականի վատթարացում կամ ժամանակի սպառման խնդիրներ: Պլանավորեք սպասարկման պատուհանները՝ հիմնվելով տվյալների բազայի չափի աճի կանխատեսումների վրա, ապահովելով բավարար ժամանակ ամբողջականության ստուգման համար՝ տվյալների ծավալների աճին զուգընթաց:

7.4 Ավտոմատացված մոնիթորինգ և ահազանգում

Համաձեւել SQL Server Գործակալը զգուշացնում է՝ անմիջապես ադմինիստրատորներին տեղեկացնելու համար, երբ DBCC CHECKDB-ը հայտնաբերում է կոռուպցիա։ Ներդրեք լոգարիթմական վերլուծության լուծումներ, որոնք արդյունահանում և դասակարգում են ամբողջականության ստուգման արդյունքները՝ հնարավորություն տալով վերլուծել միտումները և նախաձեռնողական խնդիրների նույնականացումը։ Ստեղծեք էսկալացիայի ընթացակարգեր, որոնք սահմանում են արձագանքման ժամկետներ և պատասխանատու անձնակազմ՝ կոռուպցիայի տարբեր աստիճանների ծանրության համար։

8. DBCC CHECKTABLE. Թեթև այլընտրանք

8.1 Ե՞րբ օգտագործել CHECKTABLE-ը CHECKDB-ի փոխարեն

DBCC CHECKTABLE-ը ապահովում է առանձին աղյուսակների ամբողջականության կենտրոնացված ստուգում, ինչը այն դարձնում է իդեալական։ tarՏվյալների բազայի որոշակի օբյեկտների խնդիրների լուծում և սպասարկում: Օգտագործեք CHECKTABLE-ը որոշակի աղյուսակների կատարողականության հետ կապված խնդիրներ ուսումնասիրելիս, տվյալների բազայի լրիվ ստուգումների միջև ընկած ժամանակահատվածում կարևորագույն բիզնես աղյուսակները ստուգելիս կամ երբ ժամանակային սահմանափակումները թույլ չեն տալիս տվյալների բազայի լրիվ ստուգում: Այս մոտեցումը հատկապես արժեքավոր է մեծ տվյալների բազաներում, որտեղ CHECKDB-ի լրիվ գործողությունները գերազանցում են առկա սպասարկման պատուհանները:

8.2 DBCC CHECKTABLE շարահյուսություն և օրինակներ

Հիմնական CHECKTABLE հրամանը tarստանում է կոնկրետ աղյուսակներ՝

DBCC CHECKTABLE('YourTable')

Ինչպես CHECKDB-ը, CHECKTABLE-ը նույնպես աջակցում է տարբեր տարբերակներ, այդ թվում՝ NOINDEX-ը՝ կատարողականի օպտիմալացման և վնասների վերացման համար նախատեսված վերականգնման պարամետրերի համար: Կարող եք նաև նշել սխեմաների անուններ՝ աղյուսակների ճշգրիտ նույնականացման համար.

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

այս tarGeted մոտեցումը թույլ է տալիս մանրամասն ստուգել ամբողջականությունը՝ միաժամանակ պահպանելով համակարգի կատարողականը աշխատանքային ժամերի ընթացքում։

8.3 Մեծ տվյալների բազաների արդյունավետության առավելությունները

CHECKTABLE գործողությունները զգալիորեն ավելի արագ են ավարտվում, քան տվյալների բազայի լրիվ ստուգումները, ինչը հնարավորություն է տալիս ավելի հաճախ ստուգել կարևոր աղյուսակների ամբողջականությունը: Այս մոտեցումը թույլ է տալիս ամեն օր ստուգել կարևոր բիզնես աղյուսակները՝ միաժամանակ CHECKDB-ի համապարփակ գործողությունները պահելով շաբաթական կամ ամսական գրաֆիկների համար: Ռեսուրսների սպառման նվազումը CHECKTABLE-ը դարձնում է հարմար արտադրական միջավայրի կատարման համար՝ օգտագործողի վրա նվազագույն ազդեցությամբ:

9. Երբ CHECKDB-ն ձախողվում է

DBCC CHECKDB-ն կձախողվի տարբեր սցենարներում, այդ թվում՝

• DBCC CHECKDB կատարում աննորմալ կերպով ավարտվում է
• DBCC CHECKDB-ի կատարումը հաջողությամբ ավարտվեց, սակայն վերանորոգման տարբերակներ տվյալների բազան վերականգնելու ձախողում։

Այս սցենարներում մեզ անհրաժեշտ է ավելի պրոֆեսիոնալ գործիք, որը կօգնի մեզ շտկել տվյալների բազայի կոռումպացված խնդիրները։

9.1 Ներածություն DataNumen SQL Recovery

DataNumen SQL Recovery ապահովում է ավելի առաջադեմ հնարավորություններ՝

• Վերականգնման լավագույն ցուցանիշը արդյունաբերությունում:
• Վերականգնել խիստ վնասված տվյալների բազայի ֆայլերը։
• Վերականգնել տվյալների բազայի բոլոր օբյեկտները, ներառյալ աղյուսակները, ինդեքսները, դիտումները, ակտիվացուցիչները, կանոնները և լռելյայն արժեքները։
• Վերականգնել պահպանված պրոցեդուրաները, սկալյար ֆունկցիաները, ներդիրային աղյուսակի արժեքով ֆունկցիաները և բազմաստիճան աղյուսակի արժեքով ֆունկցիաները:
• Վերականգնել ընդմիշտ ջնջված գրառումները։
• Գաղտնագրված օբյեկտների վերծանումը SQL Server տվյալների բազաներ:
• MDF ֆայլերի խմբաքանակով վերանորոգում:
• Վերանորոգման համապարփակ տարբերակներ:
• Ընդլայնված գրանցում և հաշվետվություն:
• Աջակցություն բոլորի համար SQL Server տարբերակներ է.
• Տեխնիկական աջակցության առկայությունը
• Պարբերաբար թարմացումներ և բարելավումներ

9.2 Հաջողության մակարդակի համեմատություն

Վերականգնման հաջողության ցուցանիշները զգալիորեն տարբերվում են.

• DBCC CHECKDB և CHECKTABLE: 1.27% վերականգնման միջին մակարդակը
• DataNumen: 92.6% վերականգնման տոկոսադրույքը

Ստորև ներկայացված է ամբողջական մրցակցային համեմատություն.

9.3 Դաժան կոռուպցիայից վերականգնում

Ընդլայնված հնարավորություններ ծանր դեպքերի համար.

• Վերականգնում ֆիզիկապես վնասված պահեստից
• Վերականգնում ձևաչափված սկավառակներից կամ խափանված համակարգերից
• Վերականգնել սկավառակի պատկերներից, պահուստային ֆայլերից, վիրտուալ մեքենայի սկավառակի ֆայլերից, տեմպիցrary ֆայլեր և այլն:

9.4 Ե՞րբ պետք է դիտարկել մասնագիտական ​​լուծումները

• Վերջերս պահուստային պատճեն չկա
• DBCC CHECKDB-ն ձախողվում է
• Լուրջ կոռուպցիոն սցենարներ
• Կարևորագույն բիզնես տվյալների հետ աշխատելը
• Երբ ժամանակը կրիտիկական է
• Երբ առավելագույն վերականգնումն էական է

10. ՀՏՀ

11: եզրափակում

11.1 Հիմնական կետերի ամփոփում

11.1.1 DBCC CHECKDB-ի հիմնական հրամանների ամփոփում

Տիրապետեք DBCC CHECKDB հիմնական սինտաքսին՝ տվյալների բազայի համապարփակ ստուգման համար, օգտագործեք NOINDEX և PHYSICAL_ONLY տարբերակները՝ կատարողականի օպտիմալացման համար, և հասկացեք CHECKTABLE-ը։ tarՍտացված աղյուսակի ստուգում: Այս հիմնարար հրամանները կազմում են տվյալների բազայի կանխարգելիչ պահպանման հիմքը՝ հնարավորություն տալով վաղ հայտնաբերման և ամբողջականության համակարգված մոնիթորինգի:

11.1.2 Կարևորագույն լավագույն փորձի հիշեցում

Միշտ պահպանեք արդիական պահուստային պատճեններ՝ ամբողջականության ստուգումներ կատարելուց առաջ, պլանավորեք CHECKDB-ի կանոնավոր գործողություններ՝ հիմնվելով տվյալների բազայի կարևորության վրա, և իրականացրեք ավտոմատացված մոնիթորինգ՝ անհապաղ կոռուպցիայի մասին ահազանգերի համար: Հիշե՛ք, որ կանոնավոր մոնիթորինգի միջոցով կանխարգելումը գերազանցում է ռեակտիվ մոտեցումները, և մասնագիտական ​​վերականգնման լուծումները ապահովում են արժեքավոր պահուստային պատճենների տարբերակներ, երբ ստանդարտ գործիքները անբավարար են դառնում:

11.2 Ե՞րբ օգտագործել DBCC CHECKDB-ն ընդդեմ Advanced Solutions-ի

Օգտագործեք DBCC CHECKDB-ը ամբողջականության պարբերական մոնիթորինգի և աննշան կոռուպցիայի վերացման համար, միաժամանակ պահպանելով մասնագիտական ​​վերականգնման գործիքներ ներկառուցված վերականգնման հնարավորություններից դուրս գտնվող լուրջ կոռուպցիայի սցենարների համար: Որոշումների կայացման շրջանակը պետք է հաշվի առնի պահուստավորման առկայությունը, տվյալների կարևորությունը, ժամանակային սահմանափակումները և կոռուպցիայի ծանրությունը: Հաջողակ տվյալների բազայի ադմինիստրատորները համատեղում են CHECKDB-ի պարբերական մոնիթորինգը համապարփակ պահուստավորման ռազմավարությունների և վերականգնման առաջադեմ տարբերակների իրազեկության հետ, երբ ստանդարտ մոտեցումները անբավարար են ապացուցվում:

11.3 DBA-ների համար արագ ամենօրյա առողջության ստուգաթերթիկ

DBCC CHECKDB-ը գործարկելուց բացի, պահպանեք տվյալների բազայի օպտիմալ առողջությունը հետևյալ կարևոր ամենօրյա պրակտիկաների միջոցով.

1. Ստուգեք պահուստային պատճենի ամբողջականությունը

• Հաստատեք, որ պլանավորված պահուստավորումները հաջողությամբ ավարտվել են
• Օգտագործեք RESTORE VERIFYONLY-ն՝ պահուստային պատճենի ընթեռնելիությունը ստուգելու համար
• Համոզվեք, որ արտաքին պատճենները համաժամեցված են և հասանելի

Կարող եք նաև լրացուցիչ տեղեկություններ ստանալ այստեղից մեր համապարփակ ուղեցույցը SQL Server կրկնօրնկ.

2. Վերանայեք համապատասխանության կարգավիճակը

• Ստուգեք գիշերային փորձարկումների ավտոմատացված DBCC CHECKDB արդյունքները
• Մոնիտոր SQL Server սխալների գրանցամատյաններ կոռուպցիայի մասին նախազգուշացումների համար
• Անմիջապես հետաքննեք ամբողջականության ցանկացած խախտում

3. Վերահսկել սերվերի առողջությունը

• Ստուգեք պրոցեսորի, հիշողության և սկավառակի մուտքի/ելքի չափանիշները
• Ստուգեք tempdb տարածքի առկայությունը
• Ճանաչեք արգելափակված գործընթացները և երկարատև հարցումները

4. Հետևեք փակուղու ակտիվությանը

• Վերանայեք համակարգի առողջության իրադարձություններից ստացված փակուղու գրաֆիկները
• Խնդրահարույց հարցումների բացահայտում և օպտիմալացում մշակողների թիմերի հետ
• Հետևեք փակուղու զոհերի թվին և բիզնեսի վրա ազդեցությանը

Կարեւոր հիշեցումներ

• Խուսափեք տվյալների բազայի հաճախակի կրճատումից – այն մեծացնում է մասնատվածությունը և վատթարացնում է կատարողականը։ Փոքրացրեք միայն տվյալների մեծ ջնջումներից հետո, երբ իսկապես անհրաժեշտ է։
• Ավտոմատացրեք մոնիթորինգի առաջադրանքները օգտագործելով SQL Server Գործակալի աշխատանքներ կամ սպասարկման պլաններ՝ կարևորագույն խնդիրների մասին ծանուցումներով։
• Փորձարկեք աղետների վերականգնման ընթացակարգերը շաբաթական՝ ապահովելու համար, որ պահուստային պատճենները վերականգնվեն և վերականգնման նպատակները մնան հասանելի։

Այս ամենօրյա ստուգաթերթիկը համատեղելով DBCC CHECKDB-ի կանոնավոր գործողությունների հետ, դուք ստեղծում եք ձեր տվյալների բազայի միջավայրի համապարփակ պաշտպանություն՝ նախաձեռնողական մոնիթորինգի և խնդիրներին արագ արձագանքման միջոցով։

12. Սայլակ

1. Microsoft Learn. «DBCC CHECKDB (Transact-SQL)»: SQL Server փաստաթղթավորումՄայքրոսոֆթ կորպորացիա։
   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-ի կողմից հաղորդված տվյալների բազայի համապատասխանության սխալների լուծում»: SQL Server փաստաթղթավորումՄայքրոսոֆթ կորպորացիա։
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors