नियमित SQL सर्वर सर्विसिंग के लिए केस बनाना

SQL सर्वर समुदाय में SQL सर्वर के लिए सर्विस पैक (SP) और संचयी अद्यतन (CU) स्थापित करने की समझदारी के बारे में कुछ विवाद चल रहे हैं। कई अलग-अलग बुनियादी स्थितियां हैं जो संगठन आमतौर पर इस विषय पर लेते हैं, जैसा कि नीचे सूचीबद्ध है:

1. संगठन नियमित रूप से सर्विस पैक और संचयी अपडेट स्थापित करता है
2. संगठन सर्विस पैक स्थापित करता है, लेकिन संचयी अद्यतन स्थापित नहीं करता है
3. संगठन सर्विस पैक या संचयी अद्यतन स्थापित नहीं करता है

पहला मामला एक संगठन है जो पूरी तरह से परीक्षण और कार्यान्वयन प्रक्रिया का उपयोग करके SQL सर्वर सर्विस पैक और SQL सर्वर संचयी अपडेट दोनों के साथ उचित रूप से वर्तमान रहने का प्रयास करेगा। मेरी राय में यह सबसे अच्छी नीति है। मेरी स्थिति यह है कि सर्विस पैक और संचयी अपडेट (जब तक आपके पास परीक्षण और कार्यान्वयन प्रक्रियाएं और उस नीति का समर्थन करने के लिए आवश्यक बुनियादी ढांचा है) दोनों के साथ अप-टू-डेट रहकर आपके संगठन की बेहतर सेवा होती है।

दूसरा मामला एक संगठन है जो (शायद कुछ देरी के बाद), SQL सर्वर सर्विस पैक स्थापित करेगा, लेकिन वे किसी भी कारण से SQL सर्वर संचयी अद्यतन स्थापित नहीं करेंगे। यह पहले मामले जितना अच्छा नहीं है, लेकिन तीसरे मामले से काफी बेहतर है।

तीसरे मामले में, कुछ संगठन किसी भी कारण से कभी भी कोई SQL सर्वर सर्विस पैक या SQL सर्वर संचयी अद्यतन स्थापित नहीं करते हैं। कुछ मामलों में, वे वास्तव में SQL सर्वर के प्रमुख संस्करण के निर्माण (RTM) निर्माण के लिए मूल रिलीज़ पर बने रहते हैं, जो वे चल रहे हैं, उदाहरण के जीवन के लिए। कई कारणों से यह सबसे कम वांछनीय नीति है।

Microsoft के पास SQL ​​​​सर्वर के एक विशेष संस्करण के लिए कोड की शाखाओं (या तो RTM शाखा या बाद की सर्विस पैक शाखा) को सेवानिवृत्त करने की नीति है, जब यह दो शाखाएँ पुरानी हो। उदाहरण के लिए, जब SQL Server 2008 R2 सर्विस पैक 2 जारी किया गया था, तो मूल RTM शाखा (CU स्तर की परवाह किए बिना) सेवानिवृत्त हो गई थी, और यह एक "असमर्थित सर्विस पैक" बन गई। इसका अर्थ यह है कि उस शाखा के लिए कोई और हॉटफ़िक्स या संचयी अपडेट नहीं होंगे, और जब तक आप अपने इंस्टेंस पर एक समर्थित सर्विस पैक स्थापित नहीं करते हैं, तब तक आपको Microsoft CSS से केवल सीमित समस्या निवारण समर्थन प्राप्त होगा।

इस कारण कि SQL सर्वर रखरखाव आस्थगित है

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

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

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

SQL सर्वर को नियमित रूप से बनाए रखने के कारण

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

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

संचयी अद्यतन कई हॉटफिक्स (आमतौर पर लगभग 10-50 हॉटफिक्स से कहीं भी) के रोलअप होते हैं जो हर आठ सप्ताह में रिलीज़ होते हैं। ये संचयी अद्यतन वास्तव में संचयी होते हैं (जैसा कि नाम से पता चलता है), इसलिए जब आप संचयी अद्यतन स्थापित करते हैं तो आपको अपने संस्करण और कोड की शाखा (RTM, SP1, SP2, आदि) के लिए पहले जारी किए गए सभी हॉटफिक्स मिलेंगे। इसका अर्थ यह है कि संगठनों के बारे में सामान्य कथन "केवल उन विशिष्ट मुद्दों को ठीक करने के लिए संचयी अपडेट लागू करना जो वे अनुभव कर रहे हैं" वास्तव में वास्तविक जीवन में विशेष रूप से मान्य नहीं है।

उदाहरण के लिए, यदि आप SQL Server 2012 सर्विस पैक 1 (11.0.3000) का RTM बिल्ड चला रहे थे, और आपने SQL Server 2012 सर्विस पैक 1 संचयी अद्यतन 3 (11.0.3349) को स्थापित करने का निर्णय लिया क्योंकि इसमें एक विशिष्ट के लिए एक हॉटफिक्स शामिल था जिस समस्या का आप वास्तव में सामना कर रहे थे, आप वास्तव में SP1 CU1, SP1 CU2, और SP1 CU3 के लिए सभी हॉटफिक्स प्राप्त कर रहे होंगे, जो कि 100 से अधिक हॉटफिक्सेस के बराबर होगा।

जैसा कि Microsoft संचयी अद्यतनों के बारे में बताता है:"क्योंकि बिल्ड संचयी होते हैं, प्रत्येक नए फ़िक्स रिलीज़ में सभी हॉटफ़िक्स और सभी सुरक्षा फ़िक्सेस होते हैं जो पिछले SQL Server 2012 SP 1 फ़िक्स रिलीज़ के साथ शामिल किए गए थे। हम अनुशंसा करते हैं कि आप इस हॉटफिक्स वाले नवीनतम फ़िक्स रिलीज़ को लागू करने पर विचार करें।" मूल रूप से इसका मतलब यह है कि यदि आपको कोई विशेष, प्रासंगिक समस्या दिखाई देती है जिसे पहले के सीयू में ठीक किया गया था, तो आपको आगे बढ़ना चाहिए और सिस्टम पर नवीनतम प्रासंगिक सीयू को तैनात करना चाहिए (जिसमें वह हॉटफिक्स भी शामिल होगा)।

एक तर्क जिसके बारे में मैं अक्सर सुनता हूँ कि संगठन संचयी अद्यतनों को परिनियोजित क्यों नहीं करते हैं, वह यह है कि, "वे सर्विस पैक की तरह पूरी तरह से प्रतिगमन परीक्षण नहीं हैं, इसलिए हम उन्हें तैनात नहीं करते हैं।" इस दृष्टिकोण में कुछ वैधता है, लेकिन एक आम गलत धारणा यह भी है कि संचयी अद्यतन केवल इकाई परीक्षण होते हैं, जिसमें कोई प्रतिगमन परीक्षण नहीं होता है। ऐसा नहीं है।

संचयी अद्यतनों के बारे में Microsoft दस्तावेज़ीकरण इंगित करता है कि चूंकि वे "विकास चक्र के दौरान वृद्धिशील प्रतिगमन परीक्षण लागू करते हैं, जिसके बाद 8 सप्ताह की रिलीज़ विंडो के भीतर 2 सप्ताह के केंद्रित परीक्षण होते हैं, CU से जुड़ी गुणवत्ता आश्वासन प्रक्रियाएं व्यक्तिगत हॉटफिक्स से अधिक होती हैं।" इसका मतलब यह है कि आप वास्तव में एक ऐसे सीयू को परिनियोजित करके कम जोखिम ले रहे हैं जिसका क्रमिक रूप से प्रतिगमन परीक्षण किया गया है और दो सप्ताह का फ़ोकस परीक्षण भी किया गया है, यदि आप एक एकल हॉटफ़िक्स को परिनियोजित करने के लिए थे जिसे केवल इकाई परीक्षण किया गया है।

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

एक परीक्षण और कार्यान्वयन योजना का महत्व

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

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

यहां कुछ शुरुआती चरण और परीक्षण दिए गए हैं जिन्हें इस तरह की योजना में शामिल किया जाना चाहिए।

1. सीयू को टेस्ट वर्चुअल मशीन पर स्थापित करें
   1. क्या सीयू बिना किसी समस्या या त्रुटि के स्थापित होता है?
   2. क्या सीयू इंस्टॉलेशन के लिए सिस्टम रीबूट की आवश्यकता है?
   3. क्या सभी प्रासंगिक SQL सर्वर सेवाएं संस्थापन के बाद पुनः प्रारंभ होती हैं?
   4. क्या इंस्टालेशन के बाद SQL सर्वर ठीक से काम करता हुआ दिखाई देता है?
2. कई विकास प्रणालियों पर सीयू स्थापित करें
   1. क्या सीयू बिना किसी समस्या या त्रुटि के स्थापित होता है?
   2. क्या SQL सर्वर सामान्य दैनिक उपयोग के दौरान सही ढंग से काम करता दिखाई देता है?
   3. क्या आपके एप्लिकेशन यूनिट परीक्षण के दौरान सही ढंग से काम करते प्रतीत होते हैं?
3. सीयू को साझा क्यूए या एकीकरण वातावरण में स्थापित करें
   1. क्या आपने स्थापना के लिए किसी विशिष्ट कार्यान्वयन योजना और चेकलिस्ट का पालन किया था?
   2. क्या SQL सर्वर का उपयोग करने वाले सभी एप्लिकेशन धूम्रपान परीक्षण पास करते हैं?
   3. क्या सभी एप्लिकेशन आपके पास उपलब्ध किसी भी स्वचालित परीक्षण को पास कर लेते हैं?
   4. क्या सभी एप्लिकेशन अधिक विस्तृत मैन्युअल कार्यात्मक परीक्षण पास करते हैं?
4. सीयू को अपने उत्पादन परिवेश में स्थापित करें
   1. जहां संभव हो रोलिंग अपग्रेड रणनीति का उपयोग करें
   2. तैनाती के दौरान विस्तृत, चरण-दर-चरण चेकलिस्ट का उपयोग करें
   3. छूटी हुई वस्तुओं और सीखे गए पाठों के साथ अपनी चेकलिस्ट को अपडेट करें

निष्कर्ष

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

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