DBCC CHECKDB: راهنمای کامل بیماری ام اس SQL Server سلامت پایگاه داده (۲۰۲۵)

فساد پایگاه داده هر چیزی است SQL Server کابوس مدیران. وقتی داده‌های حیاتی کسب‌وکار غیرقابل دسترس یا غیرقابل اعتماد می‌شوند، ...ost می‌تواند ویرانگر باشد. این راهنمای جامع، هر آنچه را که باید در مورد استفاده از DBCC CHECKDB برای حفظ سلامت پایگاه داده و جلوگیری از خرابی بدانید، به علاوه راه‌حل‌های پیشرفته بازیابی برای زمانی که ابزارهای استاندارد کافی نیستند، پوشش می‌دهد.

1. اهمیت از SQL Server سلامت پایگاه داده

۱.۱ چه چیزی باعث خرابی پایگاه داده می‌شود؟ Costکسب و کارها

امروز، مost کسب‌وکارها داده‌های حیاتی خود را در پایگاه‌های داده ذخیره می‌کنند. وقتی خرابی پایگاه داده رخ می‌دهد، عواقب فاجعه‌باری دارد:

• زیان های مالی به طور متوسط ​​سالانه 2.3 میلیون دلار به دلیل از دست دادن داده‌ها، که خرابی سخت‌افزار و خرابی از دلایل اصلی آن هستند (شرکت EMC)
• نرخ تعطیلی کسب و کارها نشان می‌دهد که ۵۰٪ از کسب‌وکارهای کوچکی که به دلیل خرابی سخت‌افزاری، داده‌های خود را از دست می‌دهند، ظرف دو سال از کار می‌افتند، در حالی که ۹۴٪ از کسب‌وکارهایی که داده‌های خود را به طور فاجعه‌باری از دست می‌دهند، اصلاً دوام نمی‌آورند.
• فراوانی خرابی داده‌ها سالانه 20٪ از برنامه‌های کاربردی حیاتی را تحت تأثیر قرار می‌دهد و باعث اختلال در تداوم کسب‌وکار می‌شود (تحقیقات گارتنر)
• فساد مربوط به سخت‌افزار ۶۷٪ از کل حوادث از دست رفتن داده‌ها از طریق خرابی هارد دیسک و خرابی سیستم رخ می‌دهد، که ۴۰٪ از این موارد مستقیماً به نقص سخت‌افزاری نسبت داده می‌شود.
• فساد نرم‌افزاری جosts بسته به شدت و دامنه، از هزاران تا میلیون‌ها دلار متغیر است، به طوری که ۸۲٪ از مشاغل، قطعی‌های برنامه‌ریزی نشده‌ای را تجربه کرده‌اند که فساد عامل اصلی آن بوده است.

۱.۲ چرا بررسی‌های منظم سلامت حیاتی هستند

افراد برای تشخیص زودهنگام بیماری‌های احتمالی به معاینات منظم پزشکی نیاز دارند. به طور مشابه، پایگاه‌های داده نیز به معاینات منظم پزشکی نیاز دارند:

1. فساد بالقوه را زود تشخیص داده و به سرعت با آن برخورد کنید و از شدت گرفتن و گسترده شدن مشکلات که می‌تواند منجر به عواقب فاجعه‌بار برای کسب‌وکار شود، جلوگیری کنید.
2. اطمینان حاصل کنید که پایگاه داده با عملکرد بهینه کار می‌کند.
3. cost بررسی‌های پیشگیرانه‌ی سلامت پایگاه داده بسیار کمتر از بازیابی واکنشی داده‌ها پس از وقوع فاجعه در پایگاه داده است.

۱.۳ مقدمه‌ای بر دستورات یکپارچگی پایگاه داده

SQL Server چندین دستور داخلی برای حفظ سلامت پایگاه داده ارائه می‌دهد، با DBCC CHECKDB خدمت به عنوان مost ابزار جامع بررسی یکپارچگی موجود است. این دستورات با هم کار می‌کنند تا جنبه‌های مختلف ساختار پایگاه داده شما، از جداول جداگانه گرفته تا کل پایگاه داده، را تأیید کنند و یک استراتژی نگهداری کامل را تشکیل دهند که داده‌های شما را ایمن و در دسترس نگه می‌دارد.

۲. DBCC CHECKDB چیست؟

DBCC CHECKDB is SQL Serverابزار اصلی برای تأیید صحت پایگاه داده و شناسایی مشکلات مربوط به خرابی.

• این یک دستور T-SQL است، نه یک ابزار GUI.
• شما می‌توانید آن را از طریق روش‌های رایج، مانند SQL Server استودیوی مدیریت (SSMS)، SQL Server عامل، SQLCMD و غیره

۲.۱ CHECKDB در واقع چه چیزی را در پایگاه داده شما بررسی می‌کند

وقتی DBCC CHECKDB را اجرا می‌کنید، این دستور چندین لایه اعتبارسنجی را در ساختار پایگاه داده شما انجام می‌دهد:

• تأیید چک‌سام‌های صفحه برای تشخیص خرابی فیزیکی و مشکلات مربوط به سخت‌افزار
• اعتبارسنجی سازگاری شاخص برای اطمینان از بازیابی مناسب داده‌ها و عملکرد صحیح پرس‌وجو
• بررسی ساختار تخصیص برای تأیید استفاده دقیق از فضا و تخصیص صفحه
• بررسی یکپارچگی ارجاعی بین جداول مرتبط و روابط کلید خارجی
• اعتبارسنجی سازگاری جدول سیستم to ensure,en SQL Serverفراداده‌های داخلی همچنان قابل اعتماد هستند
• تأیید پیوند صفحه داده برای تأیید یکپارچگی مناسب زنجیره صفحه
• سازگاری طرحواره پایگاه داده برای اعتبارسنجی تعاریف و وابستگی‌های شیء

این بررسی‌های جامع، هم داده‌های کاربر و هم ساختارهای سیستم را پوشش می‌دهند و دید کاملی از وضعیت سلامت پایگاه داده شما ارائه می‌دهند.

۳. اجرای DBCC CHECKDB: گام به گام

3.1 پیش نیازها

در زیر چک لیست قبل از اجرای هرگونه عملیات DBCC CHECKDB آمده است:

• پشتیبان‌گیری کامل از پایگاه داده – قبل از اجرای بررسی‌های یکپارچگی، یک نسخه پشتیبان کامل ایجاد کنید تا در صورت کشف خرابی یا نیاز به عملیات تعمیر، شبکه ایمنی شما برقرار باشد.
• مجوزهای مناسب برای اجرای دستورات DBCC CHECKDB به مجوزهای sysadmin یا db_owner نیاز دارید.
• منابع سیستم کافی:
  • حافظه: ۲۵٪ از حجم پایگاه داده
  • فضای Tempdb: 10-15٪ از حجم پایگاه داده
  • پردازنده: ۵۰ تا ۷۰ درصد در طول مدت نگهداری در دسترس است
  • ورودی/خروجی: انتظار عملیات خواندن سنگین را داشته باشید
• دسترسی به پایگاه داده – تأیید کنید که پایگاه داده شما قابل دسترسی است و در حالت محدود شده قرار ندارد، زیرا CHECKDB نیاز به دسترسی خواندن به تمام صفحات پایگاه داده دارد.

3.2 فرمان پایه

مترost دستور پایه DBCC CHECKDB شامل سه تغییر رایج است:

(1) پایگاه داده فعلی را بررسی کنید (بدون پارامتر):

DBCC CHECKDB

(2) بررسی یک پایگاه داده بر اساس نام:

DBCC CHECKDB ('YourDatabaseName')

(3) بررسی یک پایگاه داده بر اساس شناسه:

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

این دستور اساسی، بررسی کامل یکپارچگی پایگاه داده مشخص شده را انجام می‌دهد و تمام جداول، ایندکس‌ها و ساختارهای سیستم را بررسی می‌کند. برای پایگاه‌های داده با نام‌های استاندارد بدون فاصله، می‌توانید علامت نقل قول را حذف کنید. این دستور تا زمان تکمیل اجرا می‌شود و پیام‌های پیشرفت و نتایج نهایی را نمایش می‌دهد. این سینتکس اساسی برای پایگاه‌های داده کوچک‌تر یا زمانی که زمان نگهداری کافی دارید، کاملاً مناسب است.

در زیر تصویری از اجرای DBCC CHECKDB در ... مشاهده می‌کنید. SQL Server استودیوی مدیریت (SSMS):

۳.۳ گزینه‌های کامل

در زیر گزینه‌های کامل برای 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	همه خطاها را نشان می‌دهد (پیش‌فرض: ۲۰۰ برای هر شیء)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	پیام‌های اطلاعاتی را پنهان می‌کند	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
عملکرد	TABLOCK	از قفل‌های جدول استفاده می‌کند (استفاده از TempDB را کاهش می‌دهد اما نوشتن را مسدود می‌کند)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	تنظیمات موازی‌سازی را لغو می‌کند	DBCC CHECKDB ('MyDB', MAXDOP = 2)
سودمندی	ESTIMATEONLY	فضای مورد نیاز TempDB را تخمین می‌زند. (بدون بررسی واقعی)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

۴. درک نتایج شما

دستور DBCC CHECKDB بسته به اینکه اجرای آن با موفقیت انجام شود یا خیر، نتایج متفاوتی تولید خواهد کرد. بیایید آنها را با جزئیات توضیح دهیم.

۴.۱ اجرای CHECKDB با موفقیت انجام شد

اگر اجرای DBCC CHECKDB با موفقیت انجام شود، بسته به وضعیت سلامت پایگاه داده شما، انواع مختلفی از نتایج را گزارش خواهد کرد.

۴.۱.۱ هیچ مشکلی یافت نشد

اگر 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.

این نتیجه نشان می‌دهد که پایگاه داده شما در تمام ساختارهای بررسی شده، یکپارچگی کاملی را حفظ می‌کند.

۴.۱.۲ خطاهای خرابی یافت‌شده

هر زمان که DBCC CHECKDB خطای خرابی را تشخیص دهد، یک پیام خطا با ساختار زیر گزارش می‌دهد:
راهنمای سطح شدت:

• سطح 16-19: خطاهای قابل اصلاح توسط کاربر، اغلب خرابی جزئی
• سطح 20-24: خطاهای سیستم، خرابی‌های جدی که نیاز به توجه فوری دارند
• سطح 25: خطاهای مهلک، ممکن است پایگاه داده غیرقابل دسترس باشد

خطاهای رایج عبارتند از:

• خطاهای بررسی صفحه (پیام ۸۲۴)
• خطاهای تخصیص (پیام ۸۹۲۸)
• مشکلات سازگاری فهرست (پیام ۸۹۶۴)

درک ساختار پیام به اولویت‌بندی اقدامات واکنشی و تعیین استراتژی‌های بازیابی مناسب کمک می‌کند.

۴.۱.۳ پیام‌های اطلاعاتی و هشدار رایج

همه خروجی‌های 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'.

۴.۲ لغو اجرای CHECKDB

اگر CHECKDB در حین اجرا به دلایل مختلف متوقف شود، یک پیام خطا گزارش می‌دهد و یک گزارش خطا با کد وضعیت زیر اضافه می‌کند:

دولت	توضیحات:
0	خطای شماره ۸۹۳۰ رخ داده است. این نشان دهنده خرابی در فراداده است که دستور DBCC را خاتمه داده است.
1	خطای شماره ۸۹۶۷ رخ داده است. یک خطای 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 برای رفع مشکل خرابی در پایگاه داده شما.

۵. رفع خطاهای خرابی

۵.۱ پشتیبان‌گیری و بازیابی: امن‌ترین راه‌حل

وقتی DBCC CHECKDB خطاهای خرابی را شناسایی می‌کند، بازیابی از یک نسخه پشتیبان تمیز، امن‌ترین و مطمئن‌ترین روش است.ost راه حل قابل اعتماد. این رویکرد ضمن از بین بردن علل اصلی خرابی، یکپارچگی داده‌ها را تضمین می‌کند. قبل از بازیابی، یکپارچگی نسخه پشتیبان را با استفاده از بازیابی VERIFYONLY دستورات را بررسی کنید و گزینه‌های بازیابی در هر لحظه را برای به حداقل رساندن از دست دادن داده‌ها در نظر بگیرید. جزئیات خرابی را برای تجزیه و تحلیل علت اصلی مستند کنید، زیرا مشکلات سخت‌افزاری یا اشکالات نرم‌افزاری ممکن است نیاز به توجه بیشتری برای جلوگیری از تکرار داشته باشند.

۵.۲ راهکارهای رفع خرابی در سطح صفحه

برای خرابی صفحات جداگانه که بخش‌های کوچکی از داده‌ها را تحت تأثیر قرار می‌دهد، SQL Server نسخه سازمانی قابلیت‌های بازیابی صفحه را ارائه می‌دهد که صفحات آسیب‌دیده خاص را بدون بازیابی کامل پایگاه داده تعمیر می‌کند. این تکنیک پیشرفته نیاز به مدل بازیابی کامل و پشتیبان‌گیری از گزارش‌های فعلی دارد.

مراحل بازیابی صفحه گام به گام:

1. شناسایی صفحه خراب از پیام خطای CHECKDB (مثلاً صفحه ۱:۲۵۶)
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

۵.۳ رفع سریع خرابی ایندکس

فساد ایندکس اغلب به خوبی به عملیات بازسازی که ساختارهای ایندکس را بدون تأثیر بر داده‌های جدول اصلی بازسازی می‌کنند، پاسخ می‌دهد:

ALTER INDEX ALL ON YourTable REBUILD

این رویکرد به ویژه برای خرابی ایندکس‌های غیرخوشه‌ای خوب عمل می‌کند، زیرا بازسازی، صفحات ایندکس را از داده‌های جدول منبع بازسازی می‌کند و به طور مؤثر خرابی را از بین می‌برد و در عین حال تمام اطلاعات اصلی را حفظ می‌کند.

۶. از REPAIR_REBUILD و REPAIR_ALLOW_DATA_LOSS استفاده کنید

اگر روش‌های قبلی همگی با شکست مواجه شدند یا امکان‌پذیر نبودند، می‌توانید از گزینه‌های REPAIR_REBUILD و REPAIR_ALLOW_DATA_LOSS برای تعمیر پایگاه داده استفاده کنید.

۶.۱ REPAIR_REBUILD (گزینه امن‌تر):

• استفاده برای: فساد ایندکس و خطاهای جزئی تخصیص
• ایمنی داده ها: تلاش برای رفع مشکلات امنیتی بدون حذف داده‌ها
• سطح ریسک: کم - انتظار نمی‌رود داده‌ها از بین بروند
• سناریوهای معمول: خرابی ایندکس غیرخوشه‌ای، مشکلات جزئی در متادیتا
• مثال دستور: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

۶.۲ REPAIR_ALLOW_DATA_LOSS (آخرین راه حل):

• استفاده برای: خرابی شدید در صورت عدم دسترسی به نسخه‌های پشتیبان
• ایمنی داده ها: ممکن است داده‌های خراب را برای بازیابی عملکرد پایگاه داده حذف کند
• سطح ریسک: زیاد - احتمال از دست دادن دائمی داده‌ها
• سناریوهای معمول: خرابی صفحه، آسیب به جدول سیستم، خطاهای زنجیره تخصیص
• مثال دستور: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

۶.۳ بهترین شیوه‌ها برای این گزینه‌ها:

• همیشه تست کنید عملیات تعمیر روی کپی‌های پایگاه داده در صورت امکان
• همیشه پشتیبان بگیرید قبل از اجرای این گزینه‌ها
• مستندسازی تمام تغییرات برای اهداف انطباق و عیب‌یابی
• پایگاه داده را روی حالت تک کاربره تنظیم کنید قبل از اجرای عملیات تعمیر

قاعدتاً باید تلاش کنیم تعمیر_بازسازی گزینه اول. اگر شکست خورد، امتحان کنید repain_owl_data_loss گزینه.

۶.۴ نتایج REPAIR_ALLOW_DATA_LOSS

۶.۴.۱ تعمیر با از دست دادن داده‌ها موفقیت‌آمیز است

بعضی اوقات repain_owl_data_loss گزینه موفقیت‌آمیز خواهد بود، اما برخی از داده‌ها ناقص هستند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 نسخه	فایل ام دی اف خراب	فایل ام دی اف توسط DataNumen SQL Recovery
SQL Server 2014	Error10_1.mdf (پیامک ۸۹۰۹ و به دنبال آن پیامک ۸۹۳۹) (۶۰۰ رکورد lost با REPAIR_ALLOW_DATA_LOSS)	Error10_1_fixed.mdf (رکوردی ثبت نشده است)ost)
SQL Server 2014	Error10_2.mdf (پیامک ۸۹۰۹ و به دنبال آن پیامک ۸۹۳۹) (۶۰۰۰ رکورد (۵۰٪) lost با REPAIR_ALLOW_DATA_LOSS)	Error10_2_fixed.mdf (فقط ۱۰۰ رکورد lost)
SQL Server 2014	خطای7ام دی اف (100 رکورد lost با REPAIR_ALLOW_DATA_LOSS)	error7_fixed.mdf (فقط یک رکورد lost)

۶.۴.۲ شکست در تعمیر – راهکار حرفه‌ای را در نظر بگیرید

If repain_owl_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 نسخه	فایل ام دی اف خراب	فایل ام دی اف توسط DataNumen SQL Recovery
SQL Server 2014	Error1_3.mdf (پیامک تکی ۸۲۴)	Error1_3_fixed.mdf
SQL Server 2014	Error1_1.mdf (خطاهای مداوم پیام ۸۲۴)	خطای 1_1_fixed.mdf
SQL Server 2014	Error1_2.mdf ((پیامک ۸۲۴ و به دنبال آن پیامک ۷۹۰۹))	Error1_2_fixed.mdf
SQL Server 2014	Error4_1.mdf (پیامک ۸۹۹۲ و به دنبال آن پیامک ۳۸۵۲)	Error4_1_fixed.mdf
SQL Server 2014	Error4_2.mdf (پیامک ۸۹۹۲ و به دنبال آن پیامک ۳۸۵۲)	Error4_2_fixed.mdf
SQL Server 2014	error5.mdf (پیامک ۸۹۴۵)	error5_fixed.mdf
SQL Server 2014	error6.mdf (پیامک ۸۹۴۵)	error6_fixed.mdf
SQL Server 2014	error2.mdf (پیامک ۸۹۴۵)	error2_fixed.mdf
SQL Server 2014	error11.mdf (پیامک ۸۹۴۵)	error11_fixed.mdf
SQL Server 2014	error3.mdf (پیامک ۸۹۴۵)	error3_fixed.mdf
SQL Server 2014	خطای8ام دی اف (پیامک ۸۹۴۵)	خطای8_fixed.mdf
SQL Server 2014	error9.mdf (پیامک ۸۹۴۵)	error9_fixed.mdf

7. بهترین شیوه ها

۶.۱ زمان‌بندی عملیات منظم CHECKDB

اجرای هفتگی DBCC CHECKDB را برای پایگاه‌های داده حیاتی عملیاتی، به همراه بررسی‌های روزانه برای سیستم‌های با تراکنش بالا، پیاده‌سازی کنید. عملیات را در دوره‌های کم‌مصرف برنامه‌ریزی کنید تا تأثیر بر عملکرد به حداقل برسد و چرخش بین بررسی‌های کامل و گزینه‌های PHYSICAL_ONLY را بر اساس اندازه پایگاه داده و پنجره‌های نگهداری در نظر بگیرید. برنامه‌ریزی خودکار از طریق SQL Server عامل، اجرای مداوم را تضمین می‌کند و در عین حال قابلیت‌های نظارت و هشدار متمرکز را ارائه می‌دهد.

۶.۲ مدیریت تأثیر عملکرد

عملیات DBCC CHECKDB منابع سیستم قابل توجهی را مصرف می‌کنند که به طور بالقوه بر فعالیت همزمان کاربر تأثیر می‌گذارد. در طول بررسی‌ها، میزان استفاده از CPU، مصرف حافظه و ورودی/خروجی دیسک را رصد کنید تا الگوهای تأثیر بر عملکرد را درک کنید. استفاده از گزینه‌های NOINDEX را برای بررسی‌های معمول در نظر بگیرید و اعتبارسنجی کامل را برای پنجره‌های نگهداری ماهانه رزرو کنید. افزونه‌های زمان‌بندی پرس‌وجو و استراتژی‌های ارتباط با کاربر را برای مدیریت انتظارات در طول دوره‌های بررسی یکپارچگی پیاده‌سازی کنید.

۶.۳ برنامه‌ریزی دوره نگهداری

برنامه‌ریزی DBCC CHECKDB را با سایر فعالیت‌های نگهداری مانند عملیات پشتیبان‌گیری، بازسازی شاخص‌ها و به‌روزرسانی‌های آمار هماهنگ کنید. از همپوشانی عملیات فشرده‌سازی منابع که می‌تواند باعث کاهش عملکرد یا مشکلات وقفه زمانی شود، خودداری کنید. دوره‌های نگهداری را بر اساس پیش‌بینی‌های رشد اندازه پایگاه داده برنامه‌ریزی کنید و با افزایش حجم داده‌ها، زمان کافی برای تأیید کامل یکپارچگی را تضمین کنید.

۶.۴ نظارت و هشدار خودکار

مجموعه SQL Server هشدارهای عامل برای اطلاع‌رسانی فوری به مدیران در صورت شناسایی فساد توسط DBCC CHECKDB. پیاده‌سازی راهکارهای تجزیه لاگ که نتایج بررسی یکپارچگی را استخراج و دسته‌بندی می‌کنند و امکان تجزیه و تحلیل روند و شناسایی پیشگیرانه مشکل را فراهم می‌کنند. ایجاد رویه‌های تشدید که بازه‌های زمانی پاسخ و پرسنل مسئول را برای سطوح مختلف شدت فساد تعریف می‌کنند.

۷. جدول بررسی DBCC: جایگزین سبک

۷.۱ چه زمانی باید از CHECKTABLE به جای CHECKDB استفاده کنیم

DBCC CHECKTABLE بررسی متمرکز یکپارچگی را برای جداول منفرد فراهم می‌کند و آن را برای موارد زیر ایده‌آل می‌سازد: tarعیب‌یابی و نگهداری اشیاء خاص پایگاه داده را دریافت کرد. از CHECKTABLE هنگام بررسی مشکلات عملکرد با جداول خاص، اعتبارسنجی جداول تجاری حیاتی بین بررسی‌های کامل پایگاه داده یا زمانی که محدودیت‌های زمانی مانع از اعتبارسنجی کامل پایگاه داده می‌شود، استفاده کنید. این رویکرد به ویژه در پایگاه‌های داده بزرگ که عملیات کامل CHECKDB از بازه‌های زمانی نگهداری موجود فراتر می‌رود، ارزشمند است.

۷.۲ سینتکس و مثال‌های DBCC CHECKTABLE

دستور پایه CHECKTABLE tarجداول خاصی را دریافت می‌کند:

DBCC CHECKTABLE('YourTable')

مانند CHECKDB، CHECKTABLE از گزینه‌های مختلفی از جمله NOINDEX برای بهینه‌سازی عملکرد و پارامترهای تعمیر برای رفع خرابی پشتیبانی می‌کند. همچنین می‌توانید نام‌های طرحواره را برای شناسایی دقیق جدول مشخص کنید:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

این tarرویکرد get امکان تأیید صحت جزئیات را فراهم می‌کند و در عین حال عملکرد سیستم را در ساعات کاری حفظ می‌کند.

۷.۳ مزایای عملکرد برای پایگاه‌های داده بزرگ

عملیات CHECKTABLE به طور قابل توجهی سریع‌تر از بررسی‌های کامل پایگاه داده انجام می‌شود و امکان تأیید صحت جداول حیاتی را به طور مکرر فراهم می‌کند. این رویکرد امکان اعتبارسنجی روزانه جداول ضروری کسب و کار را فراهم می‌کند و در عین حال عملیات جامع CHECKDB را برای برنامه‌های هفتگی یا ماهانه رزرو می‌کند. کاهش مصرف منابع، CHECKTABLE را برای اجرای محیط تولید با حداقل تأثیر بر کاربر مناسب می‌سازد.

۸. وقتی CHECKDB با شکست مواجه می‌شود

DBCC CHECKDB در سناریوهای مختلف از جمله موارد زیر با شکست مواجه می‌شود:

• اجرای DBCC CHECKDB به طور غیرطبیعی خاتمه می‌یابد
• اجرای DBCC CHECKDB با موفقیت به پایان می‌رسد، اما گزینه های تعمیر عدم موفقیت در تعمیر پایگاه داده.

در این سناریوها، به یک ابزار حرفه‌ای‌تر نیاز داریم تا به ما در رفع خرابی‌های پایگاه داده کمک کند.

9.1 مقدمه ای بر DataNumen SQL Recovery

DataNumen SQL Recovery قابلیت‌های پیشرفته‌تری را ارائه می‌دهد:

• بهترین نرخ بازیابی در صنعت
• بازیابی فایل‌های پایگاه داده به شدت آسیب دیده.
• بازیابی تمام اشیاء پایگاه داده، شامل جداول، ایندکس‌ها، نماها، تریگرها، قوانین و پیش‌فرض‌ها.
• رویه های ذخیره شده، توابع اسکالر، توابع با مقدار جدول درون خطی، و توابع با ارزش جدول چند حالتی را بازیابی کنید.
• بازیابی رکوردهای حذف شده دائمی
• رمزگشایی اشیاء رمزگذاری شده در SQL Server پایگاه های داده
• تعمیر فایل‌های MDF به صورت دسته‌ای.
• گزینه های تعمیر جامع
• ثبت و گزارش پیشرفته.
• حمایت از همه SQL Server نسخه ها
• در دسترس بودن پشتیبانی فنی
• به روز رسانی و بهبودهای منظم

۸.۲ مقایسه میزان موفقیت

نرخ موفقیت بازیابی به طور قابل توجهی متفاوت است:

• بررسی DBCC و جدول بررسی: ٪۱۰۰ میانگین نرخ بازیابی
• DataNumen: ٪۱۰۰ نرخ بازیابی

در زیر یک مقایسه کامل رقابتی وجود دارد:

9.3 بازیابی از فساد شدید

قابلیت های پیشرفته برای موارد شدید:

• بازیابی از ذخیره سازی آسیب دیده فیزیکی
• بازیابی از درایوهای فرمت شده یا سیستم های خراب
• بازیابی از تصاویر دیسک، فایل های پشتیبان، فایل های دیسک ماشین مجازی، سرعتrarفایل های y و غیره

۸.۵ چه زمانی باید راهکارهای حرفه‌ای را در نظر گرفت

• نسخه پشتیبان اخیر در دسترس نیست
• خطای DBCC CHECKDB
• سناریوهای شدید فساد
• برخورد با داده‌های حیاتی کسب و کار
• زمانی که زمان حیاتی است
• زمانی که حداکثر بازیابی ضروری است

10. سQالات متداول

11. نتیجه

11.1 خلاصه نکات کلیدی

۹.۱.۱ خلاصه دستورات ضروری DBCC CHECKDB

تسلط بر سینتکس پایه DBCC CHECKDB برای بررسی جامع پایگاه داده، استفاده از گزینه‌های NOINDEX و PHYSICAL_ONLY برای بهینه‌سازی عملکرد، و درک CHECKTABLE برای tarتأیید جدول دریافت شده. این دستورات اساسی، پایه و اساس نگهداری پیشگیرانه پایگاه داده را تشکیل می‌دهند و امکان تشخیص زودهنگام خرابی و نظارت سیستماتیک بر یکپارچگی را فراهم می‌کنند.

۹.۱.۲ یادآوری بهترین شیوه‌های حیاتی

همیشه قبل از اجرای بررسی‌های یکپارچگی، از نسخه‌های پشتیبان فعلی خود نسخه پشتیبان تهیه کنید، عملیات منظم CHECKDB را بر اساس میزان حساسیت پایگاه داده برنامه‌ریزی کنید و نظارت خودکار را برای هشدارهای فوری خرابی پیاده‌سازی کنید. به یاد داشته باشید که پیشگیری از طریق نظارت منظم، از رویکردهای واکنشی پیشی می‌گیرد و راه‌حل‌های بازیابی حرفه‌ای، گزینه‌های پشتیبان‌گیری ارزشمندی را در صورت ناکافی بودن ابزارهای استاندارد ارائه می‌دهند.

۹.۲ چه زمانی از DBCC CHECKDB در مقابل راهکارهای پیشرفته استفاده کنیم

از DBCC CHECKDB برای نظارت روتین بر یکپارچگی و رفع خرابی‌های جزئی استفاده کنید، در حالی که ابزارهای بازیابی حرفه‌ای را برای سناریوهای خرابی شدید فراتر از قابلیت‌های تعمیر داخلی در نظر بگیرید. چارچوب تصمیم‌گیری باید در دسترس بودن نسخه پشتیبان، حساسیت داده‌ها، محدودیت‌های زمانی و شدت خرابی را در نظر بگیرد. مدیران موفق پایگاه داده، نظارت منظم CHECKDB را با استراتژی‌های جامع پشتیبان‌گیری و آگاهی از گزینه‌های پیشرفته بازیابی در زمانی که رویکردهای استاندارد ناکافی باشند، ترکیب می‌کنند.

12. منابع

1. آموزش مایکروسافت. «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. آموزش مایکروسافت. «عیب‌یابی خطاهای مربوط به سازگاری پایگاه داده که توسط DBCC CHECKDB گزارش می‌شوند.» SQL Server مستنداتشرکت مایکروسافت.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors