परिचय
नियमित डेटाबेस रखरखाव डेटाबेस प्रशासक के काम का एक महत्वपूर्ण हिस्सा है जो यह सुनिश्चित करने में मदद करता है कि महत्वपूर्ण रूप से महत्वपूर्ण सिस्टम सामान्य रूप से चल रहे हैं। इसे पूरा करने के सबसे आसान तरीकों में से एक डीबीसीसी चेकडीबी से संबंधित कार्यों को स्वचालित करना होगा। कोई फर्क नहीं पड़ता कि आप SQL सर्वर का कौन सा संस्करण चला रहे हैं, ऐसा डेटाबेस कभी नहीं होगा जिसे रखरखाव की आवश्यकता नहीं है। आपको नियमित रूप से रखरखाव की योजना बनानी होगी ताकि आप विशेष रूप से वास्तविक आपदा परिदृश्य के समय अपनी पीठ को ढक सकें।
डीबीए हमेशा अपराधी होता है
जब भी कोई डेटाबेस समस्या होती है, तो सभी की निगाहें DBA पर होती हैं। चाहे समस्या बारिश के कारण हुई हो या कुछ डेवलपर द्वारा खराब कोड लिखने के कारण डेटाबेस धीमा हो गया हो, DBA से हमेशा गड़बड़ी को ठीक करने की अपेक्षा की जाती है। और आप कल्पना कर सकते हैं कि आपको किस प्रकार के दबाव से निपटने की आवश्यकता है यदि आपको अंतिम उपलब्ध बैकअप का उपयोग करके डेटाबेस को जल्दी से पुनर्स्थापित करने के लिए कहा जाता है, जैसा कि आप इस प्रक्रिया में पाते हैं, मान्य नहीं है और डेटाबेस अखंडता पहले से ही कुछ महीनों से समझौता किया गया था पहले। यहाँ एक सक्रिय DBA और एक प्रतिक्रियाशील DBA के बीच अंतर है। वास्तव में, बैकअप रणनीति की तुलना में आपकी पुनर्प्राप्ति रणनीति बहुत अधिक महत्वपूर्ण है। दैनिक डेटाबेस बैकअप किस उद्देश्य की पूर्ति कर सकते हैं यदि वे बहाली के समय किसी काम के नहीं हैं?
रखरखाव क्यों महत्वपूर्ण है?
डेटाबेस प्रौद्योगिकियों के अभूतपूर्व विकास और प्रत्येक रिलीज के साथ दिखाई देने वाली नई सुविधाओं के साथ, एक डीबीए के रूप में आपके लिए यह अनिवार्य है कि आप बाकी से आगे रहें और सुनिश्चित करें कि आप उद्योग-सर्वोत्तम प्रथाओं का पालन कर रहे हैं डेटाबेस रखरखाव।
DBCC CheckDB और हम इसे कैसे चला सकते हैं
DBCC CheckDB - यह नाम कार्यक्षमता का काफी वर्णनात्मक है। आसान शब्दों में कहें तो यह डेटाबेस की जांच करता है। यह सुनिश्चित करना महत्वपूर्ण है कि यह डेटाबेस अपेक्षा के अनुरूप काम कर रहा है। मूल रूप से, DBCC CheckDB डेटाबेस में सभी वस्तुओं की तार्किक और भौतिक अखंडता की जाँच करता है। आधिकारिक . के अनुसार DBCC CheckDB हुड के तहत यही करता है माइक्रोसॉफ्ट दस्तावेज:
डेटाबेस पर DBCC CHECKALLOC चलाता है - डिस्क स्थान आवंटन की स्थिरता
डेटाबेस में प्रत्येक तालिका और दृश्य पर DBCC CHECKTABLE चलाता है - यह तालिका या अनुक्रमित दृश्य बनाने वाले सभी पृष्ठों और संरचनाओं की अखंडता है।
डेटाबेस पर DBCC CHECKCATALOG चलाता है - यह निर्दिष्ट डेटाबेस के भीतर कैटलॉग संगतता के लिए जाँच करता है।
डेटाबेस में प्रत्येक अनुक्रमित दृश्य की सामग्री को मान्य करता है।
FILESTREAM का उपयोग करके फ़ाइल सिस्टम में varbinary(max) डेटा संग्रहीत करते समय तालिका मेटाडेटा और फ़ाइल सिस्टम निर्देशिकाओं/फ़ाइलों के बीच लिंक-स्तरीय संगतता को मान्य करता है।
डेटाबेस में सर्विस ब्रोकर डेटा को मान्य करता है।
जब आप DBCC CheckDB कमांड को स्पष्ट रूप से या नौकरी के माध्यम से चलाते हैं, तो यह मूल रूप से उपरोक्त सभी को करता है।
DBCC CheckDB को सीधे डेटाबेस पर चलाना
आप सीधे डेटाबेस पर DBCC CheckDB कमांड चला सकते हैं और परिणामों की जांच कर सकते हैं। नीचे स्क्रीनशॉट में दिखाए अनुसार कमांड का आउटपुट चेक करें। आउटपुट तालिकाओं में पंक्तियों और इन पंक्तियों द्वारा उपयोग किए गए पृष्ठों की संख्या के बारे में विवरण दिखाता है।
यदि आप बारीकी से देखें, तो आप डेटाबेस ऑब्जेक्ट्स के लिए विशिष्ट विवरण देखेंगे। उदाहरण के लिए, "VLDB" डेटाबेस पर, मैं निम्नलिखित आउटपुट देख सकता हूँ:
“Object ID 1179151246 (object 'Warehouse.ColdRoomTemperatures'): The operation is not supported with memory optimized tables. This object has been skipped and will not be processed.”
जैसा कि यह आउटपुट दिखाता है, DBCC CheckDB स्मृति-अनुकूलित तालिकाओं के साथ समर्थित नहीं है। मेमोरी-ऑप्टिमाइज़्ड टेबल्स को पहली बार SQL Server 2014 में एंटरप्राइज़-ओनली फीचर के रूप में पेश किया गया था। हालांकि, पिछले कुछ वर्षों में वे SQL सर्वर में एक लोकप्रिय और व्यापक कार्यक्षमता बन गए हैं।
आप यह भी देखेंगे कि DBCC चेक ने डेटाबेस में सर्विस ब्रोकर डेटा को मान्य किया है जैसा कि नीचे दिखाया गया है।
“DBCC results for 'VLDB'. Service Broker Msg 9675, State 1: Message Types analyzed: 14. Service Broker Msg 9676, State 1: Service Contracts analyzed: 6. Service Broker Msg 9667, State 1: Services analyzed: 3. Service Broker Msg 9668, State 1: Service Queues analyzed: 3. Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0. Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0. Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0. Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.”
आखिरकार, DBCC CheckDB कमांड सफलतापूर्वक पूरा होने के बाद, आपको निम्न आउटपुट दिखाई देगा:
क्या होता है यदि DBCC CheckDB चलाने के बाद त्रुटियों की रिपोर्ट की जाती है?
उपरोक्त उदाहरण में, आप देख सकते हैं कि DBCC CheckDB बिना किसी त्रुटि के पूरा हो गया था। हालाँकि, यदि आप इतने भाग्यशाली नहीं हैं, तो आपको निरंतरता की त्रुटियां आ सकती हैं - और यही वह समय होगा जब आपको कुछ महत्वपूर्ण निर्णय लेने की आवश्यकता होगी। यदि आपको उत्पादन डेटाबेस में कोई समस्या आती है, तो व्यापार मालिकों या अपने संचालन प्रबंधक को अपने कार्ड टेबल पर रखने के लिए सूचित करना सबसे अच्छा है। आप या तो उन्हें अंतिम उपलब्ध बैकअप से डेटाबेस को पुनर्स्थापित करने का विकल्प दे सकते हैं या आप अतिरिक्त विकल्पों के साथ DBCC CheckDB कमांड चलाने के साथ प्रयोग कर सकते हैं।
DBCC त्रुटि संदेश कुछ इस तरह दिख सकते हैं:
Table error: Object ID 36, index ID 1, partition ID, alloc unit ID (type In-row data). Keys out of order on page (1:107), slots 6 and 9. CHECKDB found 0 allocation errors and 1 consistency errors in table 'sys.syk' (object ID 36). CHECKDB found 0 allocation errors and 1 consistency errors in database 'VLDB'. repair_rebuild is the minimum repair level for the errors found by DBCC CHECKDB (VLDB).
त्रुटि संदेश में, आप ध्यान से लिखे गए त्रुटि संदेश को देख सकते हैं - "repair_rebuild है न्यूनतम DBCC CHECKDB द्वारा पाई गई त्रुटियों के लिए सुधार स्तर ”- आपको डीबीसीसी चेकडीबी को रिपेयर_रेबिल्ड विकल्प के साथ चलाने का सुझाव दे रहा है। हाइलाइट किए जा रहे शब्द को देखें - 'न्यूनतम'। इसका मतलब है कि, Repair_rebuild विकल्प के साथ, डेटा हानि की कोई वास्तविक संभावना नहीं है और SQL सर्वर हुड के तहत कुछ त्वरित सुधार करता है। डीबीसीसी चेकडीबी को रिपेयर_रेबिल्ड विकल्प के साथ चलाने के लिए कृपया नीचे दिए गए कमांड को देखें। डेटाबेस को सिंगल यूजर मोड में रखना सुनिश्चित करें।
Microsoft दस्तावेज़ के अनुसार, REPAIR_REBUILD विकल्प सबसे हानिरहित संस्करण है क्योंकि कोई डेटा हानि नहीं हो सकती है। हालाँकि, यदि REPAIR_REBUILD अभी भी संगतता त्रुटियों को ठीक नहीं करता है, तो एक अन्य विकल्प है - REPAIR_ALLOW_DATA_LOSS को सक्षम करने के लिए। नाम को देखते हुए, हम जानते हैं कि अगर हम इस विकल्प को चालू करते हैं तो कुछ डेटा हानि की संभावना होगी। इसके कारण, Microsoft हमें अत्यधिक सावधानी के साथ इसका उपयोग करने की चेतावनी देता है क्योंकि DBCC CheckDB को REPAIR_ALLOW_DATA_LOSS के साथ चलाने पर अप्रत्याशित परिणाम हो सकते हैं। इस मामले में DBCC CheckDB कमांड इस तरह दिखेगा:
DBCC CheckDB के साथ मरम्मत विकल्प का उपयोग करने से पहले विचार करने योग्य बिंदु
विचाराधीन डेटाबेस कितना महत्वपूर्ण है?
क्या डेटाबेस उत्पादन या परीक्षण वातावरण पर है?
डेटाबेस कितना बड़ा है?
समस्या आने की स्थिति में क्या आपके पास एक अच्छी पुनर्प्राप्ति रणनीति है?
क्या आपने अपने डेटाबेस बैकअप की पुष्टि की है?
उपरोक्त प्रश्नों के उत्तर और स्थिति के आधार पर, ग्राहक के सर्वोत्तम हितों को ध्यान में रखते हुए निर्णय लेने का प्रयास करें।
डेटाबेस रखरखाव योजनाओं का उपयोग करके SQL सर्वर पर DBCC CheckDB कार्यों को स्वचालित करना
ठीक है, आपको इन सभी आदेशों को अपने सर्वर पर मैन्युअल रूप से चलाने की आवश्यकता नहीं है। इसलिए हमारे पास रखरखाव की योजना है। डेटाबेस रखरखाव योजनाओं का उपयोग करके अपने सभी डेटाबेस के लिए नियमित रखरखाव चक्र शेड्यूल करना सुनिश्चित करें। यह काफी सरल और सीधा काम है। "रखरखाव योजना कार्य" के तहत, "डेटाबेस अखंडता कार्य जांचें" चुनें।
यह आपके डेटाबेस के लिए अखंडता जांच शेड्यूल करने के लिए आपकी रखरखाव योजना में एक उप-कार्य जोड़ देगा। दिखाए गए अनुसार आवश्यक डेटाबेस का चयन करना सुनिश्चित करें।
कृपया सप्ताह के व्यस्ततम समय के दौरान सभी डेटाबेस जाँचों को चलाना सुनिश्चित करें। आमतौर पर, रखरखाव विंडो सप्ताहांत पर होती है जब सर्वर सप्ताह के अन्य दिनों की तुलना में कम व्यस्त होता है। हालाँकि, यह सर्वर से सर्वर में भिन्न होगा और एप्लिकेशन पर निर्भर करता है। महत्वपूर्ण डेटाबेस सिस्टम पर, अलर्ट आमतौर पर तब दिखाए जाते हैं जब कोई DBCC CheckDB या अखंडता जांच छूट जाती है। इस तरह, डीबीए सक्रिय रूप से जांच कर सकते हैं और सुनिश्चित कर सकते हैं कि वे बाद में आश्चर्य से बचने के लिए अखंडता जांच पूरी कर लें।
कस्टमाइज्ड स्क्रिप्ट या अन्य लोकप्रिय स्क्रिप्ट का उपयोग करके SQL सर्वर पर DBCC CheckDB कार्यों को स्वचालित करना
SQL सर्वर रखरखाव योजनाओं को आपके SQL सर्वर इंस्टेंस पर रखरखाव कार्यों को करने के लिए हर समय उपयोग करने की आवश्यकता नहीं है। अन्य उपलब्ध अनुकूलित स्क्रिप्ट हैं जिनका आप उपयोग कर सकते हैं। लोकप्रिय मुफ्त रखरखाव उपकरणों में से एक ओला हॉलेंग्रेन का रखरखाव समाधान है। आप संपूर्ण रखरखाव समाधान स्थापित कर सकते हैं जिसमें बैकअप, अनुकूलन आदि के लिए कार्य शामिल हैं, या आप केवल अखंडता जांच से संबंधित प्रासंगिक स्क्रिप्ट डाउनलोड कर सकते हैं। इस डेमो में, हम डेटाबेस अखंडता जांच के लिए विशिष्ट स्क्रिप्ट को स्थापित करने का प्रयास करेंगे।
DatabaseIntegrityCheck.sql विकल्प पर क्लिक करें जैसा कि डेटाबेस अखंडता की जांच करने वाली संग्रहीत प्रक्रियाओं को डाउनलोड करने के लिए दिखाया गया है। इन संग्रहीत कार्यविधियों को मास्टर डेटाबेस पर चलाने के बाद, मुझे ये चेतावनी संदेश मिले:
“The module 'DatabaseIntegrityCheck' depends on the missing object 'dbo.CommandExecute'. The module will still be created; however, it cannot run successfully until the object exists.”
यदि आप अखंडता जांच करने के लिए संग्रहीत कार्यविधि चलाते हैं, तो आपको निम्न त्रुटि प्राप्त होगी:
जैसा कि त्रुटि बताती है, आप लापता कोड यहां डाउनलोड कर सकते हैं। एक बार यह हो जाने के बाद, आप डेटाबेस अखंडता जाँचों को आज़माना शुरू कर सकते हैं।
आप अतिरिक्त DBCC कमांड पैरामीटर का उपयोग करके विभिन्न विकल्पों को समायोजित कर सकते हैं। आप उनके बारे में अधिक विवरण और उदाहरण यहां पा सकते हैं।
हालांकि, इस डेमो में, हम यह देखने के लिए कुछ उदाहरणों की जांच करेंगे कि ये स्क्रिप्ट वास्तव में कितनी आसान और उपयोगकर्ता के अनुकूल हैं।
सभी उपयोगकर्ता डेटाबेस पर DBCC CheckDB चलाने के लिए , आपको निम्नलिखित निष्पादित करने की आवश्यकता होगी:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'USER_DATABASES', @CheckCommands = 'CHECKDB'
आप चलाए गए कमांड और परिणाम की स्थिति देख सकते हैं जो पुष्टि करता है कि DBCC CheckDB सफलतापूर्वक पूरा हुआ।
चलाने के लिए DBCC केवल सिस्टम डेटाबेस की जांच करें, इस कमांड को निष्पादित करें:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'SYSTEM_DATABASES', @CheckCommands = 'CHECKDB'
स्क्रीनशॉट पर, आप देख सकते हैं कि सिस्टम डेटाबेस के लिए DBCC CheckDB सफलतापूर्वक पूरा किया गया था।
केवल एक विशिष्ट डेटाबेस के लिए DBCC CheckDB चलाने के लिए, निम्नलिखित निष्पादित करें:
EXECUTE dbo.DatabaseIntegrityCheck @Databases = 'VLDB', -- your specific DB Name @CheckCommands = 'CHECKDB'
उपरोक्त उदाहरण में, आपने देखा कि हम पैरामीटर का उपयोग कैसे कर सकते हैं। हालाँकि, कई अन्य फ़िल्टर हैं जिन्हें आप अपनी प्राथमिकताओं के आधार पर चुन सकते हैं। साथ ही, जैसा कि पहले ही उल्लेख किया गया है, आप इस लिंक का संदर्भ ले सकते हैं ओला हॉलेंग्रेन की लिपियों को और समझने के लिए। बस दोहराने के लिए, मैं अपने द्वारा प्रबंधित सर्वर पर ओला हॉलेंग्रेन की स्क्रिप्ट का उपयोग कर रहा हूं और यह SQL सर्वर समुदाय के भीतर अत्यधिक अनुशंसित और मान्यता प्राप्त है। आप अपने पसंदीदा मापदंडों के आधार पर संग्रहीत कार्यविधियों को शेड्यूल कर सकते हैं और इसे ऑफ-पीक घंटों के दौरान एक SQL कार्य चला सकते हैं। इस तरह, आपको इनमें से किसी भी स्क्रिप्ट को मैन्युअल रूप से चलाने की ज़रूरत नहीं है, ताकि आप अन्य महत्वपूर्ण कार्यों पर ध्यान केंद्रित कर सकें।
निष्कर्ष
- इस लेख से, आपने DBCC CheckDB के बारे में सीखा और इसका उपयोग कैसे किया जा सकता है
- आपने अपने सभी महत्वपूर्ण डेटाबेस पर नियमित आधार पर DBCC CheckDB चलाने के महत्व को भी समझा
- आपने परीक्षण की गई बैकअप रणनीति के महत्व के बारे में भी जाना - यह अनुशंसा की जाती है कि DBCC मरम्मत विकल्पों का उपयोग करके किसी भी संगति त्रुटि को हल करने के बजाय एक अच्छे बैकअप का उपयोग करके अपने डेटाबेस को पुनर्स्थापित करें
- आपने यह भी देखा कि SQL सर्वर रखरखाव योजनाओं या अनुकूलित स्क्रिप्ट का उपयोग करके स्क्रिप्ट को कॉन्फ़िगर और स्वचालित करना कितना आसान है, जैसे, Ola Hallengren से एक।
- आपने अपने समर्थित बुनियादी ढांचे पर DBCC CheckDB को शेड्यूल न करने के जोखिमों के बारे में भी सीखा
- आपने यह भी सीखा कि, आप चाहे किसी भी सर्वर पर हों या आप किस बुनियादी ढांचे को चलाते हों, कोई भी डेटाबेस ऐसा नहीं हो सकता जिसके लिए रखरखाव की आवश्यकता न हो
- अंत में, अपने डेटाबेस को स्वस्थ रखना सुनिश्चित करें और, किसी भी स्थिति में, उन ऑफ दिनों के लिए तैयार रहें जो आपके नियंत्रण में नहीं हो सकते हैं
