DBCC CHECKDB: MS کے لیے مکمل گائیڈ SQL Server ڈیٹا بیس ہیلتھ (2025)

ڈیٹا بیس کی کرپشن ہر ہے۔ SQL Server منتظم کا ڈراؤنا خواب جب اہم کاروباری ڈیٹا ناقابل رسائی یا ناقابل اعتماد ہو جاتا ہے، cost تباہ کن ہو سکتا ہے. یہ جامع گائیڈ ہر اس چیز کا احاطہ کرتا ہے جو آپ کو ڈیٹا بیس کی صحت کو برقرار رکھنے اور بدعنوانی کو روکنے کے لیے DBCC CHECKDB استعمال کرنے کے بارے میں جاننے کے لیے درکار ہے، نیز جب معیاری ٹولز کافی نہ ہوں تو اس کے لیے جدید ترین ریکوری حل۔

1 کی اہمیت SQL Server ڈیٹا بیس ہیلتھ

1.1 ڈیٹا بیس میں کیا بدعنوانی Costs کاروبار

آج، ایمost کاروبار اپنے اہم ڈیٹا کو ڈیٹا بیس میں محفوظ کرتے ہیں۔ جب ڈیٹا بیس میں بدعنوانی ہوتی ہے تو اس کے نتائج تباہ کن ہوتے ہیں:

• مالی نقصان ڈیٹا کے نقصان کی وجہ سے اوسطاً $2.3 ملین سالانہ، جس میں ہارڈ ویئر کی ناکامی اور بدعنوانی بنیادی وجوہات ہیں (EMC کارپوریشن)
• کاروبار بند ہونے کی شرح ظاہر کریں کہ ہارڈ ویئر کی ناکامی کی وجہ سے ڈیٹا کے نقصان کا سامنا کرنے والے 50% چھوٹے کاروبار دو سال کے اندر کاروبار سے باہر ہو جاتے ہیں، جب کہ تباہ کن ڈیٹا کے نقصان کے ساتھ 94% کاروبار بالکل بھی زندہ نہیں رہتے۔
• ڈیٹا کرپشن فریکوئنسی سالانہ 20% مشن کے لیے اہم ایپلی کیشنز کو متاثر کرتا ہے، جس سے کاروبار کے تسلسل میں خلل پڑتا ہے (گارٹنر ریسرچ)
• ہارڈ ویئر سے متعلق بدعنوانی ہارڈ ڈرائیو کے کریشز اور سسٹم کی ناکامیوں کے ذریعے ڈیٹا کے ضائع ہونے کے تمام واقعات میں سے 67% کا حصہ ہے، جس میں 40% ڈیٹا کا نقصان براہ راست ہارڈ ویئر کی خرابیوں سے ہوتا ہے۔
• سافٹ ویئر بدعنوانی costs شدت اور دائرہ کار کے لحاظ سے ہزاروں سے ملین ڈالر تک کی حد، 82% کاروبار غیر منصوبہ بند بندش کا سامنا کر رہے ہیں جہاں بدعنوانی ایک اہم وجہ تھی۔

1.2 صحت کی باقاعدہ جانچ کیوں ضروری ہے۔

ممکنہ بیماریوں کا جلد پتہ لگانے کے لیے لوگوں کو باقاعدہ صحت کے چیک اپ کی ضرورت ہوتی ہے۔ اسی طرح، ڈیٹا بیس کو بھی باقاعدگی سے صحت کی جانچ کی ضرورت ہے:

1. ممکنہ بدعنوانی کا جلد پتہ لگائیں اور اسے فوری طور پر ہینڈل کریں، مسائل کو شدید اور وسیع ہونے سے روکیں، جو کاروبار کے لیے تباہ کن نتائج کا باعث بن سکتے ہیں۔
2. یقینی بنائیں کہ ڈیٹا بیس بہترین کارکردگی پر کام کرتا ہے۔
3. سیost ڈیٹا بیس کی تباہی کے بعد فعال ڈیٹا بیس کی صحت کی جانچ کی ری ایکٹو ڈیٹا ریکوری کے مقابلے بہت کم ہے۔

1.3 ڈیٹا بیس انٹیگریٹی کمانڈز کا تعارف

SQL Server ڈیٹا بیس کی صحت کو برقرار رکھنے کے لیے کئی بلٹ ان کمانڈز فراہم کرتا ہے۔ ڈی بی سی سی چیک ڈی بی۔ ایم کے طور پر خدمت کر رہا ہےost جامع سالمیت کی جانچ کا آلہ دستیاب ہے۔ یہ کمانڈز آپ کے ڈیٹا بیس کی ساخت کے مختلف پہلوؤں کی توثیق کرنے کے لیے مل کر کام کرتی ہیں، انفرادی جدولوں سے لے کر پورے ڈیٹا بیس کی مستقل مزاجی تک، ایک مکمل دیکھ بھال کی حکمت عملی تشکیل دیتی ہے جو آپ کے ڈیٹا کو محفوظ اور قابل رسائی رکھتی ہے۔

2. DBCC CHECKDB کیا ہے؟

ڈی بی سی سی چیک ڈی بی۔ is SQL Serverڈیٹا بیس کی سالمیت کی تصدیق اور بدعنوانی کے مسائل کی نشاندہی کرنے کا بنیادی ٹول۔

• یہ ایک T-SQL بیان ہے، GUI ٹول نہیں۔
• آپ اسے عام طریقوں سے انجام دے سکتے ہیں، جیسے SQL Server مینجمنٹ اسٹوڈیو (SSMS)، SQL Server ایجنٹ، SQLCMD، وغیرہ۔

2.1 آپ کے ڈیٹا بیس میں CHECKDB دراصل کیا چیک کرتا ہے۔

جب آپ DBCC CHECKDB چلاتے ہیں، تو کمانڈ آپ کے ڈیٹا بیس کے ڈھانچے میں متعدد توثیق کی تہوں کو انجام دیتی ہے:

• صفحہ چیکسم کی تصدیق جسمانی بدعنوانی اور ہارڈ ویئر سے متعلق مسائل کا پتہ لگانے کے لیے
• انڈیکس مستقل مزاجی کی توثیق مناسب ڈیٹا کی بازیافت اور استفسار کی کارکردگی کو یقینی بنانے کے لیے
• مختص کی ساخت کی جانچ پڑتال درست جگہ کے استعمال اور صفحہ مختص کی تصدیق کرنے کے لیے
• حوالہ جاتی سالمیت کا امتحان متعلقہ جدولوں اور غیر ملکی کلیدی تعلقات کے درمیان
• سسٹم ٹیبل کی مستقل مزاجی کی توثیق یقینی بنانے کے لئے SQL Serverکا اندرونی میٹا ڈیٹا قابل اعتماد رہتا ہے۔
• ڈیٹا پیج لنکیج کی تصدیق صفحہ چین کی صحیح سالمیت کی تصدیق کرنے کے لیے
• ڈیٹا بیس اسکیما کی مستقل مزاجی آبجیکٹ کی تعریف اور انحصار کی توثیق کرنے کے لیے

یہ جامع جانچیں صارف کے ڈیٹا اور سسٹم ڈھانچے دونوں کا احاطہ کرتی ہیں، جو آپ کے ڈیٹا بیس کی صحت کی حالت میں مکمل مرئیت فراہم کرتی ہیں۔

3. DBCC CHECKDB چلانا: مرحلہ وار

3.1 ضروریات

کسی بھی DBCC CHECKDB آپریشن کو انجام دینے سے پہلے ذیل میں چیک لسٹ ہے:

• مکمل ڈیٹا بیس بیک اپ - اگر بدعنوانی کا پتہ چلتا ہے یا مرمت کے کام ضروری ہو جاتے ہیں تو اپنے حفاظتی جال کے طور پر سالمیت کی جانچ کو چلانے سے پہلے ایک مکمل بیک اپ بنائیں۔
• مناسب اجازتیں۔ - آپ کو DBCC CHECKDB کمانڈز کو انجام دینے کے لیے sysadmin یا db_owner کی اجازت کی ضرورت ہے
• کافی سسٹم وسائل:
  • میموری: ڈیٹا بیس کے سائز کا 25%
  • Tempdb جگہ: ڈیٹا بیس کے سائز کا 10-15%
  • CPU: دیکھ بھال کے دوران 50-70% دستیابی۔
  • I/O: بھاری پڑھنے والے آپریشنز کی توقع کریں۔
• ڈیٹا بیس کی رسائی - تصدیق کریں کہ آپ کا ڈیٹا بیس قابل رسائی ہے اور محدود حالت میں نہیں ہے، کیونکہ 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)
کارکردگی	TABLOCK	ٹیبل لاک استعمال کرتا ہے (ٹیمپ ڈی بی کے استعمال کو کم کرتا ہے لیکن بلاکس لکھتا ہے)	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،XNUMX: صارف کی طرف سے درست ہونے والی غلطیاں، اکثر معمولی بدعنوانی
• سطح 20-24،XNUMX: سسٹم کی خرابیاں، سنگین کرپشن جس پر فوری توجہ کی ضرورت ہے۔
• سطح 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 بدعنوانی کی غلطیوں کی نشاندہی کرتا ہے، تو صاف بیک اپ سے بحال کرنا سب سے محفوظ اور m کی نمائندگی کرتا ہے۔ost قابل اعتماد حل. یہ نقطہ نظر بدعنوانی کی بنیادی وجوہات کو ختم کرتے ہوئے ڈیٹا کی سالمیت کی ضمانت دیتا ہے۔ بحال کرنے سے پہلے، استعمال کرتے ہوئے بیک اپ کی سالمیت کی تصدیق کریں۔ تصدیق شدہ طور پر بحال کریں۔ کمانڈز، اور ڈیٹا کے نقصان کو کم سے کم کرنے کے لیے پوائنٹ ان ٹائم ریکوری کے اختیارات پر غور کریں۔ بنیادی وجہ کے تجزیہ کے لیے بدعنوانی کی تفصیلات کو دستاویز کریں، کیونکہ ہارڈ ویئر کے مسائل یا سافٹ ویئر کی خرابیوں کو دوبارہ ہونے سے روکنے کے لیے اضافی توجہ کی ضرورت پڑ سکتی ہے۔

5.2 صفحہ کی سطح پر بدعنوانی کے حل

الگ تھلگ صفحہ کی بدعنوانی کے لیے جو ڈیٹا کے چھوٹے حصوں کو متاثر کرتا ہے، SQL Server انٹرپرائز ایڈیشن صفحہ کی بحالی کی صلاحیتیں پیش کرتا ہے جو مکمل ڈیٹا بیس کی بحالی کے بغیر مخصوص خراب شدہ صفحات کی مرمت کرتی ہے۔ اس جدید تکنیک کے لیے مکمل ریکوری ماڈل اور موجودہ لاگ بیک اپ کی ضرورت ہے۔

مرحلہ وار صفحہ کی بحالی کا عمل:

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_REBUILD سب سے پہلے اختیار. اگر یہ ناکام ہو جائے تو پھر کوشش کریں۔ مرمت_اللہ_ ڈیٹا_لوس۔ آپشن.

6.4 REPAIR_ALLOW_DATA_LOSS نتائج

6.4.1 ڈیٹا کے نقصان کے ساتھ مرمت کامیاب

کبھی کبھی مرمت_اللہ_ ڈیٹا_لوس۔ آپشن کامیاب ہو جائے گا، لیکن کچھ ڈیٹا 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 کچھ خراب شدہ ریکارڈز کو چھوڑ کر ڈیٹا بیس کو ٹھیک کرتا ہے، لیکن اصل میں، most ان میں سے اب بھی کے ذریعے برآمد کیا جا سکتا ہے 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 (کوئی ریکارڈ نہیں lost)
SQL Server 2014	نقص 10_2.mdf (پیغام 8909 اس کے بعد میسج 8939) (6000 ریکارڈ (50%) lost REPAIR_ALLOW_DATA_LOSS کے ساتھ)	نقص 10_2_fixed.mdf (صرف 100 ریکارڈ ایلost)
SQL Server 2014	نقص 7ایم ڈی ایف (100 ریکارڈز ایلost REPAIR_ALLOW_DATA_LOSS کے ساتھ)	نقص 7_fixed.mdf (صرف ایک ریکارڈ ایلost)

6.4.2 مرمت ناکام ہو جاتی ہے - پیشہ ورانہ حل پر غور کریں۔

If مرمت_اللہ_ ڈیٹا_لوس۔ ناکام ہوجاتا ہے، یہ ایک یا ایک سے زیادہ خرابی کے پیغامات کو آؤٹ پٹ کرے گا۔

ذیل میں کچھ مثالیں ہیں:

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_fixed.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	نقص 8ایم ڈی ایف (پیغام 5125)	نقص 8_fixed.mdf
SQL Server 2014	نقص 9.mdf (پیغام 3313)	نقص 9_fixed.mdf

7. بہترین طرز عمل

7.1 باقاعدہ چیک ڈی بی آپریشنز کا شیڈولنگ

اہم پروڈکشن ڈیٹا بیسز کے لیے ہفتہ وار DBCC CHECKDB عمل درآمد کریں، جس میں ہائی ٹرانزیکشن سسٹمز کے لیے روزانہ کی جانچ پڑتال کی جاتی ہے۔ کارکردگی کے اثرات کو کم سے کم کرنے کے لیے کم استعمال کے ادوار کے دوران آپریشنز کا شیڈول بنائیں، اور ڈیٹا بیس کے سائز اور مینٹیننس ونڈوز کی بنیاد پر مکمل چیک اور PHYSICAL_ONLY آپشنز کے درمیان گھومنے پر غور کریں۔ خودکار شیڈولنگ کے ذریعے SQL Server ایجنٹ مرکزی نگرانی اور الرٹ کرنے کی صلاحیتیں فراہم کرتے ہوئے مسلسل عملدرآمد کو یقینی بناتا ہے۔

7.2 کارکردگی کے اثرات کا انتظام

DBCC CHECKDB آپریشنز اہم نظام کے وسائل استعمال کرتے ہیں، ممکنہ طور پر ہم وقت صارف کی سرگرمی کو متاثر کرتے ہیں۔ کارکردگی کے اثرات کے نمونوں کو سمجھنے کے لیے جانچ کے دوران CPU کے استعمال، میموری کی کھپت، اور ڈسک I/O کی نگرانی کریں۔ معمول کی جانچ کے لیے NOINDEX کے اختیارات استعمال کرنے پر غور کریں، ماہانہ مینٹیننس ونڈوز کے لیے مکمل توثیق محفوظ رکھیں۔ سالمیت کی جانچ کی مدت کے دوران توقعات کا انتظام کرنے کے لیے استفسار کے ٹائم آؤٹ ایکسٹینشنز اور صارف کے رابطے کی حکمت عملیوں کو نافذ کریں۔

7.3 مینٹیننس ونڈو پلاننگ

DBCC CHECKDB شیڈولنگ کو دیگر بحالی کی سرگرمیوں جیسے بیک اپ آپریشنز، انڈیکس ری بلڈنگ، اور شماریات کی تازہ کاری کے ساتھ مربوط کریں۔ اوور لیپنگ وسائل سے متعلق کاموں سے گریز کریں جو کارکردگی میں کمی یا ٹائم آؤٹ کے مسائل کا سبب بن سکتے ہیں۔ ڈیٹا بیس کے سائز میں اضافے کے تخمینوں پر مبنی مینٹیننس ونڈوز کی منصوبہ بندی کریں، ڈیٹا کے حجم میں اضافے کے ساتھ مکمل سالمیت کی تصدیق کے لیے مناسب وقت کو یقینی بنائیں۔

7.4 خودکار نگرانی اور انتباہ

سیٹ کریں SQL Server جب DBCC CHECKDB بدعنوانی کی نشاندہی کرتا ہے تو ایجنٹ منتظمین کو فوری طور پر مطلع کرنے کے لیے الرٹ کرتا ہے۔ لاگ پارسنگ کے حل کو لاگو کریں جو سالمیت کی جانچ کے نتائج کو نکالتے ہیں اور ان کی درجہ بندی کرتے ہیں، رجحان تجزیہ اور فعال مسئلہ کی شناخت کو فعال کرتے ہیں۔ بدعنوانی کی شدت کی مختلف سطحوں کے لیے جوابی ٹائم فریم اور ذمہ دار اہلکاروں کی وضاحت کرنے والے بڑھنے کے طریقہ کار بنائیں۔

8. ڈی بی سی سی چیک ٹیبل: ہلکا پھلکا متبادل

8.1 CHECKDB کے بجائے CHECKTABLE کب استعمال کریں۔

ڈی بی سی سی چیک ٹیبل انفرادی ٹیبلز کے لیے فوکسڈ انٹیگریٹی چیکنگ فراہم کرتا ہے، جو اسے مثالی بناتا ہے۔ tarمخصوص ڈیٹا بیس اشیاء کی خرابیوں کا سراغ لگانا اور دیکھ بھال حاصل کی۔ مخصوص جدولوں کے ساتھ کارکردگی کے مسائل کی چھان بین کرتے وقت، مکمل ڈیٹا بیس کی جانچ پڑتال کے درمیان اہم کاروباری جدولوں کی توثیق کرتے وقت، یا جب وقت کی پابندیاں مکمل ڈیٹا بیس کی توثیق کو روکتی ہیں تو CHECKTABLE استعمال کریں۔ یہ نقطہ نظر بڑے ڈیٹا بیس میں خاص طور پر قابل قدر ثابت ہوتا ہے جہاں مکمل CHECKDB آپریشن دستیاب مینٹیننس ونڈوز سے زیادہ ہوتے ہیں۔

8.2 DBCC چیک ٹیبل نحو اور مثالیں۔

بنیادی چیک ٹیبل کمانڈ tarمخصوص میزیں حاصل کرتا ہے:

DBCC CHECKTABLE('YourTable')

CHECKDB کی طرح، CHECKTABLE مختلف اختیارات کو سپورٹ کرتا ہے بشمول NOINDEX کارکردگی کو بہتر بنانے اور بدعنوانی کے حل کے لیے مرمت کے پیرامیٹرز۔ آپ ٹیبل کی درست شناخت کے لیے اسکیما کے نام بھی بتا سکتے ہیں:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

یہ tarحاصل شدہ نقطہ نظر کاروباری اوقات کے دوران سسٹم کی کارکردگی کو برقرار رکھتے ہوئے دانے دار سالمیت کی تصدیق کی اجازت دیتا ہے۔

8.3 بڑے ڈیٹا بیس کے لیے کارکردگی کے فوائد

چیک ٹیبل آپریشن مکمل ڈیٹا بیس کی جانچ کے مقابلے میں نمایاں طور پر تیزی سے مکمل ہوتے ہیں، جس سے اہم جدولوں کی زیادہ کثرت سے سالمیت کی تصدیق ہوتی ہے۔ یہ نقطہ نظر ہفتہ وار یا ماہانہ شیڈولز کے لیے جامع CHECKDB آپریشنز کو محفوظ کرتے ہوئے ضروری کاروباری جدولوں کی روزانہ توثیق کی اجازت دیتا ہے۔ کم وسائل کی کھپت صارف کے کم سے کم اثر کے ساتھ پیداواری ماحول پر عمل درآمد کے لیے چیک ٹیبل کو موزوں بناتی ہے۔

9. جب CHECKDB ناکام ہوجاتا ہے۔

DBCC CHECKDB مختلف منظرناموں میں ناکام ہو جائے گا، بشمول:

• DBCC CHECKDB پر عمل درآمد غیر معمولی طور پر ختم ہو جاتا ہے
• DBCC CHECKDB کا عمل کامیابی سے مکمل ہوتا ہے، لیکن مرمت کے اختیارات ڈیٹا بیس کی مرمت کرنے میں ناکام۔

ان حالات میں، ہمیں ڈیٹا بیس میں موجود بدعنوانیوں کو ٹھیک کرنے میں مدد کرنے کے لیے ایک زیادہ پیشہ ور ٹول کی ضرورت ہے۔

9.1 کا تعارف DataNumen SQL Recovery

DataNumen SQL Recovery مزید جدید صلاحیتیں فراہم کرتا ہے:

• بحالی کی بہترین شرح صنعت میں.
• شدید خراب ڈیٹا بیس فائلوں کو بازیافت کریں۔
• تمام ڈیٹابیس اشیاء کو بازیافت کریں، بشمول ٹیبلز، انڈیکسز، ویوز، ٹرگرز، رولز، اور ڈیفالٹس۔
• ذخیرہ شدہ طریقہ کار، اسکیلر فنکشنز، ان لائن ٹیبل ویلیو فنکشنز، اور ملٹی اسٹیٹمنٹ ٹیبل ویلیو فنکشنز کو بازیافت کریں۔
• مستقل طور پر حذف شدہ ریکارڈز کو بازیافت کریں۔
• میں خفیہ کردہ اشیاء کو ڈکرپٹ کریں۔ SQL Server ڈیٹا بیس.
• بیچ میں MDF فائلوں کی مرمت کریں۔
• جامع مرمت کے اختیارات۔
• اعلی درجے کی لاگنگ اور رپورٹنگ۔
• سب کے لئے حمایت SQL Server ورژن.
• تکنیکی مدد کی دستیابی
• باقاعدہ اپ ڈیٹ اور بہتری

9.2 کامیابی کی شرح کا موازنہ

بحالی کی کامیابی کی شرح نمایاں طور پر مختلف ہے:

• ڈی بی سی سی چیک ڈی بی اور چیک ٹیبل: 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 بمقابلہ ایڈوانسڈ سلوشنز کب استعمال کریں۔

معمول کی سالمیت کی نگرانی اور معمولی بدعنوانی کے حل کے لیے 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