निम्नलिखित उन परिणामों का संकलन है जिन्हें मैंने पढ़ा है। लिंक किए गए ब्लॉग और दस्तावेजों में आपको बहुत अधिक जानकारी मिलेगी।
सबसे पहले, यह हो सकता है कि DBCC CHECKDBअगर आप चेकसम या टर्न_पेज सत्यापन बंद करते हैं तो विसंगतियों का पता नहीं चलेगा। इस पोस्ट में पॉल रैंडल का एक उद्धरण :
आप सही हैं - यदि फटे-पृष्ठ या चेकसम चालू नहीं हैं, तो ऐसा कुछ भी नहीं है, जिसका पता लगाया जा सके, जहां तक पृष्ठ संरक्षण विकल्पों का सवाल है। CHECKDB अभी भी उन भ्रष्टाचारों को उठा सकता है, जो यह करता है कि वह जो भी करता है - सभी स्थिरता जांच करने से पाता है - लेकिन यह उदाहरण के लिए, डेटा मानों के बीच में भ्रष्टाचार नहीं देखेगा।
हा - यह पृष्ठ चेकसमों को चालू करने के बारे में बमर है - जब तक एक पृष्ठ में पढ़ा नहीं जाता है, तब तक कुछ नहीं होता है, और वापस लिखा जाता है। चेकसम को प्राप्त करने के लिए पृष्ठों को बाध्य करने का एकमात्र तरीका उन्हें बदलना है - जैसे कि आपके सभी अनुक्रमों के पुनर्निर्माण के माध्यम से, जो अनछुए हो सकते हैं - वहाँ कोई 'स्पर्श' उपकरण नहीं है।
यदि आप SQL Server 2000 या 2005 से पहले या बाद के डेटाबेस को अपग्रेड करते हैं, तो उपरोक्त स्थिति आपको प्रभावित कर सकती है। फिर आपको उन्हें सक्रिय करने के लिए ALTER DATABASE के साथ पेज चेकसम को मैन्युअल रूप से सक्षम करने की आवश्यकता है। लेकिन फिर उपरोक्त उद्धरण का दूसरा पैराग्राफ आपको परेशान करता है और आपको परेशान कर सकता है।
BACKUP WITH CHECKSUMचेकसम विसंगतियों का पता लगाएगा, लेकिन केवल तभी जब पेज में पहले से ही एक चेकसम लिखा हो, जब उसका बैकअप लिया जा रहा हो। आम तौर पर DBCC CHECKDBइन त्रुटियों का भी पता लगाता है, इसलिए DBCC CHECKDB को बदलने के लिए CHECKSUM के साथ BACKUP का उपयोग करना अच्छा नहीं है ।
अब DBCC CHECKDBकोई असंगति न दिखाने की दूसरी संभावना है , भले ही कुछ हों। इसके लिए मैं पॉल रैन्डल को भ्रांतियों के चारों ओर गलतफहमी में फिर से उद्धृत कर रहा हूं : क्या वे गायब हो सकते हैं? :
तो लुप्त हो रहे भ्रष्टाचारों का क्या? यह इस बात पर निर्भर करता है कि स्थिरता जांच कैसे काम करती है। संगणना जाँच केवल उन डेटाबेस के पन्नों पर चलती है जिन्हें आवंटित किया गया है। यदि किसी पृष्ठ को कुछ भी आवंटित नहीं किया जाता है, तो इसके 8192 बाइट अर्थहीन हैं और इसकी व्याख्या नहीं की जा सकती है। आरक्षित और आबंटित के बीच भ्रमित न हों - मैं समझाता हूँ कि यहाँ पहले गलत धारणाएँ हैं। जब तक किसी पृष्ठ को आवंटित किया जाता है, तब तक DBCC CHECKDB द्वारा जाँच की जाती है, यदि यह मौजूद है, तो पृष्ठ चेकसम का परीक्षण करना भी शामिल है। यदि एक DBCC CHECKDB रन के समय एक भ्रष्ट पृष्ठ आवंटित किया जाता है, तो एक भ्रष्टाचार गायब हो सकता है, लेकिन अगले DBCC CHECKDB रन के समय तक इसे हटा दिया जाता है। पहली बार इसे भ्रष्ट के रूप में रिपोर्ट किया जाएगा, लेकिन दूसरी बार इसे आवंटित नहीं किया गया है, इसलिए यह निरंतरता की जाँच नहीं है और इसे भ्रष्ट नहीं बताया जाएगा। भ्रष्टाचार ऐसा लगता है जैसे यह रहस्यमय तरीके से गायब हो गया है। लेकिन यह नहीं है - यह सिर्फ इतना है कि भ्रष्ट पृष्ठ अब आवंटित नहीं किया गया है। SQL सर्वर को दूषित पृष्ठ से हटाते हुए कुछ भी नहीं है - वास्तव में, यह है कि DBCC CHECKDB मरम्मत में से कई - क्या टूटी हुई है, और सभी लिंक को ठीक करें।
मेरे पास आपके प्रश्न का अंतिम उत्तर नहीं है, लेकिन DBCC CHECKDBकेवल आवंटित पृष्ठों की जांच के रूप में यह अस्वीकृत पृष्ठों में असंगतता नहीं दिखाएगा। एकमात्र स्थिति जिसकी मैं अभी कल्पना कर सकता हूं, वह यह है कि BACKUP उन चेकडॉलेटेड पृष्ठों का भी बैकअप लेता है, जो संभावित चेकसम त्रुटियों को दिखाते हैं, जिन्हें छोड़ दिया गया था DBCC CHECKDB।