रखरखाव योजना का उपयोग करके ओला की लिपियों बनाम पेशेवरों और विपक्ष क्या हैं?

Question

क्या आप कृपया रखरखाव योजना पर ओला के समाधान का उपयोग करने के पेशेवरों और विपक्षों को समझने में मेरी मदद करेंगे? मैंने SQL पास ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 ) पर आधारित एक प्रस्तुति तैयार की है, जिसे मैं प्रस्तुत करूंगा।

मैं कुछ परिदृश्य भी तैयार कर रहा हूं जो ओला के समाधान पते और रखरखाव योजना समाधान नहीं करता है। क्या आप सभी इसे तकनीकी रूप से समझाने में मेरी मदद कर सकते हैं?

वैसे, हम उनमें से कम से कम 75% ओला के समाधान के साथ लगभग 150+ सर्वर (2008/2012/2014 का मिश्रण) का प्रबंधन कर रहे हैं। ब्रेंट ओजर का यह लेख मुझे पसंद आया। लेकिन एक टिप्पणी में, ब्रेंट ने हमारे पास मौजूद सर्वरों की संख्या के लिए स्क्रिप्ट आधारित समाधान का उपयोग करने की सिफारिश की है। https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

Comments

क्या हम बैकअप, इंडेक्स / स्टेट मेंटेनेंस, करप्शन चेकिंग या उपरोक्त सभी बातें कर रहे हैं?

— nkdbajoe

उन सभी को। ओला द्वारा संपूर्ण रखरखाव समाधान स्क्रिप्ट। मैंने ओला की लिपियों का उपयोग करके अनुरक्षण योजना में अनावश्यक सूचकांक पुनर्वित्त और सांख्यिकी अपडेट के मुद्दों को हल किया है। मैं बस वहाँ से बाहर अन्य DBAs से कुछ और तकनीकी बारूद चाहता था। धन्यवाद।

— पैट

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

— जिओ

क्या आपके पास यह दिखाने के लिए कोई डेटा है कि वे बेहतर हैं या आप सिर्फ उसी चीज़ के साथ जा रहे हैं जो आपको बेहतर लगता है? इस मुद्दे को हल करने का सबसे अच्छा तरीका कुछ प्रदर्शन डेटा प्राप्त करना है ताकि यह दिखाने में सक्षम हो कि एक विधि बेहतर क्यों है

— जो डब्ल्यू

इंडेक्स मेंटेनेंस के लिए, कई बार लिमिटिंग फैक्टर आपका SAN और स्टोरेज सब्मिट होता है। आपके SAN कॉन्फ़िगरेशन के आधार पर, आप समानांतर रीबिल्ड्स में कोई सुधार नहीं देख सकते हैं।

— Alen

Answer 1

मैंने यहाँ लिखा है

रखरखाव की योजनाएं खराब नहीं हैं, लेकिन जब आपका वातावरण बढ़ता है, तो सीमित लचीलापन और कार्यक्षमता जो रखरखाव योजना प्रदान करती है, पर्याप्त नहीं होगी।

अधिक जोड़ने के लिए,

• ओला के रखरखाव समाधान को व्यापक रूप से समुदाय और बड़े संगठनों में स्वीकार किया जाता है ।
• इसकी खुली खटास और मुद्दों को बहुत तेजी से तय किए जाने की संभावना के साथ github / मुद्दों पर उठाया जा सकता है ।
• इसका लचीला और स्केलेबल (भले ही आप इसे 100s सर्वर पर तैनात करना चाहते हैं बस dbatools से Install-DbaMainuranceSolution का उपयोग करें ।)
• Microsoft ने रखरखाव योजना GUI को ठीक करने में लगभग एक दशक का समय लिया जो कि छोटी गाड़ी थी :-)
• व्यापक प्रलेखन और अक्सर पूछे जाने वाले प्रश्न और नए एसक्यूएल सर्वर संस्करणों को समायोजित करने के लिए लगातार अद्यतन किया जाता है।
• में पूर्वावलोकन संस्करण है, तो आप भी समानांतर में बैकअप चला सकते हैं।
• इंडेक्स मेंटेनेंस सॉल्यूशन के लिए, आप प्रक्रिया को समय भी दे सकते हैं, जैसे अगर यह एक्स की मात्रा से अधिक चलता है, तो इसे निरस्त कर दें।

Answer 2

स्क्रिप्ट आधारित समाधान के प्रमुख लाभों में से एक तैनाती में आसानी है - ऐसा कुछ जो आपके मामले में स्पष्ट रूप से प्रासंगिक है, क्योंकि आपके पास 150+ सर्वर हैं। 150 सर्वरों में कई रखरखाव योजनाओं (यानी न्यूनतम 2 पर, सिस्टम डेटाबेस के लिए एक और उपयोगकर्ता डेटाबेस के लिए) को रोलआउट करने की कोशिश करना एक बुरा सपना होगा। जगह में एक बार उन्हें बनाए रखना केवल एक परेशानी के रूप में है।

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

हमारे मामले में, हमारे DEV वातावरण में हमारे पास लगभग 40 SQL इंस्टेंसेस हैं, और हम SSMS की कई-कनेक्शन-सुविधा के साथ संशोधित ओला स्क्रिप्ट का उपयोग करते हैं, जो एक क्लिक पर सभी 40 इंस्टेंस पर रखरखाव शासन में परिवर्तन रोलआउट करने में सक्षम हो। कोई भी विशेष मामला हमारे संशोधनों द्वारा नियंत्रित किया जाता है।

Answer 3

मैं उनकी स्क्रिप्ट्स का 100% निश्चित नहीं हूं, लेकिन कस्टम स्क्रिप्ट्स रखरखाव योजनाओं की तुलना में बेहतर हैं। बिल्ट इन प्लान्स में हर इंडेक्स को टेबल पर रखा जाएगा चाहे वह कितना भी छोटा सा क्यों न हो। यदि आपके पास हमेशा ऑन रहता है, तो यह यातायात का तूफान पैदा करेगा।

कस्टम स्क्रिप्ट आप 20% से अधिक या जो भी आपकी सीमा है, उसका पुनर्निर्माण कर सकते हैं। एक बार में कम अनुक्रमणिका का पुनर्निर्माण किया जाता है। कम हमेशा दूसरे के लिए भेजने के लिए डेटा पर। तेजी से पुनर्निर्माण क्योंकि आप कम अनुक्रमित पुनर्निर्माण कर रहे हैं। कम रखरखाव खिड़की की आवश्यकता है।

पिछली बार जब मैंने अनुरक्षण योजनाओं का उपयोग किया था, तो मेरे पास 300 मिलियन की पंक्ति तालिका थी और जब भी अनुक्रमणिका को बंद किया जाता है और लेन-देन लॉग ओवरफ़्लो के साथ समस्याएँ होती हैं, तो हमेशा ऑन रहती हैं। स्क्रिप्ट पर वापस चले गए और यह सब चला गया।

Comments

मैंने मूल रूप से 2007 के आसपास SQL ​​2005 के लिए अपना खुद का लिखा था। मैंने ऑन-लाइन पुस्तकों को आधार के रूप में इस्तेमाल किया और इसे थोड़ा बदल दिया। तब ऐसा लग रहा था कि अधिकांश लोग योजनाओं का उपयोग कर रहे थे और अब लगता है कि यह उल्टा हो गया है। और इससे पहले कि मैं डीबीए सामान करना शुरू कर देता, मेरे पहले पिछले डीबीए में एसक्यूएल 2000 के लिए कस्टम स्क्रिप्ट थे। केवल एक चीज जो मैंने अलग-अलग की थी, मैंने सब कुछ फिर से बनाया था। यह 20% या 30% से अधिक के पुनर्निर्माण के साथ-साथ कुछ भी पुनर्निर्माण करने के लिए तेज़ था। बैकअप के लिए हम हमेशा तीसरे पक्ष के उत्पादों का उपयोग किया

— एलेन

Answer 4

साथ ही उपरोक्त मेरा पसंदीदा कारण बैकअप के प्रकार को स्वचालित रूप से स्विच करने में सक्षम होना है, इसलिए एक नया डेटाबेस एक पूर्ण बैकअप पहली बार होगा जब लॉग बैकअप नौकरी अगले पूर्ण बैकअप नौकरी के चलने तक प्रतीक्षा करने के बजाय चलती है।

Answer 5

रखरखाव की योजना ज्यादातर समय ठीक कर देगी। ओला हैलेनग्रेन की पटकथा ज्यादातर समय ठीक रहेगी।

बहुत ही दुर्लभ मामलों में, आपको अपना खुद का विकास करना पड़ सकता है।

जैसा कि जोया ने कहा, यह नीचे आता है जिसके साथ आप काम करने में सबसे सहज हैं। यदि आपका सहकर्मी रखरखाव योजनाओं के साथ सबसे अधिक आरामदायक है, तो अपने घुटनों को एक मोड़ में क्यों प्राप्त करें?

यदि वह 20+ वर्षों से डेटाबेस कर रहा है, तो वह पहले से ही अपनी रखरखाव स्क्रिप्ट लिख चुका है। जिस समय आप गाड़ी चलाना सीख रहे थे, ठीक उसी समय, कार्गो शॉर्ट्स और फ़्लिपॉप्स में कुछ युवा गुंडा था और साथ में था "अरे, आप पुराने कोडर हैं, रखरखाव की योजना बेहतर है - और अपनी पैंट को नीचे खींचें, आप हास्यास्पद लग रहे हैं!" "।

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

तीन बातों पर विचार करें:

क्या वास्तव में आपके पर्यावरण पर लागू हॉलिनेग्रनाइट श्रेष्ठता के ये उदाहरण हैं?

यदि वह रखरखाव योजनाओं का उपयोग करता है तो क्या यह आपको एक वास्तविक समस्या पैदा करने वाला है?

यदि आप उसे हॉलेंगर की स्क्रिप्ट का उपयोग करने के लिए मनाते हैं और कोई समस्या है, तो क्या वह इसे स्वयं हल कर पाएगा या उसे आपको कॉल करना होगा?

Comments

पहले दो सवालों के जवाब हां। हमने पहले से ही रखरखाव योजनाओं के साथ मुद्दों को देखा है और मैंने ओला के समाधान के साथ हल किया है। उत्पादन सर्वर पर सिकोड़ लॉग कार्य (??) था जिसे मैंने तुरंत अक्षम कर दिया। तीसरा सवाल, मुझे नहीं पता। मुझे यकीन नहीं है कि वह रखरखाव योजना द्वारा बनाए गए मुद्दों को हल करने में सक्षम होगा या नहीं। जब मैंने उनसे पूछा कि क्या हम इसके साथ मुद्दों को देखते हैं, तो हमें क्या करना चाहिए? उनका जवाब Microsoft समर्थन को कॉल करना था। (()

— पाट

@Pat, आह, लगता है कि वह पीटर सिद्धांत के तहत अपनी सीमा को मार रहा है। उसे बेहतर बनाने की कोशिश में सावधान रहें - वह मदद की सराहना करने की संभावना नहीं है।

— जेम्स