मेरी पिछली पोस्ट में, मैंने सक्रिय स्वास्थ्य जांच को कवर करने के लिए एक श्रृंखला शुरू की जो आपके SQL सर्वर के लिए महत्वपूर्ण हैं। हमने डिस्क स्थान के साथ शुरुआत की, और इस पोस्ट में हम रखरखाव कार्यों पर चर्चा करेंगे। एक डीबीए की मूलभूत जिम्मेदारियों में से एक यह सुनिश्चित करना है कि निम्नलिखित रखरखाव कार्य नियमित रूप से चलते हैं:
- बैकअप
- अखंडता जांच
- इंडेक्स रखरखाव
- आंकड़े अपडेट
मेरी शर्त है कि इन कार्यों को प्रबंधित करने के लिए आपके पास पहले से ही नौकरियां हैं। और मैं यह भी शर्त लगाऊंगा कि यदि कोई कार्य विफल हो जाता है तो आपको और आपकी टीम को ईमेल करने के लिए आपके पास सूचनाएं कॉन्फ़िगर की गई हैं। यदि दोनों सत्य हैं, तो आप रखरखाव के बारे में पहले से ही सक्रिय हैं। और अगर आप दोनों नहीं कर रहे हैं, तो इसे अभी ठीक करना है - जैसे, इसे पढ़ना बंद करें, ओला हॉलेंग्रेन की स्क्रिप्ट डाउनलोड करें, उन्हें शेड्यूल करें, और सुनिश्चित करें कि आपने सूचनाएं सेट की हैं। (सूचकांक रखरखाव के लिए विशिष्ट एक अन्य विकल्प, जिसे हम ग्राहकों को भी सुझाते हैं, वह है SQL संतरी विखंडन प्रबंधक।)
यदि आप नहीं जानते कि आपके कार्य विफल होने पर आपको ईमेल करने के लिए सेट हैं या नहीं, तो इस क्वेरी का उपयोग करें:
चुनें [नाम], [विवरण] [डीबीओ] से। [sysjobs] जहां [सक्षम] =1 और [notify_level_email] [नाम] द्वारा आदेश (2,3) में नहीं;हालांकि, रखरखाव के बारे में सक्रिय होना एक कदम आगे जाता है। यह सुनिश्चित करने के अलावा कि आपकी नौकरियां चलती हैं, आपको यह जानना होगा कि उन्हें कितना समय लगता है। इसकी निगरानी के लिए आप msdb में सिस्टम टेबल का उपयोग कर सकते हैं:
चुनें [जे]। [नाम] एएस [जॉबनाम], [एच]। [स्टेप_आईडी] एएस [स्टेपआईडी], [एच]। ([h].[run_date],8, 0) AS DATETIME), 121) AS [RunDate], STUFF(STUFF(RIGHT('000000' + CAST ( [h].[run_time] AS VARCHAR(6)) , 6),5,0,':'),3,0,':') AS [रनटाइम], (([run_duration]/10000*3600 + ([run_duration]/100)%100*60 + [run_duration] %100 + 31 ) / 60) AS [RunDuration_Minutes], CASE [h]। [run_status] जब 0 तब 'विफल' जब 1 तब 'सफल' हुआ जब 2 फिर 'पुन:प्रयास करें' जब 3 तब 'रद्द' जब 4 फिर 'इन' प्रगति 'अंत के रूप में [निष्पादन स्थिति], [एच]। [संदेश] के रूप में [संदेश उत्पन्न] [एमएसडीबी] से। [डीबीओ]। [sysjobhistory] [एच] आंतरिक शामिल हों [एमएसडीबी]। [डीबीओ]। [sysjobs] [जे] चालू [h]।या, यदि आप ओला की स्क्रिप्ट और लॉगिंग जानकारी का उपयोग कर रहे हैं, तो आप उसकी कमांडलॉग तालिका को क्वेरी कर सकते हैं:
चुनें [डेटाबेसनाम], [कमांड टाइप], [स्टार्टटाइम], [एंडटाइम], DATEDIFF (मिनट, [स्टार्टटाइम], [एंडटाइम]) AS [Duration_Minutes] [मास्टर] से। [डीबीओ]। [कमांडलॉग]कहां [ डेटाबेसनाम] ='एडवेंचरवर्क्स2014'और [कमांड] 'बैकअप डेटाबेस%' की तरह [स्टार्टटाइम] द्वारा ऑर्डर करें;उपरोक्त स्क्रिप्ट AdventureWorks2014 डेटाबेस के लिए प्रत्येक पूर्ण बैकअप के लिए बैकअप अवधि को सूचीबद्ध करती है। आप उम्मीद कर सकते हैं कि समय के साथ रखरखाव कार्य अवधि धीरे-धीरे बढ़ेगी, जैसे-जैसे डेटाबेस बड़ा होता जाएगा। जैसे, आप अवधि में बड़ी वृद्धि, या अप्रत्याशित कमी की तलाश कर रहे हैं। उदाहरण के लिए, मेरे पास 30 मिनट से कम की औसत बैकअप अवधि वाला क्लाइंट था। अचानक, बैकअप में एक घंटे से अधिक समय लगने लगता है। डेटाबेस आकार में महत्वपूर्ण रूप से नहीं बदला था, उदाहरण या डेटाबेस के लिए कोई सेटिंग नहीं बदली थी, हार्डवेयर या डिस्क कॉन्फ़िगरेशन के साथ कुछ भी नहीं बदला था। कुछ सप्ताह बाद, बैकअप अवधि वापस आधे घंटे से भी कम समय तक कम हो गई। उसके एक महीने बाद, वे फिर से ऊपर चले गए। हमने अंततः बैकअप अवधि में परिवर्तन को क्लस्टर नोड्स के बीच विफलताओं से संबद्ध किया। एक नोड पर, बैकअप में आधे घंटे से भी कम समय लगा। दूसरी ओर, उन्होंने एक घंटे से अधिक समय लिया। एनआईसी और सैन फैब्रिक के विन्यास की थोड़ी जांच और हम समस्या का पता लगाने में सक्षम थे।
CHECKDB संचालन के निष्पादन के औसत समय को समझना भी महत्वपूर्ण है। यह कुछ ऐसा है जिसके बारे में पॉल हमारे उच्च उपलब्धता और आपदा वसूली विसर्जन कार्यक्रम में बात करता है:आपको पता होना चाहिए कि CHECKDB को सामान्य रूप से चलने में कितना समय लगता है, ताकि यदि आप भ्रष्टाचार पाते हैं और आप पूरे डेटाबेस पर एक चेक चलाते हैं, तो आप जानते हैं कि इसे कितने समय तक चलना चाहिए CHECKDB को पूरा करने के लिए लें। जब आपका बॉस पूछता है, "कितना समय तक हमें समस्या की सीमा का पता चलेगा?" आप प्रतीक्षा करने के लिए आवश्यक न्यूनतम समय का मात्रात्मक उत्तर प्रदान करने में सक्षम होंगे। यदि CHECKDB सामान्य से अधिक समय लेता है, तो आप जानते हैं कि इसे कुछ मिला है (जो जरूरी नहीं कि भ्रष्टाचार हो; आपको हमेशा चेक को समाप्त होने देना चाहिए)।
अब, यदि आप सैकड़ों डेटाबेस प्रबंधित कर रहे हैं, तो आप उपरोक्त क्वेरी को प्रत्येक डेटाबेस या प्रत्येक कार्य के लिए नहीं चलाना चाहते हैं। इसके बजाय, हो सकता है कि आप ऐसी नौकरियां ढूंढना चाहें जो औसत अवधि से कुछ प्रतिशत कम हों, जिन्हें आप इस क्वेरी का उपयोग करके प्राप्त कर सकते हैं:
चुनें [जे]। [नाम] एएस [जॉबनाम], [एच]। [स्टेप_आईडी] एएस [स्टेपआईडी], [एच]। ([h].[run_date],8, 0) AS DATETIME), 121) AS [RunDate], STUFF(STUFF(RIGHT('000000' + CAST ( [h].[run_time] AS VARCHAR(6)) , 6),5,0,':'),3,0,':') AS [रनटाइम], (([run_duration]/10000*3600 + ([run_duration]/100)%100*60 + [run_duration] %100 + 31 ) / 60) AS [RunDuration_Minutes], [avdur]। [Avg_RunDuration_Minutes] [dbo] से। [sysjobhistory] [h]INNER JOIN [dbo]। [sysjobs] [j] ऑन [h]। ] =[j]। [job_id] INNER जॉइन (चुनें [j]। [नाम] AS [जॉबनाम], AVG (([run_duration]/10000*3600 + ([run_duration]/100)%100*60 + [ run_duration]% 100 + 31 ) / 60)) AS [Avg_RunDuration_Minutes] [dbo] से। [sysjobhistory] [h] इनर जॉइन [dbo]। [sysjobs] [j] ऑन [h]। .[job_id] जहां [step_id] =0 और CONVERT(DATE, RTRIM(h.run_date))>=DATEADD(DAY, -60, GETDATE()) GROUP BY [j].[name]) AS [avdur] ON [अवदुर]। [जॉबनाम] =[जे]। [नाम] जहां [स्टेप_आईडी] =0AND ( ([run_duration]/10000*3600 + ([run_duration]/100)%100*60 + [run_duration]%100 + 31 ) / 60)> ([avdur].[Avg_RunDuration_Minutes] + ([avdur]। * .25)) [जे] द्वारा आदेश। [नाम], [रनडेट];यह क्वेरी उन नौकरियों को सूचीबद्ध करती है जिनमें औसत से 25% अधिक समय लगा। अपनी इच्छित विशिष्ट जानकारी प्रदान करने के लिए क्वेरी में कुछ बदलाव की आवश्यकता होगी - छोटी अवधि (जैसे 5 मिनट से कम) वाली कुछ नौकरियां दिखाई देंगी यदि वे बस कुछ अतिरिक्त मिनट लेते हैं - यह चिंता का विषय नहीं हो सकता है। फिर भी, यह प्रश्न एक अच्छी शुरुआत है, और महसूस करें कि विचलन खोजने के कई तरीके हैं - आप प्रत्येक निष्पादन की तुलना पिछले एक से भी कर सकते हैं और उन नौकरियों की तलाश कर सकते हैं जिनमें पिछले की तुलना में एक निश्चित प्रतिशत अधिक समय लगता है।
जाहिर है, संभावित समस्याओं के लिए उपयोग करने के लिए नौकरी की अवधि सबसे तार्किक पहचानकर्ता है - चाहे वह बैकअप नौकरी हो, अखंडता जांच हो, या नौकरी जो विखंडन को हटा दे और आंकड़ों को अपडेट करे। मैंने पाया है कि अवधि में सबसे बड़ा बदलाव आमतौर पर विखंडन को हटाने और आंकड़ों को अद्यतन करने के कार्यों में होता है। रीऑर्ग बनाम पुनर्निर्माण के लिए आपके थ्रेसहोल्ड और आपके डेटा की अस्थिरता के आधार पर, आप अधिकतर रीगॉग के साथ दिन जा सकते हैं, फिर अचानक कुछ इंडेक्स बड़े टेबल के लिए किक करते हैं, जहां वे पुनर्निर्माण औसत अवधि को पूरी तरह से बदलते हैं। आप कुछ इंडेक्स के लिए अपनी थ्रेसहोल्ड बदलना चाह सकते हैं, या भरण कारक को समायोजित कर सकते हैं, ताकि इंडेक्स और विखंडन के स्तर के आधार पर पुनर्निर्माण अधिक बार या कम बार हो। इन समायोजनों को करने के लिए, आपको यह देखने की आवश्यकता है कि प्रत्येक इंडेक्स को कितनी बार पुनर्निर्मित या पुनर्गठित किया जाता है, जो आप केवल तभी कर सकते हैं जब आप ओला की स्क्रिप्ट का उपयोग कर रहे हों और कमांडलॉग टेबल पर लॉगिंग कर रहे हों, या यदि आपने अपना समाधान रोल किया हो और लॉगिंग कर रहे हों प्रत्येक reorg या पुनर्निर्माण। कमांडलॉग टेबल का उपयोग करके इसे देखने के लिए, आप यह देखने के लिए जांच कर शुरू कर सकते हैं कि कौन से इंडेक्स सबसे अधिक बार बदले जाते हैं:
चुनें [डेटाबेसनाम], [ऑब्जेक्टनाम], [इंडेक्सनाम], [मास्टर] से COUNT(*)। INDEX%' ग्रुप बाय [डेटाबेसनाम], [ऑब्जेक्टनाम], [इंडेक्सनाम] ऑर्डर बाय COUNT(*) DESC;इस आउटपुट से, आप यह देखना शुरू कर सकते हैं कि किन तालिकाओं (और इसलिए अनुक्रमणिका) में सबसे अधिक अस्थिरता है, और फिर यह निर्धारित कर सकते हैं कि पुनर्रचना बनाम पुनर्निर्माण के लिए सीमा को समायोजित करने की आवश्यकता है, या भरण कारक को संशोधित करने की आवश्यकता है।
जीवन को आसान बनाना
अब, जब तक आप SQL संतरी इवेंट मैनेजर (EM) का उपयोग कर रहे हैं, तब तक अपने स्वयं के प्रश्नों को लिखने की तुलना में एक आसान समाधान है। उपकरण एक उदाहरण पर सेट किए गए सभी एजेंट कार्यों की निगरानी करता है, और कैलेंडर दृश्य का उपयोग करके, आप जल्दी से देख सकते हैं कि कौन से कार्य विफल हुए, रद्द किए गए, या सामान्य से अधिक समय तक चले:
SQL संतरी इवेंट मैनेजर कैलेंडर दृश्य (फ़ोटोशॉप में जोड़े गए लेबल के साथ)
आप यह देखने के लिए अलग-अलग निष्पादन में ड्रिल कर सकते हैं कि इसे चलाने में कितना समय लगा, और आसान रनटाइम ग्राफ़ भी हैं जो आपको अवधि की विसंगतियों या विफलता की स्थिति में किसी भी पैटर्न को जल्दी से देखने की अनुमति देते हैं। इस मामले में, मैं देख सकता हूं कि हर 15 मिनट में, इस विशिष्ट कार्य के लिए रनटाइम की अवधि लगभग 400% बढ़ गई:
SQL संतरी इवेंट मैनेजर रनटाइम ग्राफ
यह मुझे एक सुराग देता है कि मुझे अन्य अनुसूचित नौकरियों को देखना चाहिए जो यहां कुछ समवर्ती मुद्दों का कारण बन सकते हैं। मैं कैलेंडर पर फिर से ज़ूम आउट कर सकता था यह देखने के लिए कि एक ही समय में अन्य कार्य क्या चल रहे हैं, या मुझे यह पहचानने की भी आवश्यकता नहीं है कि यह कुछ रिपोर्टिंग या बैकअप कार्य है जो इस डेटाबेस के विरुद्ध चलता है।
सारांश
मैं शर्त लगा सकता हूं कि आप में से अधिकांश के पास पहले से ही आवश्यक रखरखाव कार्य हैं, और आपके पास नौकरी की विफलता के लिए सूचनाएं भी हैं। यदि आप अपनी नौकरियों के लिए औसत अवधि से परिचित नहीं हैं, तो यह सक्रिय होने में आपका अगला कदम है। नोट:आपको यह देखने के लिए भी जांच करनी पड़ सकती है कि आप कितने समय तक नौकरी के इतिहास को बरकरार रख रहे हैं। नौकरी की अवधि में विचलन की तलाश करते समय, मैं कुछ हफ्तों के बजाय कुछ महीनों के डेटा को देखना पसंद करता हूं। आपको उन रन टाइम को याद रखने की आवश्यकता नहीं है, लेकिन एक बार जब आप सत्यापित कर लेते हैं कि आपके पास शोध के लिए इतिहास का उपयोग करने के लिए पर्याप्त डेटा है, तो नियमित रूप से विविधताओं की तलाश शुरू करें। एक आदर्श परिदृश्य में, बढ़ा हुआ रन टाइम आपको संभावित समस्या के प्रति सचेत कर सकता है, जिससे आप अपने उत्पादन परिवेश में कोई समस्या आने से पहले इसका समाधान कर सकते हैं।
