एसक्यूएल सर्वर रखरखाव योजना - कार्य और निर्धारण पर सर्वोत्तम अभ्यास

Question

मुझे हमारे Sql Server 2005 डेटाबेस के लिए एक रखरखाव योजना तैयार करने का काम सौंपा गया है। मुझे पता है कि बैकअप के लिए मैं हर 15 मिनट में एक दैनिक पूर्ण डेटाबेस बैकअप और ट्रांजेक्शनल लॉग बैकअप करना चाहता हूं। मेरी समस्या यह पता लगाने की है कि मैं कौन से अन्य कार्य करना चाहता हूं और मुझे उन्हें कितनी बार करना चाहिए।

इसलिए, अभी तक मेरे मन में यही है। मुझे सही करें अगर मेरी सोच में कोई खामियां हैं या ऐसा करने का बेहतर तरीका है।

1. बैकअप - सभी तालिकाएँ, पूर्ण बैकअप (दैनिक)
2. बैकअप - चयनित तालिकाएँ, पूर्ण बैकअप (प्रति घंटा)
3. बैकअप - लेन-देन लॉग (हर 15 मिनट में)
4. डेटाबेस अखंडता की जाँच करें (दैनिक)
5. सूचकांक का पुनर्गठन (दैनिक)
6. अद्यतन आँकड़े (दैनिक)
7. डेटाबेस सिकोड़ें (साप्ताहिक)
8. अनुक्रमणिका (साप्ताहिक) का पुनर्निर्माण करें
9. रखरखाव सफाई (दैनिक)

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

Comments

आप डेटाबेस को सिकोड़ना नहीं चाहते हैं, यह फ़ाइल विखंडन का कारण बन सकता है

— एंडी तजहोनो

वर्तमान डेटाबेस 30 जीबी से अधिक है, इसलिए मैंने सोचा कि एक हटना मदद करेगा। आपके इनपुट के लिए धन्यवाद, एंडी।

— जोश

सप्ताह में एक बार एक अलग साप्ताहिक नौकरी बनाएं और आंकड़े अपडेट करें।

— माइकल रिले - AKA Gunny

इसलिए मुझे दैनिक सांख्यिकीय अपडेट को साप्ताहिक में बदलना चाहिए?

— जोश

इस विषय पर एक मुफ्त ईबुक जो मुझे बहुत उपयोगी लगी है : ब्रैड की श्योर गाइड टू एसक्यूएल सर्वर रखरखाव योजनाएं ।

Answer 1

जोश,

यह सभी डीबीए के लिए एक बहुत ही सामान्य कार्य है और सही उत्तर हर एक और प्रत्येक सर्वर के लिए समान नहीं है। अन्य चीजों के रूप में, यह इस बात पर निर्भर करता है कि आपको क्या चाहिए।

सबसे निश्चित रूप से आप पहले से ही सुझाए गए "डेटाबेस को सिकोड़ें" चलाना नहीं चाहते हैं। प्रदर्शन के लिए इसकी EVIL और नीचे दिए गए रेफरी आपको दिखाएंगे कि क्यों। यह डिस्क और साथ ही सूचकांक विखंडन का कारण बनता है और इससे प्रदर्शन समस्याएं हो सकती हैं। आप पूर्व-आबंटन द्वारा डेटा और लॉग फ़ाइलों के लिए एक बड़े आकार से बेहतर हैं ताकि ऑटोग्रॉथ किक-इन न हो।

मुझे आपका # 2 समझ नहीं आया। चयनित टेबल पूर्ण बैकअप। क्या आप इस पर अधिक विस्तार कर सकते हैं?

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

जब आप अनुक्रमणिका का पुन: निर्माण करते हैं, तो अनुक्रमणिका के आंकड़े फुलस्कैन के साथ अपडेट किए जाते हैं, लेकिन यदि आप उसके बाद के आंकड़े अपडेट करते हैं, तो उन्हें फिर से एक डिफ़ॉल्ट नमूने के साथ अपडेट किया जाएगा (जो कि कई कारकों पर निर्भर करता है, आमतौर पर तालिका का 5% जब तालिका आकार> 8 एमबी) जो प्रदर्शन के मुद्दों को जन्म दे सकता है। आपके पास जो संस्करण है, उसके आधार पर, आप ऑनलाइन इंडेक्स रिबर्ड कर सकते हैं। इस गतिविधि को करने का सही तरीका विखंडन की मात्रा की जांच करना है और इस पर निर्भर करता है कि या तो सूचकांक पुनर्निर्माण या सूचकांक पुनर्गठन + अद्यतन आँकड़े हैं। और आप यह भी पहचान सकते हैं कि किन तालिकाओं को आँकड़ों को बार-बार अद्यतन करने की आवश्यकता है और आँकड़ों को अधिक बार अद्यतन करने का प्रयास करें।

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

Ref: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

यह आपके प्रश्न का एक व्यापक उत्तर नहीं है बल्कि एक अच्छा प्रारंभिक बिंदु है। HTH और हमें बताएँ कि क्या आपके पास कोई अतिरिक्त प्रश्न / टिप्पणी है।

Comments

शंकर, आपके इनपुट के लिए धन्यवाद। मैंने सोचा था कि कुछ तालिकाओं का प्रति घंटा बैकअप करना (जो तालिकाएँ जो अक्सर बदलती नहीं हैं) को छोड़ कर प्रति घंटा बैकअप पर कुछ बैकअप समय बचाने के लिए एक बेहतर दृष्टिकोण हो सकता है। यहाँ बड़ा मुद्दा यह है कि मैं वास्तव में 15 मिनट के लेन-देन लॉग बैकअप चाहता हूं क्योंकि हमारी स्थिति में डेटा हानि के कानूनी नुकसान हो सकते हैं। पूर्ण बैकअप आवृत्ति के लिए, प्रति घंटा सबसे अच्छा होगा, लेकिन मुझे सिस्टम पर बहुत अधिक कर लगाने से डर लगता है। मैंने पोस्ट करने से पहले उस स्क्रिप्ट को देखा, लेकिन मुझे इसे आज़माने का मौका नहीं मिला।

— जोश

Answer 2

मैं अपना अनुभव साझा करूंगा, भले ही आपने पहले ही एक उत्तर स्वीकार कर लिया हो। शायद यह उपयोगी होगा :-)।

1. पूर्ण दैनिक बैकअप (दैनिक) - महान, लेकिन कुछ पूर्वनिर्धारित समय के बाद अंतरिक्ष की जांच करना और पुरानी फाइलों को हटाना न भूलें।
2. बैकअप चयनित तालिकाओं (प्रति घंटा) - समझ में नहीं आता कि आपको इसकी आवश्यकता क्यों है, आप बेहतर अंतर वाले बैकअप के साथ जाएंगे। आप केवल कुछ तालिकाओं का बैकअप कैसे लेते हैं: SSIS, स्क्रिप्ट, bcp? अलग बैकअप के बारे में, इसे अक्सर शेड्यूल न करें, क्योंकि आप लॉग बैकअप भूमिका को चुरा लेंगे।
3. लेन-देन लॉग बैकअप (हर 15 मिनट) - महान, क्या आप सभी डेटाबेस के लिए आवश्यक हैं? क्या सभी डेटाबेस पूर्ण पुनर्प्राप्ति मॉडल का उपयोग करते हैं या नहीं?
4. DB अखंडता की जाँच करें - हाँ, लेकिन आपको यह सुनिश्चित करने की आवश्यकता है कि आप पर्यावरण को नहीं मारें। DBCC चेक स्टेटमेंट संसाधनों पर बहुत स्वार्थी हैं और पूर्ण dbs को स्कैन करते हैं, इसलिए उन्हें ऑफ घंटे के दौरान शेड्यूल करने की आवश्यकता होती है।
5. सूचकांक (दैनिक) का पुनर्गठन करें - इसे बाध्य न करें, यदि आवश्यक हो तो ही करें। सूचकांक डीएमवी के विखंडन के बारे में जाँच करें और केवल जरूरतों के आधार पर पुनर्गठन करें। मैं एक ही साप्ताहिक कार्य पर सभी सूचकांक और आँकड़ों के संचालन को आगे बढ़ाता हूँ।
6. अद्यतन आँकड़े (दैनिक) - कृपया मेरे पिछले प्रश्न का उत्तर देखें । हर दिन केवल सभी आँकड़ों के अद्यतन को मजबूर करने के बजाय, आप बेहतर जाँच करेंगे जब आँकड़ों को अंतिम रूप से अद्यतन किया गया था और केवल कुछ मामलों में ही उन्हें अद्यतन किया गया था।
7. डेटाबेस सिकोड़ें (साप्ताहिक) - ओह, नहीं। कृपया फ़ाइल के सिकुड़ने के संबंध में पॉल रान्डल का लेख पढ़ें ।
8. सूचकांक (साप्ताहिक) का पुनर्निर्माण करें - 5 देखें।

9. रखरखाव क्लीनअप (दैनिक) - ठीक है।

10. आप बेहतर तरीके से अपने बैकअप्स को सत्यापित करने के लिए एक कार्य जोड़ेंगे - RESTORE कमांड का एक संस्करण है (वेरिफाइली .. अगर मुझे सही याद है) - चलो साप्ताहिक कहता हूं, हालांकि मैं इसे दैनिक रूप से पसंद करता हूं।

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

Comments

क्या खंडित अनुक्रमित को SQL सर्वर पर "बुरी चीज" माना जाता है? जहां मैं डीफ़्रेग्मेंटिंग इंडेक्स जीता हूं, प्रदर्शन को मार सकता है और वैसे भी आमतौर पर बहुत बेकार होता है

— जैक डगलस

@ जेक - बंद खंडित अनुक्रमित एक बुरी बात हैं :-)। उदाहरण सहित खंडित अनुक्रमितों के बारे में ब्रेंट ओजर का लेख देखें । अपने लेख के अंदर इस्तेमाल किए गए एक एमएस श्वेत पत्र का एक उद्धरण: "सूचकांक विखंडन ने 13% से 460 के बीच अपने सिस्टम को धीमा कर दिया। ओच।" और यह ध्यान रखें कि टॉम का लेख पीछे से है, जब वह नियम आधारित ऑप्टिमाइज़र का उपयोग कर रहा था, न कि बाद के लागत आधारित ऑप्टिमाइज़र का।

— मैरियन

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

— जैक डगलस

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

— मैरियन

Answer 3

देर से जवाब लेकिन अन्य पाठकों के लिए उपयोग किया जा सकता है।

कृपया, ध्यान रखें कि बहुत सारे रखरखाव या रिपोर्टिंग कार्य हैं, आप बना सकते हैं, जो उनके साथ जुड़े हुए जोखिमों को वहन करते हैं।

क्या होगा जब एक ड्राइव रोजाना किए गए डिफरेंशियल बैकअप के दौरान भर जाता है? और क्या होगा अगर एक इंडेक्स पुनर्निर्माण कार्य असामान्य रूप से लंबा चलता है? यदि डेटा लोड प्रक्रिया व्यापक संसाधन विवाद का कारण बनती है, तो उनके घुटनों तक सामान्य ऑपरेशन कैसे लाएंगे? ये सभी नियोजित घटनाएँ हैं, फिर भी जिन प्रक्रियाओं को हम सुरक्षित करने का प्रयास कर रहे हैं, उनमें काफी व्यवधान पैदा कर सकते हैं।

हमेशा इस बात पर विचार करें कि विभिन्न नौकरियां कैसे बातचीत करती हैं और उन्हें ऐसे समय देती हैं कि संवेदनशील या संसाधन गहन कार्यों में कोई ओवरलैप नहीं होता है।

मैं पहले इस लेख को पढ़ने का सुझाव देता हूं: http://www.sqlshack.com/removing-the-risk-from-important-mainurance-tasks-in-sql-server/

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

Answer 4

1. ठीक लगता है

2. आप यहाँ विभेदक बैकअप करने से लाभान्वित हो सकते हैं। उन्हें निश्चित रूप से देखें

3. ठीक लगता है

4. ठीक लगता है

5. जैसा कि पहले कहा गया है, डेटाबेस सिकुड़ते खराब हैं क्योंकि वे आपके डेटा और लॉग फ़ाइलों के भौतिक विखंडन का निर्माण करते हैं, इस प्रकार अधिक यादृच्छिक IO पढ़ता है।

5, 6 और 8: निम्नलिखित देखें।

ये वास्तव में हाथों से चलते हैं, क्योंकि अनुक्रमित तारीख के आंकड़ों पर निर्भर करते हैं, और इन कार्यों का क्रम काफी महत्वपूर्ण है। बेसलाइन विधि जो मैं नियोजित करता हूं, जो कि आमतौर पर सभी के लिए काम नहीं कर सकता है, यह है कि मैं सूचकांक रखरखाव के दो दौर करता हूं। पहले, मैं क्लस्टर किए गए अनुक्रमित और फिर गैर-अनुक्रमित अनुक्रमित करता हूं। दोनों के लिए मेरे द्वारा नियोजित विधि निम्न है। यदि कोई अनुक्रमणिका काफी बड़ी है और पर्याप्त खंडित है (sysinos_db_index_physical_stats), तो मैं अनुक्रमणिका (जिसमें पूर्ण स्कैन के साथ एक आँकड़े अद्यतन भी शामिल है) का पुनर्निर्माण करेगा। यदि एक इंडेक्स या तो पुनर्निर्माण के लिए बहुत छोटा है या पुनर्निर्माण के लिए पर्याप्त रूप से खंडित नहीं है (100 पृष्ठों से कम और 5% और 15% विखंडन के बीच), तो मैं सबसे पहले एक इंडेक्स का पुनर्गठन करूंगा। मैं फिर पूर्ण स्कैन के साथ एक आँकड़े अद्यतन प्रदर्शन करूँगा।

अब, यह सूचकांक आँकड़ों को शामिल करता है, लेकिन स्तंभ आँकड़ों के लिए कुछ भी करने की उपेक्षा करता है। साप्ताहिक रूप से, मैं कॉलम के आँकड़े अपडेट करूँगा।

मुझे उम्मीद है कि इसने किसी तरह से मदद की है!

Answer 5

मैं आपके "डेटा लॉस पर यहाँ कानूनी रूप से नुकसान पहुँचा सकता हूँ" टिप्पणी पर झुका हुआ था।

फिर, आप निश्चित रूप से एक शक्तिशाली 3 पार्टी टूल (डीपीएम की तरह) प्राप्त करना चाहते हैं जो बैकअप को संभाल सकता है (और फ्लैश और न्यूनतम फ्यूशिंग में भयावह घटनाओं से उबर सकता है) तेजी से और किसी भी स्क्रिप्ट से बेहतर है जिसे आप इंटरनेट से खींच सकते हैं।

बैकअप होना एक बात है। यह जानना कि आपातकाल में उनका उपयोग कैसे किया जाता है।

यह मत भूलो कि यदि आप एक बड़ी विफलता के बाद बैकअप को बहाल करने के बिंदु पर हैं, तो आप शायद पहले से ही तनाव और दबाव के बोझ के नीचे हैं। आपको 12 लेन-देन लॉग फ़ाइलों के साथ खोद-खोदकर और फिर से लिखने के विवरण के अतिरिक्त बोझ की आवश्यकता नहीं है ... और प्रार्थना करना यह आपको विफल नहीं करता है ...

अपने कार्यस्थल पर, मैं DPM का उपयोग करके पिछले सप्ताह के लिए 5 मिनट की अवधि में किसी भी बिंदु पर 350Gb डेटाबेस को पुनर्प्राप्त / पुनर्स्थापित कर सकता हूं। GUI इंटरफ़ेस के साथ। मेरी किताब में, इसके लायक।

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

अंत में, मैं अपनी आवाज़ को "कभी-कभी आपकी फ़ाइलों को स्वचालित रूप से सिकोड़ना नहीं" समूह में जोड़ता हूं। फ़ाइल श्रिंक केवल एक उपकरण है जो छिटपुट रूप से उपयोग किया जाता है जब कोई अनियमित घटना होती है जो आपके लॉग या DB फ़ाइलों (अनंत लूप या ऐसे) को ओवरगेट करती है। यह एक रखरखाव उपकरण नहीं माना जाता है। यदि आपके पास डिस्क स्थान दबाव है, तो हटना केवल अपरिहार्य को देरी करेगा।