MSDB पर रखरखाव का महत्व

MSDB SQL सर्वर द्वारा उपयोग किया जाने वाला एक सिस्टम डेटाबेस है। MSDB सभी प्रकार के डेटा को संग्रहीत करता है, जैसे कि बैकअप और पुनर्स्थापना इतिहास, SQL एजेंट कार्य इतिहास, लॉग शिपिंग मॉनिटर इतिहास, SSIS पैकेज, डेटाबेस इंजन ट्यूनिंग सलाहकार डेटा और सेवा ब्रोकर कतार डेटा। उपयोगकर्ता डेटाबेस की तरह, msdb को नियमित रखरखाव की आवश्यकता होती है, जिसमें अनुक्रमणिका अनुकूलन और अधिक महत्वपूर्ण बात, नियमित रूप से शुद्ध करना शामिल है।

बैकअप और पुनर्स्थापना इतिहास

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

अधिकांश तृतीय पक्ष टूल और सम्मानित रखरखाव समाधानों में बैकअप को साफ़ करने और इतिहास को पुनर्स्थापित करने की प्रक्रिया शामिल है ताकि इसे एक समस्या बनने से रोका जा सके। यह जानने का एक आसान तरीका है कि आप बैकअप इतिहास को शुद्ध कर रहे हैं या नहीं, सीधे msdb को क्वेरी करना है:

सेलेक्ट CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS सर्वर, msdb.dbo.backupset.database_name, msdb.dbo.backupset.backup_finish_date, CASE msdb..backupset.type जब 'D' तब ' डेटाबेस' जब 'L' तब 'लॉग' के रूप में बैकअप_टाइप के रूप में msdb.dbo.backupmediafamilyINNER से msdb.dbo.backupmediafamily.media_set_id =msdb.dbo.backupset.media_set_idORDER BY upset.dbo.dbo. /पूर्व> 

 यदि आपके पास 90 दिनों से अधिक पुराना बैकअप या पुनर्स्थापना इतिहास है, तो आपको जांच करनी चाहिए कि क्या कोई नियामक आवश्यकता है जो अनिवार्य है कि आपको उन बैकअप के बारे में ऐतिहासिक जानकारी एक विशिष्ट अवधि के लिए रखनी चाहिए। यदि कोई आवश्यकता नहीं है, तो आपको एक निश्चित समय अवधि से पुराने डेटा को शुद्ध करने पर विचार करना चाहिए। आपके डेटाबेस को पुनर्स्थापित करने के लिए बैकअप इतिहास की आवश्यकता नहीं है, और हम अनुशंसा करते हैं कि msdb को उचित आकार में रखने के लिए इसे नियमित रूप से शुद्ध किया जाए। मैं आमतौर पर ग्राहकों को 90 दिन या उससे कम समय रखने की सलाह देता हूं।
 

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

 डेटाबेस इंजन ट्यूनिंग सलाहकार, जिसे डीटीए के रूप में भी जाना जाता है, एक उपकरण है जिसका उपयोग डेवलपर्स और डेटाबेस प्रशासक डेटाबेस को ट्यून करने में मदद के लिए कर सकते हैं। ट्यूनिंग इतिहास और अन्य सहायक वस्तुओं को संग्रहीत करने के लिए डीटीए एमएसडीबी डेटाबेस का लाभ उठाता है।
 

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

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

 ऐसे मामलों में जहां ग्राहकों की नौकरी में अप्रतिबंधित वृद्धि हुई थी, sysjobhistory तालिका अत्यधिक बड़ी हो गई थी और उसे शुद्ध करने की आवश्यकता थी। इतिहास को शुद्ध करने का सबसे अच्छा तरीका है sp_purge_jobhistory . का उपयोग करना और दिनांक पैरामीटर में पास करें। संग्रहीत कार्यविधि आपके द्वारा प्रदान की गई तिथि से पुराने सभी कार्य इतिहास को हटा देगी। यदि आपको SQL सर्वर एजेंट इतिहास के दिनों की न्यूनतम संख्या रखनी है, तो पंक्तियों के आधार पर कार्य इतिहास लॉग को सीमित करना प्रभावी नहीं है। इसके बजाय, कार्य इतिहास लॉग के आकार को सीमित न करें और उस कार्य को भी शेड्यूल करें जो sp_purge_jobhistory चलाएगा और आपके लिए आवश्यक कार्य इतिहास के न्यूनतम दिनों के लिए दिनांक पैरामीटर में पास होगा। 14 या 30 दिनों के मान का उपयोग करना सामान्य है। 
 
सर्विस ब्रोकर
 

 हाल ही में मुझे एक क्लाइंट के साथ एक समस्या का सामना करना पड़ा जहां msdb आकार में 14GB तक बढ़ गया था। इंस्टेंस को मौजूदा सर्विस पैक में अपडेट करने के प्रयास के बाद, अपग्रेड स्क्रिप्ट को एमएसडीबी पर लागू करने में विफल रहा और एमएसडीबी को फिर से तेजी से बढ़ने का कारण बना। कुछ शोध के बाद हमने पाया कि सर्विस ब्रोकर को इवेंट नोटिफिकेशन के लिए सक्षम किया गया था लेकिन इसे ठीक से कॉन्फ़िगर नहीं किया गया था। एक साल से अधिक समय से इवेंट नोटिफिकेशन कतार में थे, लेकिन रूट नहीं किए जा रहे थे। 
 

 Sys.transmission_queue की जाँच में मैंने पाया कि लक्ष्य डेटाबेस में सेवा दलाल अनुपलब्ध था, और सेवा दलाल प्रशासनिक रूप से अक्षम था। फिर मैंने यह देखने के लिए जाँच की कि sys.server_events_notifications को क्वेरी करके कौन से ईवेंट नोटिफिकेशन सेट किए गए थे और केवल एक प्रविष्टि मिली:सभी त्रुटि लॉग ईवेंट कैप्चर करें। फिर मैंने sys.transmissions_queue से पूछा कि कतार में कितनी घटनाएं थीं और वहां कई मिलियन रिकॉर्ड मिले। 
 

 क्लाइंट के साथ इस पर चर्चा करने और निष्कर्षों की व्याख्या करने के बाद, हम सहमत हुए कि कार्रवाई का सबसे अच्छा तरीका घटना अधिसूचना को छोड़ना और एक नया ब्रोकर बनाकर वर्तमान कतार को साफ़ करना था। ऐसा करने के लिए मैंने ALTER DATABASE msdb SET NEW_BROKER निष्पादित किया। यह घंटों के बाद और एमएसडीबी के अच्छे पूर्ण बैकअप के बाद किया गया था। 
 

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

 अपने डीबीए करियर की शुरुआत में मुझे एक समेकन सर्वर विरासत में मिला था जिसमें कुछ सौ डेटाबेस थे जो लॉग को दूसरे डेटासेंटर में सेकेंडरी सर्वर पर भेज दिया गया था। यह सर्वर कई वर्षों से चल रहा था और हर 15 मिनट में लॉग भेज रहा था। न केवल यह उदाहरण बैकअप इतिहास को शुद्ध नहीं करने से ग्रस्त था, यह लॉग शिपिंग मॉनिटर इतिहास को ठीक से साफ़ नहीं कर रहा था। एक बार जब मैंने बैकअप इतिहास को शुद्ध कर दिया और msdb के आकार की जाँच कर ली तो यह अभी भी उससे अधिक उपयोग की जाने वाली जगह दिखा रहा था। मैंने प्रत्येक तालिका का कुल आकार दिखाने के लिए एक स्क्रिप्ट चलाई और पाया कि log_shipping_monitor_history_detail टेबल बहुत बड़ी थी। इस मामले में मैं sp_cleanup_log_shipping_history . चलाने में सक्षम था इतिहास को शुद्ध करने और msdb को सामान्य आकार में वापस लाने के लिए। 
 
अनुक्रमण
 

 एमएसडीबी में इंडेक्स को ऑप्टिमाइज़ करना आपके उपयोगकर्ता डेटाबेस जितना ही महत्वपूर्ण है। कई बार मुझे ऐसे क्लाइंट मिले हैं जो यूजर डेटाबेस को ऑप्टिमाइज़ कर रहे हैं लेकिन सिस्टम डेटाबेस को नहीं। चूंकि msdb डेटाबेस का उपयोग SQL सर्वर एजेंट, लॉग शिपिंग, सर्विस ब्रोकर, SSIS, बैकअप और पुनर्स्थापना, और अन्य प्रक्रियाओं द्वारा किया जाता है, इसलिए इंडेक्स अत्यधिक खंडित हो सकते हैं। सुनिश्चित करें कि आपकी अनुक्रमणिका अनुकूलन नौकरियों में आपके सिस्टम डेटाबेस, या कम से कम msdb भी शामिल हैं। मैंने देखा है कि इंडेक्स ऑप्टिमाइजेशन एमएसडीबी के भीतर अत्यधिक खंडित इंडेक्स से कई गीगाबाइट स्पेस को मुक्त करता है। 
 
सारांश
 

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