DBCC CHECKDB के प्रभाव को कम करना:क्या करें और क्या न करें

डीबीए (या <यहां भूमिका डालें>) के रूप में आपकी जिम्मेदारियों में शायद प्रदर्शन ट्यूनिंग, क्षमता योजना और आपदा वसूली जैसी चीजें शामिल हैं। बहुत से लोग जो भूल जाते हैं या टाल देते हैं, वह है उनके डेटाबेस की संरचना (तार्किक और भौतिक दोनों) की अखंडता सुनिश्चित करना; सबसे महत्वपूर्ण कदम है DBCC CHECKDB . आप "डेटाबेस अखंडता कार्य जांचें" के साथ एक साधारण रखरखाव योजना बनाकर वहां भाग ले सकते हैं - हालांकि, मेरे दिमाग में, यह सिर्फ एक चेकबॉक्स की जांच कर रहा है।

यदि आप करीब से देखते हैं, तो कार्य कैसे संचालित होता है इसे नियंत्रित करने के लिए आप बहुत कम कर सकते हैं। यहां तक ​​​​कि काफी विस्तृत गुण पैनल रखरखाव उपयोजना के लिए बहुत सारी सेटिंग्स को उजागर करता है, लेकिन वस्तुतः DBCC के बारे में कुछ भी नहीं है। आदेश यह चलाएगा। व्यक्तिगत रूप से मुझे लगता है कि आपको अपना CHECKDB प्रदर्शन करने के तरीके के बारे में अधिक सक्रिय और नियंत्रित दृष्टिकोण अपनाना चाहिए। उत्पादन वातावरण में संचालन, अपने स्वयं के रोजगार सृजित करके और अपने DBCC . को मैन्युअल रूप से हस्त-निर्मित करके आदेश। आप अपने शेड्यूल या कमांड को अलग-अलग डेटाबेस के लिए तैयार कर सकते हैं - उदाहरण के लिए ASP.NET सदस्यता डेटाबेस शायद आपके बिक्री डेटाबेस जितना महत्वपूर्ण नहीं है, और कम बार-बार और/या कम गहन जांच को सहन कर सकता है।

लेकिन आपके महत्वपूर्ण डेटाबेस के लिए, मैंने सोचा था कि मैं कुछ चीजों का विवरण देने के लिए एक पोस्ट डालूंगा, ताकि मैं व्यवधान को कम कर सकूं DBCC आदेशों का कारण हो सकता है - और आपको किन मिथकों और मार्केटिंग हुपला से सावधान रहना चाहिए। और मैं पॉल "मिस्टर डीबीसीसी" रान्डल (@PaulRandal) को धन्यवाद देना चाहता हूं कि उन्होंने न केवल इस विशिष्ट पोस्ट के लिए, बल्कि अपने ब्लॉग #sqlhelp और SQLskills विसर्जन प्रशिक्षण में उनके द्वारा प्रदान की जाने वाली अंतहीन सलाह को मूल्यवान इनपुट प्रदान किया।

कृपया इन सभी विचारों को नमक के दाने के साथ लें, और अपने वातावरण में पर्याप्त परीक्षण करने की पूरी कोशिश करें - ये सभी सुझाव सभी वातावरणों में बेहतर प्रदर्शन नहीं देंगे। लेकिन कम से कम अपने CHECKDB के प्रभाव पर विचार करने के लिए आप अपने, अपने उपयोगकर्ताओं और अपने हितधारकों के लिए ऋणी हैं संचालन हो सकता है, और जहां संभव हो उन प्रभावों को कम करने के लिए कदम उठाएं - सही चीजों की जांच न करके अनावश्यक जोखिम शुरू किए बिना।

शोर को कम करें और सभी त्रुटियों को दूर करें

कोई फर्क नहीं पड़ता कि आप कहां चल रहे हैं CHECKDB , हमेशा WITH NO_INFOMSGS . का उपयोग करें विकल्प। यह बस सभी अप्रासंगिक आउटपुट को दबा देता है जो आपको बताता है कि प्रत्येक तालिका में कितनी पंक्तियां हैं; यदि आप उस जानकारी में रुचि रखते हैं, तो आप इसे DMVs के विरुद्ध सरल प्रश्नों से प्राप्त कर सकते हैं, न कि DBCC के दौरान चल रहा है। आउटपुट को दबाने से यह बहुत कम संभावना है कि आप उस सभी सुखद आउटपुट में दफन एक महत्वपूर्ण संदेश को याद करेंगे।

इसी तरह, आपको हमेशा WITH ALL_ERRORMSGS का उपयोग करना चाहिए विकल्प, लेकिन विशेष रूप से यदि आप SQL Server 2008 RTM या SQL Server 2005 चला रहे हैं (उन मामलों में, आप प्रति-ऑब्जेक्ट त्रुटियों की सूची को 200 तक काट कर देख सकते हैं)। किसी भी CHECKDB . के लिए त्वरित तदर्थ जांच के अलावा अन्य संचालन, आपको आउटपुट को फ़ाइल में निर्देशित करने पर विचार करना चाहिए। प्रबंधन स्टूडियो DBCC CHECKDB . से आउटपुट की 1000 पंक्तियों तक सीमित है , इसलिए यदि आप इस आंकड़े को पार करते हैं तो आप कुछ त्रुटियों से चूक सकते हैं।

जबकि सख्ती से एक प्रदर्शन समस्या नहीं है, इन विकल्पों का उपयोग करने से आपको प्रक्रिया को फिर से चलाने से रोका जा सकेगा। यह विशेष रूप से महत्वपूर्ण है यदि आप आपदा वसूली के बीच में हैं।

जहां संभव हो तार्किक जांचों को ऑफलोड करें

ज्यादातर मामलों में, CHECKDB अपना अधिकांश समय डेटा की तार्किक जाँच करने में व्यतीत करता है। अगर आपके पास सच्ची कॉपी . पर ये जांच करने की क्षमता है डेटा का, आप अपने प्रयासों को अपने उत्पादन प्रणालियों की भौतिक संरचना पर केंद्रित कर सकते हैं, और सभी तार्किक जाँचों को संभालने के लिए द्वितीयक सर्वर का उपयोग कर सकते हैं और उस लोड को प्राथमिक से कम कर सकते हैं। सेकेंडरी सर्वर . द्वारा , मेरा मतलब केवल निम्नलिखित से है:

• वह स्थान जहां आप अपने पूर्ण पुनर्स्थापना का परीक्षण करते हैं - क्योंकि आप अपने पुनर्स्थापना का परीक्षण करते हैं, है ना?

अन्य लोगों (सबसे विशेष रूप से बीहमोथ मार्केटिंग फोर्स जो कि माइक्रोसॉफ्ट है) ने आपको आश्वस्त किया होगा कि सेकेंडरी सर्वर के अन्य रूप DBCC के लिए उपयुक्त हैं। चेक उदाहरण के लिए:

• एक हमेशा उपलब्ध उपलब्धता समूह पठनीय माध्यमिक;
• प्रतिबिंबित डेटाबेस का एक स्नैपशॉट;
• एक लॉग शिप किया गया सेकेंडरी;
• सैन मिररिंग;
• या अन्य विविधताएं...

दुर्भाग्य से, यह मामला नहीं है, और इनमें से कोई भी सेकेंडरी प्राथमिक के विकल्प के रूप में आपकी जांच करने के लिए मान्य, विश्वसनीय स्थान नहीं है। केवल एक के लिए एक बैकअप ही सच्ची प्रति के रूप में काम कर सकता है; कुछ और जो चीजों पर निर्भर करता है जैसे कि एक सुसंगत स्थिति में लाने के लिए लॉग बैकअप के अनुप्रयोग प्राथमिक पर अखंडता समस्याओं को मज़बूती से प्रतिबिंबित नहीं करने वाला है।

इसलिए अपनी तार्किक जाँचों को एक माध्यमिक में उतारने की कोशिश करने के बजाय और उन्हें प्राथमिक पर कभी भी निष्पादित न करें, यहाँ मेरा सुझाव है:

1. सुनिश्चित करें कि आप अपने पूर्ण बैकअप की पुनर्स्थापना का बार-बार परीक्षण कर रहे हैं। और नहीं, इसमें COPY_ONLY शामिल नहीं है एजी सेकेंडरी से बैकअप, ऊपर के समान कारणों के लिए - यह केवल उस मामले में मान्य होगा जहां आपने सेकेंडरी को पूर्ण पुनर्स्थापना के साथ शुरू किया है।
2. चलाएं DBCC CHECKDB अक्सर पूर्ण . के विरुद्ध कुछ और करने से पहले पुनर्स्थापित करें। दोबारा, इस बिंदु पर लॉग रिकॉर्ड को फिर से चलाने से यह डेटाबेस सच्ची प्रतिलिपि . के रूप में अमान्य हो जाएगा स्रोत का।
3. चलाएं DBCC CHECKDB आपके प्राथमिक के खिलाफ, शायद पॉल रैंडल द्वारा सुझाए गए तरीकों से, और/या कम लगातार शेड्यूल पर, और/या PHYSICAL_ONLY का उपयोग करके विभाजित किया गया अधिक से अधिक बार नहीं। यह इस बात पर निर्भर कर सकता है कि आप कितनी बार और मज़बूती से प्रदर्शन कर रहे हैं (2)।
4. यह कभी न मानें कि सेकेंडरी के खिलाफ चेक पर्याप्त हैं। यहां तक ​​​​कि आपके प्राथमिक डेटाबेस की सटीक प्रतिकृति के साथ, अभी भी भौतिक समस्याएं हैं जो आपके प्राथमिक के I/O सबसिस्टम पर हो सकती हैं जो कभी भी द्वितीयक के लिए प्रचारित नहीं होंगी।
5. हमेशा DBCC का विश्लेषण करें आउटपुट बस इसे चलाना और इसे अनदेखा करना, किसी सूची से इसकी जांच करना, बैकअप चलाने और कभी भी परीक्षण किए बिना सफलता का दावा करने के समान सहायक है कि आप वास्तव में जरूरत पड़ने पर उस बैकअप को पुनर्स्थापित कर सकते हैं।

ट्रेस फ़्लैग 2549, 2562, और 2566 के साथ प्रयोग

मैंने दो ट्रेस फ़्लैग (2549 और 2562) का कुछ गहन परीक्षण किया है और पाया है कि वे पर्याप्त प्रदर्शन सुधार प्राप्त कर सकते हैं, हालांकि लोनी की रिपोर्ट है कि वे अब आवश्यक या उपयोगी नहीं हैं। अगर आप 2016 या इससे नए हैं, तो इस पूरे अनुभाग को छोड़ दें . यदि आप पुराने संस्करण पर हैं, तो इन दो ट्रेस फ़्लैग्स को KB #2634571 में बहुत अधिक विस्तार से वर्णित किया गया है, लेकिन मूल रूप से:

• ट्रेस फ्लैग 2549
  • यह प्रत्येक व्यक्तिगत डेटाबेस फ़ाइल को एक अद्वितीय अंतर्निहित डिस्क पर रहने के रूप में मानकर चेकडीबी प्रक्रिया को अनुकूलित करता है। यदि आपके डेटाबेस में एक एकल डेटा फ़ाइल है, या यदि आप जानते हैं कि प्रत्येक डेटाबेस फ़ाइल वास्तव में, एक अलग ड्राइव पर है, तो इसका उपयोग करना ठीक है। यदि आपके डेटाबेस में एकाधिक फ़ाइलें हैं और वे एक एकल, प्रत्यक्ष-संलग्न स्पिंडल साझा करते हैं, तो आपको इस ट्रेस फ़्लैग से सावधान रहना चाहिए, क्योंकि यह अच्छे से अधिक नुकसान कर सकता है।

    महत्वपूर्ण :sql.sasquatch SQL सर्वर 2014 में इस ट्रेस ध्वज व्यवहार में एक प्रतिगमन की रिपोर्ट करता है।
    

• ट्रेस फ्लैग 2562
  • यह ध्वज उच्च tempdb उपयोग (डेटाबेस आकार के 5% तक) की कीमत पर संपूर्ण चेकडीबी प्रक्रिया को एक बैच के रूप में मानता है।
  • डेटाबेस से पृष्ठों को पढ़ने का तरीका निर्धारित करने के लिए एक बेहतर एल्गोरिदम का उपयोग करता है, लैच विवाद को कम करता है (विशेष रूप से DBCC_MULTIOBJECT_SCANNER के लिए) ) ध्यान दें कि यह विशिष्ट सुधार SQL Server 2012 कोड पथ में है, इसलिए आप ट्रेस ध्वज के बिना भी इससे लाभान्वित होंगे। यह त्रुटियों से बच सकता है जैसे:
    कुंडी की प्रतीक्षा करते समय समय समाप्त हो गया:कक्षा 'DBCC_MULTIOBJECT_SCANNER'।
• उपरोक्त दो ट्रेस फ़्लैग निम्न संस्करणों में उपलब्ध हैं:

  SQL Server 2008 सर्विस पैक 2 संचयी अद्यतन 9+
  (10.00.4330 -> 10.00.5499)

  SQL सर्वर 2008 सर्विस पैक 3 संचयी अद्यतन 4+
  (10.00.5775+)

  SQL Server 2008 R2 RTM संचयी अद्यतन 11+
  (10.50.1809 -> 10.50.2424)

  SQL Server 2008 R2 सर्विस पैक 1 संचयी अद्यतन 4+
  (10.50.2796 -> 10.50.3999)

  SQL Server 2008 R2 सर्विस पैक 2
  (10.50.4000+)

  SQL सर्वर 2012, सभी संस्करण
  (11.00.2100+)

• ट्रेस फ्लैग 2566
  • यदि आप अभी भी SQL Server 2005 का उपयोग कर रहे हैं, तो यह ट्रेस ध्वज, 2005 SP2 CU#9 (9.00.3282) में प्रस्तुत किया गया था (हालांकि उस संचयी अद्यतन के नॉलेज बेस आलेख, KB #953752) में प्रलेखित नहीं है, खराब प्रदर्शन को ठीक करने का प्रयास करता है DATA_PURITY . का x64-आधारित सिस्टम पर जाँच करता है। एक बिंदु पर, आप KB #945770 में अधिक विवरण देख सकते थे, लेकिन ऐसा लगता है कि आलेख को Microsoft की सहायता साइट और WayBack मशीन दोनों से साफ़ किया गया था। SQL सर्वर के अधिक आधुनिक संस्करणों में यह ट्रेस फ़्लैग आवश्यक नहीं होना चाहिए, क्योंकि क्वेरी प्रोसेसर में समस्या को ठीक कर दिया गया है।

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

I/O प्रभाव कम करें:tempdb अनुकूलित करें

DBCC CHECKDB tempdb का भारी उपयोग कर सकते हैं, इसलिए सुनिश्चित करें कि आप वहां संसाधन उपयोग की योजना बना रहे हैं। यह आमतौर पर किसी भी मामले में करना एक अच्छी बात है। CHECKDB के लिए आप tempdb को उचित रूप से स्थान आवंटित करना चाहेंगे; आखिरी चीज जो आप चाहते हैं वह है CHECKDB . के लिए प्रगति (और किसी भी अन्य समवर्ती संचालन) को ऑटोग्रो के लिए इंतजार करना पड़ता है। आप WITH ESTIMATEONLY . का उपयोग करके आवश्यकताओं के लिए एक विचार प्राप्त कर सकते हैं , जैसा कि पॉल यहां बताते हैं। बस इस बात से अवगत रहें कि SQL Server 2008 R2 में बग के कारण अनुमान काफी कम हो सकता है। इसके अलावा यदि आप ट्रेस फ्लैग 2562 का उपयोग कर रहे हैं तो अतिरिक्त स्थान आवश्यकताओं के लिए समायोजित करना सुनिश्चित करें।

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

• tempdb प्रदर्शन का अनुकूलन (MSDN)
• tempdb के लिए क्षमता योजना (MSDN)
• एक SQL सर्वर DBA मिथक एक दिन:(12/30) tempdb में प्रति प्रोसेसर कोर में हमेशा एक डेटा फ़ाइल होनी चाहिए

I/O प्रभाव कम करें:स्नैपशॉट नियंत्रित करें

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

आपने CHECKDB . को ज़बरदस्ती करने के सुझाव देखे होंगे WITH TABLOCK . का उपयोग करके ऑफ़लाइन मोड में चलाने के लिए विकल्प। मैं इस दृष्टिकोण के खिलाफ दृढ़ता से अनुशंसा करता हूं। यदि आपका डेटाबेस सक्रिय रूप से उपयोग किया जा रहा है, तो इस विकल्प को चुनने से उपयोगकर्ता निराश होंगे। और यदि डेटाबेस सक्रिय रूप से उपयोग नहीं किया जा रहा है, तो आप स्नैपशॉट से बचकर कोई डिस्क स्थान नहीं बचा रहे हैं, क्योंकि स्टोर करने के लिए कोई कॉपी-ऑन-राइट गतिविधि नहीं होगी।

I/O प्रभाव कम करें:665/1450/1452 त्रुटियों से बचें

कुछ मामलों में आपको निम्न में से कोई एक त्रुटि दिखाई दे सकती है:

फ़ाइल '[फ़ाइल]' में ऑफ़सेट 0x[…] पर लिखने के दौरान ऑपरेटिंग सिस्टम ने त्रुटि 665 (फ़ाइल सिस्टम की सीमा के कारण अनुरोधित कार्रवाई पूरी नहीं की जा सकी) SQL सर्वर को लौटा दी।

CHECKDB . के दौरान इन त्रुटियों के जोखिम को कम करने के लिए यहां कुछ युक्तियां दी गई हैं संचालन, और सामान्य रूप से उनके प्रभाव को कम करना - आपके ऑपरेटिंग सिस्टम और SQL सर्वर संस्करण के आधार पर उपलब्ध कई सुधारों के साथ:

• विरल फ़ाइल त्रुटियाँ:1450 या 665 फ़ाइल विखंडन के कारण:सुधार और समाधान
• SQL सर्वर ऑपरेटिंग सिस्टम त्रुटि 1450 या 1452 या 665 (पुन:प्रयास) की रिपोर्ट करता है

CPU प्रभाव कम करें

DBCC CHECKDB डिफ़ॉल्ट रूप से बहु-थ्रेडेड है (लेकिन केवल एंटरप्राइज़ संस्करण में)। यदि आपका सिस्टम CPU-बद्ध है, या आप केवल CHECKDB चाहते हैं लंबे समय तक चलने की कीमत पर कम CPU का उपयोग करने के लिए, आप दो अलग-अलग तरीकों से समानता को कम करने पर विचार कर सकते हैं:

1. जब तक आप एंटरप्राइज़ संस्करण चला रहे हैं, 2008 और उसके बाद के संस्करण पर संसाधन गवर्नर का उपयोग करें। किसी विशेष संसाधन पूल या कार्यभार समूह के लिए केवल DBCC कमांड को लक्षित करने के लिए, आपको एक क्लासिफायर फ़ंक्शन लिखना होगा जो उन सत्रों की पहचान कर सकता है जो यह कार्य करेंगे (जैसे एक विशिष्ट लॉगिन या एक जॉब_आईडी)।
2. DBCC CHECKDB के लिए समानांतरवाद को बंद करने के लिए ट्रेस फ़्लैग 2528 का उपयोग करें (साथ ही CHECKFILEGROUP और CHECKTABLE ) ट्रेस फ्लैग 2528 का वर्णन यहां किया गया है। बेशक यह केवल एंटरप्राइज़ संस्करण में मान्य है, क्योंकि वर्तमान में पुस्तकें ऑनलाइन जो कहती हैं, उसके बावजूद सच्चाई यह है कि CHECKDB मानक संस्करण में समानांतर नहीं जाता है।
3. जबकि DBCC कमांड स्वयं MAXDOP . का समर्थन नहीं करता है (कम से कम SQL Server 2014 SP2 से पहले), यह वैश्विक सेटिंग max degree of parallelism का सम्मान करता है . शायद ऐसा कुछ नहीं जो मैं उत्पादन में करूंगा जब तक कि मेरे पास कोई अन्य विकल्प न हो, लेकिन यह कुछ DBCC को नियंत्रित करने का एक व्यापक तरीका है। आदेश यदि आप उन्हें अधिक स्पष्ट रूप से लक्षित नहीं कर सकते हैं।

हम CPU की संख्या पर बेहतर नियंत्रण की मांग कर रहे थे जो DBCC CHECKDB उपयोग करता है, लेकिन SQL सर्वर 2014 SP2 तक उन्हें बार-बार अस्वीकार कर दिया गया था। तो अब आप WITH MAXDOP = n . जोड़ सकते हैं आदेश के लिए।

मेरे निष्कर्ष

मैं इनमें से कुछ तकनीकों को ऐसे वातावरण में प्रदर्शित करना चाहता था जिसे मैं नियंत्रित कर सकता था। मैंने AdventureWorks2012 को स्थापित किया, फिर जोनाथन केहैयस (ब्लॉग | @SQLPoolBoy) द्वारा लिखित AW विस्तारक स्क्रिप्ट का उपयोग करके इसका विस्तार किया, जिसने डेटाबेस को लगभग 7 जीबी तक बढ़ा दिया। फिर मैंने CHECKDB . की एक श्रृंखला चलाई इसके खिलाफ आदेश, और उन्हें समय दिया। मैंने एक सादे वैनिला DBCC CHECKDB . का इस्तेमाल किया अपने आप, फिर अन्य सभी कमांड WITH NO_INFOMSGS, ALL_ERRORMSGS का उपयोग करते हैं . फिर चार परीक्षण (ए) नो ट्रेस फ्लैग, (बी) 2549, (सी) 2562, और (डी) दोनों 2549 और 2562 के साथ। फिर मैंने उन चार परीक्षणों को दोहराया, लेकिन PHYSICAL_ONLY जोड़ा। विकल्प, जो सभी तार्किक जाँचों को बायपास करता है। परिणाम (औसतन 10 से अधिक टेस्ट रन) बता रहे हैं:

CHECKDB परिणाम 7GB डेटाबेस के विरुद्ध

फिर मैंने डेटाबेस का कुछ और विस्तार किया, दो बढ़े हुए तालिकाओं की कई प्रतियां बनाईं, जिससे डेटाबेस का आकार सिर्फ 70 जीबी के उत्तर में हो गया, और फिर से परीक्षण चला। परिणाम, फिर से औसतन 10 से अधिक टेस्ट रन:

CHECKDB परिणाम 70GB डेटाबेस पर

इन दो परिदृश्यों में, मैंने निम्नलिखित सीखा है (फिर से, यह ध्यान में रखते हुए कि आपका माइलेज भिन्न हो सकता है, और यह कि आपको कोई सार्थक निष्कर्ष निकालने के लिए अपने स्वयं के परीक्षण करने की आवश्यकता होगी):

1. जब मुझे तार्किक जांच करनी हो:
   • छोटे डेटाबेस आकार में, NO_INFOMSGS जब SSMS में चेक चलाए जाते हैं तो विकल्प प्रसंस्करण समय में काफी कटौती कर सकता है। हालांकि, बड़े डेटाबेस पर, यह लाभ कम हो जाता है, क्योंकि सूचना को प्रसारित करने में लगने वाला समय और कार्य समग्र अवधि का इतना महत्वहीन हिस्सा बन जाता है। 2 मिनट में 21 सेकंड काफ़ी है; 35 मिनट में से 88 सेकंड, इतना नहीं।
   • मैंने जिन दो ट्रेस फ़्लैग का परीक्षण किया, उनका प्रदर्शन पर महत्वपूर्ण प्रभाव पड़ा - जब दोनों का एक साथ उपयोग किया गया तो रनटाइम में 40-60% की कमी आई।
     
2. जब मैं तार्किक जांच को द्वितीयक सर्वर पर धकेल सकता हूं (फिर से, यह मानते हुए कि मैं सच्ची प्रतिलिपि के विरुद्ध कहीं और तार्किक जांच कर रहा हूं। ):
   • मैं एक मानक CHECKDB की तुलना में अपने प्राथमिक इंस्टेंस पर संसाधन समय को 70-90% तक कम कर सकता हूं बिना किसी विकल्प के कॉल करें।
   • मेरे परिदृश्य में, PHYSICAL_ONLY प्रदर्शन करते समय ट्रेस फ़्लैग्स का अवधि पर बहुत कम प्रभाव पड़ा जाँच करता है।

बेशक, और मैं इस पर पर्याप्त जोर नहीं दे सकता, ये अपेक्षाकृत छोटे डेटाबेस हैं और केवल इसलिए उपयोग किए जाते हैं ताकि मैं उचित समय में बार-बार, मापा परीक्षण कर सकूं। इस सर्वर में 80 तार्किक सीपीयू और 128 जीबी रैम थे, और मैं अकेला उपयोगकर्ता था। सिस्टम पर अन्य कार्यभार के साथ अवधि और अंतःक्रिया इन परिणामों को काफी कम कर सकती है। यहां CHECKDB में से किसी एक के दौरान SQL संतरी का उपयोग करते हुए सामान्य CPU उपयोग की एक त्वरित झलक दी गई है संचालन (और किसी भी विकल्प ने वास्तव में CPU पर समग्र प्रभाव को नहीं बदला, बस अवधि):

CHECKDB के दौरान CPU प्रभाव - नमूना मोड

और यहां एक और दृश्य है, जो तीन अलग-अलग नमूनों के लिए समान CPU प्रोफाइल दिखा रहा है CHECKDB ऐतिहासिक मोड में संचालन (मैंने इस श्रेणी में नमूने लिए गए तीन परीक्षणों का विवरण मढ़ा है):

CHECKDB के दौरान CPU प्रभाव - ऐतिहासिक मोड

व्यस्त सर्वरों पर होस्ट किए गए और भी बड़े डेटाबेस पर, आप अलग-अलग प्रभाव देख सकते हैं, और आपका माइलेज भिन्न होने की संभावना है। तो कृपया अपना उचित परिश्रम करें और इन विकल्पों का परीक्षण करें और एक विशिष्ट समवर्ती कार्यभार के दौरान झंडे का पता लगाएं, यह तय करने से पहले कि आप CHECKDB तक कैसे पहुंचना चाहते हैं ।

निष्कर्ष

DBCC CHECKDB एक डीबीए या आर्किटेक्ट के रूप में आपकी जिम्मेदारी का एक बहुत ही महत्वपूर्ण लेकिन अक्सर इसका मूल्यांकन नहीं किया जाता है, और आपकी कंपनी के डेटा की सुरक्षा के लिए महत्वपूर्ण है। इस जिम्मेदारी को हल्के में न लें, और यह सुनिश्चित करने के लिए अपनी पूरी कोशिश करें कि आप अपने उत्पादन उदाहरणों पर प्रभाव को कम करने के हित में कुछ भी त्याग न करें। सबसे महत्वपूर्ण:यह सुनिश्चित करने के लिए कि आप पूरी तरह से समझते हैं कि वे वादे कितने वैध हैं और क्या आप उन पर अपनी कंपनी के डेटा को दांव पर लगाने के इच्छुक हैं, मार्केटिंग डेटा शीट से परे देखें। कुछ चेकों को स्किप करना या उन्हें अमान्य द्वितीयक स्थानों पर उतारना एक आपदा हो सकती है जो घटित होने की प्रतीक्षा कर रही है।

आपको इन PSS लेखों को पढ़ने पर भी विचार करना चाहिए:

• एक तेज़ CHECKDB - भाग I
• एक तेज़ CHECKDB - भाग II
• एक तेज़ CHECKDB - भाग III
• एक तेज़ CHECKDB - भाग IV (SQL CLR UDTs)

और ब्रेंट ओज़र की यह पोस्ट:

• DBCC CHECKDB को तेज़ चलाने के 3 तरीके

अंत में, यदि आपके पास DBCC CHECKDB . के बारे में कोई अनसुलझा प्रश्न है , इसे ट्विटर पर #sqlhelp हैश टैग पर पोस्ट करें। पॉल अक्सर उस टैग की जांच करता है और, चूंकि उसकी तस्वीर मुख्य पुस्तकें ऑनलाइन लेख में दिखाई देनी चाहिए, यह संभावना है कि अगर कोई इसका उत्तर दे सकता है, तो वह कर सकता है। यदि यह 140 वर्णों के लिए बहुत जटिल है, तो आप यहां पूछ सकते हैं (और मैं सुनिश्चित करूंगा कि पॉल इसे किसी बिंदु पर देखे), या डेटाबेस व्यवस्थापक स्टैक एक्सचेंज जैसी फ़ोरम साइट पर पोस्ट करें।