कई दिनों में DBCC CHECKDB को विभाजित करना

10

मैं बहुत बड़े डेटाबेस के लिए कई दिनों में मैन्युअल रूप से DBCC CHECKDB को फैलाने के पॉल रान्डल के तरीके को लागू करने पर काम कर रहा हूँ , जिसमें मूल रूप से शामिल हैं:

डेटाबेस में तालिकाओं को विभाजित करते हुए लगभग 7 बाल्टी के बीच समान रूप से
सप्ताह में दो बार DBCC CHECKALLOC चलाना
सप्ताह में एक बार DBCC CHECKCATALOG चलाना
सप्ताह के प्रत्येक दिन एक बाल्टी पर DBCC CHECKTABLE चलाना

क्या किसी ने इस तकनीक का इस्तेमाल किया है? किसी भी मौजूदा स्क्रिप्ट वहाँ?

मुझे लगता है कि यह वास्तव में सब कुछ है कि CHECKDB करता है कवर नहीं कर सकता हूँ; CHECKDB के लिए पुस्तकें ऑनलाइन प्रलेखन का कहना है कि CHECKALLOC, CHECKCATALOG और CHECKTABLE के अलावा, यह भी:

डेटाबेस में हर अनुक्रमित दृश्य की सामग्री को मान्य करता है।
FILESTREAM का उपयोग करते हुए फ़ाइल सिस्टम में varbinary (अधिकतम) डेटा संग्रहीत करते समय तालिका मेटाडेटा और फ़ाइल सिस्टम निर्देशिका और फ़ाइलों के बीच लिंक-स्तरीय स्थिरता को मान्य करता है। (SQL 2008 केवल)
डेटाबेस में सेवा ब्रोकर डेटा को मान्य करता है।

तो यहाँ मेरे सवाल हैं:

क्या ये अतिरिक्त जांच आवश्यक / महत्वपूर्ण हैं? (अनुक्रमित विचार शायद मेरे विषय में थोड़े अधिक हैं, मुझे नहीं लगता कि हम अभी तक सेवा ब्रोकर या फेस्टरेम का उपयोग कर रहे हैं।)
यदि हां, तो क्या इन अतिरिक्त जांचों को अलग से करने के तरीके हैं?
CHECKALLOC और CHECKCATALOG बहुत तेज़ी से चलने लगती हैं, यहाँ तक कि बड़े dbs पर भी। हर दिन इनको न चलाने का कोई कारण?

(नोट: यह सैकड़ों मौजूदा सर्वरों के हजारों सर्वरों के लिए एक मानक दिनचर्या होगी, या कम से कम हर डेटाबेस एक निश्चित आकार से अधिक होगा। इसका मतलब है कि CHECKFILEGROUP का उपयोग करने के लिए सभी डेटाबेसों के पुनर्गठन जैसे विकल्प वास्तव में हमारे लिए व्यावहारिक नहीं हैं।)

sql-server dbcc-checkdb vldb

— BradC
स्रोत

पॉल ने अपने ब्लॉग पर टिप्पणियों में इस सवाल के एक संस्करण का जवाब दिया। उन्होंने कहा, "अनुक्रमित दृश्य सत्यापन के बारे में चिंता न करें। यह 2008 से डिफ़ॉल्ट रूप से बंद है क्योंकि यह समस्या नहीं ढूंढ रहा था।"

— ब्रैड

मैं वही करने के लिए काम कर रहा हूं - कोई सलाह / जो आपको मिली है, क्योंकि आपने पहले ही इसे लागू कर दिया है?

— scsimon

1

@scsimon मुझे यह अच्छी तरह से काम करने के लिए मिला है, मैं संबंधित विशिष्ट रणनीति के लिए इस प्रश्न को देखता हूं जिसका उपयोग मैंने तालिकाओं को विभाजित करने के लिए किया था। मुझे लगता है कि मैंने अंततः पूरे सर्वर पर सभी (बड़े) डेटाबेसों में सभी तालिकाओं की एक मास्टर सूची दैनिक "बकेट" में विभाजित करने के लिए बनाई, जिसने मुझे प्रत्येक डेटाबेस की सूची को व्यक्तिगत रूप से विभाजित करने की तुलना में बहुत अधिक विभाजित किया। छोटे डेटाबेस मैं बस एक पूर्ण DBCC प्रत्येक दिन किया था, और विभाजन का हिस्सा नहीं थे।

— ब्रैडॉक

6

क्या ये अतिरिक्त जांच आवश्यक / महत्वपूर्ण हैं? (अनुक्रमित विचार शायद मेरे विषय में थोड़े अधिक हैं, मुझे नहीं लगता कि हम अभी तक सेवा ब्रोकर या फेस्टरेम का उपयोग कर रहे हैं।)

आप DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKS सीधे अनुक्रमित दृश्यों पर चल सकते हैं । अनुक्रमित दृश्यों की जाँच कुछ परिस्थितियों में समस्याग्रस्त हो सकती है , इसलिए परिणामी किसी भी झूठी सकारात्मक जांच करने के लिए तैयार रहें। (पॉल रान्डल ने संदर्भित लेख की टिप्पणियों में भी उल्लेख किया है कि झूठी नकारात्मकताएं भी संभव हैं, लेकिन मुझे इसका कोई अनुभव नहीं है।)

यदि हां, तो क्या इन अतिरिक्त जांचों को अलग से करने के तरीके हैं?

सर्विस ब्रोकर या FILESTREAMचेक को अलग से चलाने का कोई समर्थन नहीं है, नहीं।

CHECKALLOCऔर CHECKCATALOGबहुत तेज़ी से चलने लगते हैं, यहाँ तक कि बड़े dbs पर भी। हर दिन इनको न चलाने का कोई कारण?

ऐसा नहीं कि मुझे पता नहीं।

आप दौड़ने पर भी विचार कर सकते हैं DBCC CHECKCONSTRAINTS। यह चेक शामिल नहीं है DBCC CHECKDB, चाहे आप किसी भी विकल्प को निर्दिष्ट करें। तुम भी के बारे में सोचना चाहते हो सकता है कभी कभी चल रहा CHECKDB, जब कभी परिस्थितियों की अनुमति है।

— पॉल व्हाइट 9
स्रोत

6

DBCC CHECKDB SQL सर्वर डेटाबेस 100% यकीन है कि कोई भ्रष्टाचार नहीं है के लिए महत्वपूर्ण है । हालाँकि, डेटाबेस के आकार में बड़े पैमाने पर वृद्धि होने के कारण, 24x7 होने का दावा करने पर इसका रखरखाव विंडो ढूंढना बहुत कठिन है। वर्षों से, SQL सर्वर टीम ने विभिन्न तंत्रों को लागू किया है जो विशेष रूप से हार्डवेयर के कारण होने वाले भौतिक भ्रष्टाचार से संबंधित भ्रष्टाचारों के सबसे सामान्य रूपों का पता लगाएगा।

SQL सर्वर 2005 और ऊपर में PAGE_VERIFY = CHECKSUM है जो आपको डेटाबेस पेजों में शारीरिक भ्रष्टाचार का पता लगाने में मदद कर सकता है, जिससे प्रत्येक पृष्ठ पर एक चेकसम जोड़ सकता है क्योंकि यह I / O सिस्टम को लिखा गया है और चेकसम को मान्य करता है क्योंकि यह डिस्क से पढ़ा जाता है।

इसके अलावा, CHECKSUM के साथ बैकअप (पूर्ण या अंतर) हार्डवेयर के कारण किसी भी I / O भ्रष्टाचार का पता लगाने की गारंटी देगा।

इसलिए, भ्रष्टाचार के हार्डवेयर पक्ष से, SQL सर्वर इसका पता लगाने और इसे रिपोर्ट करने का एक अच्छा काम करता है। ( महत्वपूर्ण भ्रष्टाचार से संबंधित अलर्ट भी सेट करना सुनिश्चित करें )।

कहा जा रहा है, अभी भी तार्किक भ्रष्टाचार , स्क्राइब्लर प्रेरित त्रुटियां - जहां इन-मेमरी पेज SQL सर्वर प्रक्रिया के अंदर चल रहे थर्ड-पार्टी कोड या विंडोज कर्नेल मोड और / या SQL सर्वर में निष्पादित पर्याप्त विशेषाधिकार के साथ ड्राइवरों या अन्य सॉफ़्टवेयर द्वारा दूषित हैं। कीड़े , आदि उपर्युक्त विधियों का उपयोग करने में असमर्थ हैं और इसलिए CHECKDB तस्वीर में आता है।

DBCC CHECKDB अधिक गहन जाँच करता है जिसमें संभावित भ्रष्टाचार के लिए पृष्ठ शीर्षकों की जाँच करना शामिल है जो किसी अन्य माध्यम से पता लगाने योग्य नहीं हैं।

किसी भी मौजूदा स्क्रिप्ट वहाँ?

पहिया को फिर से मजबूत करने के बजाय, मैं आपको ओला के एसक्यूएल सर्वर इंटीग्रिटी चेक सॉल्यूशन पर एक नज़र डालने की अत्यधिक सलाह दूंगा

कुशलतापूर्वक DBCC CHECKDB चल रहा है:

जब आप CHECKDB को चलाने के लिए विशाल डेटाबेस या डेटाबेस की उच्च संख्या वाले रखरखाव विंडो में तंग हैं, तो आपको बस रचनात्मक होने की आवश्यकता है।

SQLSkills प्रशिक्षण में भाग लेने के बाद, मैंने अपने परिवेश में जो लागू किया है वह है:

जाँच करने के लिए कौन सी तालिकाएँ महत्वपूर्ण हैं, इस पर प्राथमिकता दें।
अलग-अलग प्राथमिकताओं वाले समूहों में तालिकाओं को अलग करें और फिर दौड़ने DBCC CHECKTABLEके साथ चलाएं DBCC CHECKALLOCऔरDBCC CHECKCATALOG
एक कार्यकर्ता तालिका बनाएं जो प्राथमिकताओं के साथ तालिका नामों को संग्रहीत करेगी। बस यह सुनिश्चित कर लें कि सभी उच्च प्राथमिकता वाले टेबल (जो बड़े पैमाने पर बड़े हैं) एक समूह में नहीं हैं और आपका CHECKDB बिल्कुल भी पूरा नहीं होगा।
आप अपनी वर्कर टेबल में एक टाइमआउट कॉलम भी रख सकते हैं, जो रखरखाव खिड़की से गुजरने के बाद आपके CHECKDB को मार देगा।
जोड़ने के लिए प्रति तालिका में कितना समय लगा DBCC CHECKTABLE, DBCC CHECKALLOCऔर DBCC CHECKCATALOG। ताकि आप यह महसूस कर सकें कि आपके चेक को चलाने के लिए आमतौर पर कितना समय लगता है ।
आप NOINDEXविकल्प के साथ भी चल सकते हैं क्योंकि यह ऑपरेशन को गति देगा क्योंकि यह उपयोगकर्ता तालिकाओं पर गैर-क्लस्टर इंडेक्स की जांच नहीं करता है। इसका कुछ लाभ है क्योंकि यह महत्वपूर्ण नहीं है क्योंकि डेटा भ्रष्टाचार के रूप में महत्वपूर्ण है क्योंकि कोई डेटा नहीं खोता है और यदि आवश्यक हो तो आप सूचकांक को छोड़ और फिर से बना सकते हैं।

जाहिर है, एंटरप्राइज़ संस्करण DBCC स्टेटमेंट के समानांतर निष्पादन का लाभ उठा सकता है, लेकिन MAXDOP सेटिंग के लिए देखें क्योंकि यह आपके सभी CPU को समाप्त कर सकता है। यह संसाधन राज्यपाल द्वारा सीमित किया जा सकता है।

नोट: यदि आपके पास स्पार्स कॉलम है, तो आपका CHECKDB यहाँ बताए अनुसार धीमा हो जाएगा ।

अंत में, यह डेटाबेस उपलब्ध भ्रष्टाचार को रोकने के लिए कैसे सभी उपलब्ध उपकरण सेट का उपयोग करके + अपने डेटाबेस सर्वर हार्डवेयर सिस्टम में आपके विश्वास और सबसे महत्वपूर्ण रूप से आपके डेटा का मूल्य।

कुछ उत्कृष्ट संदर्भ:

— परिजन शाह
स्रोत