DBCC CHECKDB: გაფანტული სკლეროზის სრული სახელმძღვანელო 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 ჩანაწერიost REPAIR_ALLOW_DATA_LOSS-ით)	Error10_1_fixed.mdf (ჩანაწერი არ არის ლost)
SQL Server 2014	შეცდომა10_2.mdf (წერილი 8909, რასაც მოჰყვება წერილი 8939) (6000 ჩანაწერი (50%) lost REPAIR_ALLOW_DATA_LOSS-ით)	Error10_2_fixed.mdf (მხოლოდ 100 ჩანაწერი ლost)
SQL Server 2014	შეცდომა 7.მდფ (100 ჩანაწერი ლost REPAIR_ALLOW_DATA_LOSS-ით)	Error7_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)	Error1_3_fixed.mdf
SQL Server 2014	შეცდომა1_1.mdf (განმეორებითი MSG 824 შეცდომები)	შეცდომა 1_1_გასწორდა.mdf
SQL Server 2014	შეცდომა1_2.mdf ((წერილი 824, რასაც მოჰყვება წერილი 7909)	Error1_2_fixed.mdf
SQL Server 2014	შეცდომა4_1.mdf (წერილი 8992, რასაც მოჰყვება წერილი 3852)	Error4_1_fixed.mdf
SQL Server 2014	შეცდომა4_2.mdf (წერილი 8992, რასაც მოჰყვება წერილი 3852)	Error4_2_fixed.mdf
SQL Server 2014	შეცდომა5.mdf (შეტყობინება 8945)	Error5_fixed.mdf
SQL Server 2014	შეცდომა6.mdf (შეტყობინება 2510)	Error6_fixed.mdf
SQL Server 2014	შეცდომა2.mdf (შეტყობინება 2575)	Error2_fixed.mdf
SQL Server 2014	შეცდომა11.mdf (შეტყობინება 8905)	Error11_fixed.mdf
SQL Server 2014	შეცდომა3.mdf (შეტყობინება 5028)	Error3_fixed.mdf
SQL Server 2014	შეცდომა 8.მდფ (შეტყობინება 5125)	შეცდომა 8_გასწორდა.mdf
SQL Server 2014	შეცდომა9.mdf (შეტყობინება 3313)	Error9_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)

ეს tarგეტირებული მიდგომა საშუალებას იძლევა დეტალური მთლიანობის გადამოწმებისა და სისტემის მუშაობის შენარჩუნების პარალელურად სამუშაო საათებში.

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. სერვერის ჯანმრთელობის მონიტორინგი

• შეამოწმეთ CPU-ს, მეხსიერების და დისკის შეყვანის/გამოყვანის მეტრიკა
• გადაამოწმეთ tempdb სივრცის ხელმისაწვდომობა
• დაბლოკილი პროცესების და ხანგრძლივი მუშაობის მოთხოვნების იდენტიფიცირება

4. ჩიხში შესული აქტივობის თვალყურის დევნება

• სისტემის ჯანმრთელობის მოვლენებიდან ჩიხის გრაფიკების მიმოხილვა
• პრობლემური შეკითხვების იდენტიფიცირება და დეველოპერების გუნდებთან ერთად ოპტიმიზაცია
• ჩიხში შესული მსხვერპლის რაოდენობისა და ბიზნესზე ზემოქმედების მონიტორინგი

მნიშვნელოვანი შეხსენებები

• მოერიდეთ მონაცემთა ბაზის ხშირ შემცირებას – ეს ზრდის ფრაგმენტაციას და აუარესებს მუშაობას. შეამცირეთ მხოლოდ მონაცემების მნიშვნელოვანი წაშლის შემდეგ, როდესაც ეს ნამდვილად აუცილებელია.
• მონიტორინგის ამოცანების ავტომატიზაცია გამოყენების SQL Server აგენტის დავალებები ან ტექნიკური მომსახურების გეგმები კრიტიკული პრობლემების შესახებ გაფრთხილებებით.
• კატასტროფის აღდგენის პროცედურების ტესტირება ყოველკვირეულად, რათა უზრუნველყოფილი იყოს სარეზერვო ასლების აღდგენა და აღდგენის მიზნების მიღწევა.

ამ ყოველდღიური საკონტროლო სიის DBCC CHECKDB-ის რეგულარულ ოპერაციებთან შერწყმით, თქვენ ქმნით თქვენი მონაცემთა ბაზის გარემოს ყოვლისმომცველ დაცვას პროაქტიული მონიტორინგისა და პრობლემებზე სწრაფი რეაგირების გზით.

12. ლიტერატურა

1. Microsoft Learn. „DBCC CHECKDB (Transact-SQL).“ SQL Server დოკუმენტაციაMicrosoft Corporation.
   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 დოკუმენტაციაMicrosoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors