मैं ओटीएन समुदाय पर हाल ही में एक थ्रेड में भाग ले रहा था जहां कोई डेटाबेस अपग्रेड के बाद डाउनग्रेडिंग के बारे में प्रश्न पूछ रहा था। प्रतिक्रियाओं में से एक ने पूछा कि कितने लोग वास्तव में डेटाबेस डाउनग्रेड का अभ्यास करते हैं। मैंने यह पोल पता लगाने के लिए बनाया है।
मैं उस सूत्र में एक योगदान पाकर हैरान था जिसमें कहा गया था:
अब उस पोस्टर ने स्पष्ट रूप से यह नहीं कहा था, लेकिन यह लगभग ऐसा था जैसे वह व्यक्ति कह रहा था कि डाउनग्रेड का अभ्यास करना समय की बर्बादी है क्योंकि उन्हें कभी इसकी आवश्यकता नहीं होगी। मैं पोस्टर को संदेह का लाभ दूंगा और यह कि Oracle का यह कर्मचारी वास्तव में ऐसा नहीं कह रहा था। मैं इस व्यक्ति को चुनने की कोशिश नहीं कर रहा हूं। मैं इस धागे को मुझे इस विषय पर अधिक सामान्य दृष्टिकोण से चर्चा करने का अवसर प्रदान करने दूंगा। (अपडेट:जिस पोस्टर ने मुझे इस ब्लॉग प्रविष्टि को लिखने के लिए प्रेरित किया, वह उस समय में वापस आ गया है जब मुझे इसे लिखने में लगा था और कहा था, "इसका मतलब यह नहीं था कि हमें डाउनग्रेड का 'परीक्षण' नहीं करना चाहिए।" )
जुलाई में वापस, मैंने द डेटा गार्जियन के बारे में एक ब्लॉग पोस्ट लिखा था। उस ब्लॉग पोस्ट में, मैंने कहा:
DBA को डेटा की सुरक्षा करने की आवश्यकता है। वह नौकरी # 1 है। नौकरी #2 डेटा को कुशल और समय पर पहुंच प्रदान करने के लिए डीबीए के लिए है। डेटा होने में क्या फायदा है अगर जिन लोगों को इसकी एक्सेस की आवश्यकता है वे डेटा तक नहीं पहुंच सकते हैं? अगर उन लोगों का डेटा के साथ इंटरैक्ट करते समय भयानक प्रदर्शन होता है, तो हो सकता है कि उनके पास कोई एक्सेस न हो।
DBA के रूप में, हमें जोखिम प्रबंधन करने की आवश्यकता है। हमें यह निर्धारित करने की आवश्यकता है कि कौन से जोखिम वास्तविकता बन सकते हैं। डीबीए का काम उन जोखिमों को मापना और दो कार्य योजनाओं का निर्धारण करना है। उस जोखिम को वास्तविकता बनने से रोकने के लिए क्या कदम उठाए जा सकते हैं और जब वह जोखिम वास्तविकता बन जाता है तो समस्या को हल करने के लिए मुझे क्या कदम उठाने होंगे?
यहां तक कि एक जूनियर स्तर का डीबीए बैकअप के महत्व को समझेगा। बैकअप एक जोखिम प्रबंधन रणनीति है। यदि डेटा खो जाता है, तो हम बैकअप से डेटा को पुनर्प्राप्त कर सकते हैं। और यहां तक कि एक जूनियर स्तर का डीबीए बैकअप से पुनर्स्थापित करने में सक्षम होने के महत्व को समझता है।
इस OTN सूत्र में, मैंने यह लिखा है:
मेरे लिए, यह एक मर्फी का नियम है। मैंने पहले भी ऐसी ही बातें कही हैं। विचार (और इस ब्लॉग प्रविष्टि का पूरा बिंदु) यह है कि यदि मैं उचित जोखिम प्रबंधन कदम नहीं उठाता, तो मैं सिर्फ देवताओं से उस जोखिम को वास्तविकता में बदलने के लिए कह रहा हूं। अगर मैं अपने रियर व्यू मिरर को एडजस्ट करने से मना कर दूं और अपने वाहन का बैकअप लेते समय इसका इस्तेमाल करूं, तो ठीक उसी दिन मैं किसी चीज में वापस आ जाता हूं। अगर मैं अपने फावड़ियों को बांधने से इनकार करता हूं, तो ठीक उसी दिन मैं एक पर कदम रखता हूं और यात्रा करता हूं। वे दिन जब मैं एक पॉवरटूल का उपयोग करते हुए सुरक्षात्मक गोगल्स पहनने से इनकार करता हूं, तो वह दिन होता है जब मुझे अपनी आंखों में कुछ मिलता है। जिस दिन मैं समुद्र तट पर जाऊंगा और धूप सेंकने से इंकार कर दूंगा, उसी दिन मैं धूप सेंकने के साथ घर आऊंगा। आपको अंदाजा हो गया।
कुछ पाठक सोच रहे होंगे कि मैं पागल हूं और ब्रह्मांड के पास यह मास्टर प्लान मेरे साथ पेंच करने के लिए नहीं है क्योंकि मैं आत्मसंतुष्ट हूं। और मैं सहमत होगा। तो मैं इसे दूसरे तरीके से कहूंगा, अगर मैंने जोखिम को कम करने की योजना नहीं बनाई है, तो मैंने इसे वास्तविकता बनने से रोकने के लिए कुछ नहीं किया है। मेरी निष्क्रियता के कारण इसके वास्तविकता बनने की संभावना कम नहीं होती है।
जोखिम प्रबंधन के दो प्रमुख घटक हैं। 1) उस जोखिम वाली वस्तु के घटित होने की संभावना का निर्धारण करना और 2) उस जोखिम के घटित होने पर प्रभाव का निर्धारण करना। वे आइटम जिनमें सबसे अधिक संभावना है होने वाली घटनाओं को पहले कम किया जाता है। यह आसान है और कुछ ऐसा जो जोखिम प्रबंधन पर काम करने वाले कई लोग अक्सर करते हैं। वे जोखिम वाली वस्तुओं को एक स्प्रेडशीट में डालते हैं और उस जोखिम के होने की संभावना के लिए कुछ मूल्य भरते हैं। पूरा होने पर, वे संभाव्यता कॉलम पर छाँटते हैं और ऊपर से नीचे तक जोखिम शमन शुरू करते हैं। कई जोखिम प्रबंधन रणनीतियाँ सूची के बीच में कहीं एक रेखा खींचती हैं और तय करती हैं कि उस रेखा के नीचे किसी भी जोखिम वाली वस्तु की संभावना बहुत कम है कि हम उस जोखिम वाली वस्तु के बारे में चिंता नहीं करेंगे। हम ब्रह्मांड में सभी संभावित जोखिमों को कम नहीं कर सकते। यह सब संभालने के लिए पर्याप्त समय नहीं है। इसलिए हमें कहीं न कहीं रेखा खींचनी होगी।
मैं हर समय जो विफलता देखता हूं उनमें से एक यह है कि जोखिम प्रबंधन प्रभाव पर ध्यान केंद्रित करने में अधिक समय नहीं लगाता है। उस जोखिम की वास्तविकता बन रही है। स्प्रैडशीट में एक समान कॉलम शामिल होना चाहिए जो उस जोखिम वाली वस्तु के लिए व्यवसाय पर प्रभाव की रेटिंग प्रदान करता हो। जोखिम प्रबंधक को इस कॉलम पर भी स्प्रेडशीट को सॉर्ट करना होगा। कोई भी वस्तु जिसका बड़ा प्रभाव पड़ता है, उसे जोखिम शमन गतिविधियों की आवश्यकता होती है, भले ही उस वस्तु के घटित होने की संभावना कम हो! अफसोस की बात है कि जोखिम प्रबंधन व्यवसाय में बहुत से लोग जोखिम प्रभाव के आकलन के इस कदम को शामिल करने में विफल रहते हैं। फिर से, जब स्प्रैडशीट को व्यवसाय पर प्रभाव के आधार पर क्रमबद्ध किया जाता है, तो कहीं न कहीं एक रेखा खींची जाती है।
किसी को उच्च संभाव्यता . के साथ जोखिम वाले आइटम मिल सकते हैं कम या बहुत कम प्रभाव व्यापार को। मुझे जोखिम प्रबंधन स्प्रैडशीट पसंद है जिसमें एक तीसरा कॉलम शामिल है जो "संभाव्यता x प्रभाव" है। यह कॉलम दो जोखिम घटकों के बीच संबंध को समझने में मदद करता है।
आइए डेटाबेस अपग्रेड प्रश्न पर वापस जाएं जिसने इस ब्लॉग पोस्ट को प्रेरित किया। मुझे लगता है कि इस ब्लॉग लेख को पढ़ने वाले सभी लोगों को इस बात से सहमत होना चाहिए कि Oracle डेटाबेस को अपग्रेड करना एक जोखिम भरा प्रस्ताव है। ऐसी कई अलग-अलग चीजें हैं जो Oracle डेटाबेस अपग्रेड के साथ गलत हो सकती हैं। संभावना एक उन्नयन विफलता उच्च है। जोखिम न्यूनीकरण मदों में अक्सर उत्पादन के क्लोन पर अपग्रेड का अभ्यास करना और अपग्रेड प्रक्रिया शुरू होने से पहले डेटाबेस का बैकअप लेना शामिल है, लेकिन इन्हीं तक सीमित नहीं है। हम ऐसा क्यों करते हैं? वैसे प्रभाव व्यापार के लिए बहुत अधिक है। यदि हम अपने उत्पादन डेटाबेस को अपग्रेड करते समय विफल हो जाते हैं, तो हमारे व्यावसायिक उपयोगकर्ताओं के पास डेटा तक पहुंच नहीं है। यदि हम इस विफलता को दूर नहीं कर सकते हैं तो हम बहुत अच्छे डेटा अभिभावक नहीं हैं। यदि हम गैर-उत्पादन वातावरण में पर्याप्त रूप से अपग्रेड का अभ्यास करते हैं, तो हम जोखिम वाले आइटम की संभावना को मध्यम तक कम कर सकते हैं। लेकिन सभी संभावनाओं में, हम उस विशिष्ट जोखिम संभावना को कम नहीं कर सकते। इसलिए हम अपग्रेड शुरू होने से पहले बैकअप लेते हैं। अभी भी समस्या होनी चाहिए, भले ही हमने अपने स्तर पर सर्वोत्तम प्रयास किया हो संभावना . को कम करें उस जोखिम वाली वस्तु का, प्रभाव व्यापार के लिए अभी भी बहुत अधिक है। इसलिए DBA की जोखिम निवारण रणनीति इस बात पर ध्यान देना है कि अपग्रेड कहां और किस कारण विफल हुआ, और बैकअप से पुनर्स्थापित किया जाए। डेटाबेस तैयार है और चल रहा है और हमने प्रभाव . को समाप्त कर दिया है व्यापार को। डीबीए फिर ड्राइंग बोर्ड पर वापस जाता है यह निर्धारित करने के लिए कि क्या गलत हुआ है इसका समाधान कैसे करें। DBA संभावना . को कम करने का प्रयास कर रहा है उस समस्या के फिर से होने पर जब वे बाद में अपग्रेड प्रक्रिया को फिर से करने के लिए बाद में वापस आते हैं।
तो आइए ओटीएन थ्रेड में उस टिप्पणी पर वापस जाएं जहां यह कह रहा था कि डेटाबेस डाउनग्रेड का अभ्यास करना समय के लायक नहीं है। मैं असहमत हूं। और मेरी असहमति का सब कुछ प्रभाव . से है व्यापार को। मैं उस टिप्पणी से सहमत हूं जो पोस्टर ने अपने जवाब में कहा था।
मैं उससे 100% सहमत हूं। हम यह "पूरी तरह से परीक्षण" क्यों करते हैं? यह सब जोखिम न्यूनीकरण के कारण है। हम संभावना . को कम करने का प्रयास कर रहे हैं कि अपग्रेड खराब प्रदर्शन का कारण बनेगा या एप्लिकेशन की कार्यक्षमता को बाधित करेगा। लेकिन जैसा कि उस पोस्टर ने कहा, "उन्नयन के बाद उत्पादन में हमेशा ऐसे मुद्दे होंगे जो आपके आवेदन के 100% का परीक्षण करना असंभव है।" फिर से, मैं 100% सहमत हूं कि यह पोस्टर यहां क्या कह रहा है। लेकिन प्रभाव . के बारे में क्या व्यापार के लिए? मैं एक मिनट में उस तक पहुंच जाऊंगा, लेकिन पहले मुझे इस अगले पैराग्राफ में थोड़ा पीछे हटना होगा…
मैंने हाल ही में एक महत्वपूर्ण उत्पादन प्रणाली को 11.2.0.4 से 12.1.0.2 संस्करण में अपग्रेड किया है। जहां मैं काम करता हूं, हमारे पास मेरे अन्य कार्यों की तुलना में अधिक आवेदन परीक्षण हैं। हमारे पास एक पूर्ण क्यूए टीम है जो हमारे लिए परीक्षण करती है। हमारे पास एक टीम भी है जो हमारे स्वचालित परीक्षण प्रयासों का प्रभारी है। हमारे पास स्वचालित रोबोट हैं जो रात में हमारे एप्लिकेशन कोड का प्रयोग करते हैं। इन सबसे ऊपर, हमारे पास एक और स्वचालित दिनचर्या है कि जब भी लोग कोड परिवर्तन को टेस्ट या प्रोडक्ट में बदलते हैं, तो यह रूटीन महत्वपूर्ण कोड पथों की त्वरित जांच करता है। मैंने विकास के वातावरण (उनमें से 15 से अधिक) को 12.1.0.2 में अपग्रेड किया और फिर एक महीने इंतजार किया। मैंने तब टेस्ट को अपग्रेड किया और प्रोडक्शन को अपग्रेड करने से पहले 3 सप्ताह तक इंतजार किया। हमारे द्वारा प्रोडक्शन को अपग्रेड करने से पहले कुछ समस्याएं पाई गईं और उनका समाधान किया गया। लेकिन इन सबके बाद भी, प्रोडक्शन अपग्रेड होने के बाद मेरे सामने बड़ी समस्याएँ थीं। उनमें से कुछ मुद्दों को देखने के लिए आप मध्य अक्टूबर से मध्य दिसंबर तक मेरे ब्लॉग पोस्ट पर जा सकते हैं। मैं इस डेटाबेस को डाउनग्रेड करने के बहुत करीब था लेकिन मैं इसके बजाय मुद्दों के माध्यम से काम करने में कामयाब रहा। अब वापस उस बिंदु पर जो मैं बना रहा था...
नवीनीकरण पूर्ण होने के बाद, डेटाबेस व्यवसाय के लिए खोल दिया जाता है। एप्लिकेशन उपयोगकर्ताओं को अब एप्लिकेशन का उपयोग करने की अनुमति है। इस बिंदु पर डेटाबेस के अंदर क्या होता है? लेन-देन! और लेन-देन का मतलब डेटा परिवर्तन है। जिस समय अपग्रेड पूरा होने के बाद डीबीए व्यवसाय के लिए डेटाबेस खोलता है, डेटा परिवर्तन होने लगते हैं। इस सब के बाद डेटाबेस का पूरा बिंदु है, है ना? डेटा परिवर्तन कैप्चर करें और एप्लिकेशन के अंतिम उपयोगकर्ताओं को डेटा उपलब्ध कराएं।
तो क्या होता है यदि आप नाव में हैं तो मैं अपने डेटाबेस अपग्रेड के साथ आखिरी बार गिर गया था? मैं उन चीजों को हिट कर रहा था जो हमने अपने सभी परीक्षण के बाद भी गैर-उत्पादन में नहीं देखीं। प्रभाव व्यापार के लिए उच्च था। मुझे व्यवसाय पर इस प्रभाव को कम करने में सक्षम होना चाहिए। मेरे पास तीन विकल्प थे। 1) मुद्दों को एक-एक करके ठीक करें। 2) अपग्रेड से पहले मेरे द्वारा लिए गए बैकअप से पुनर्स्थापित करें ताकि मैं डेटाबेस को पुराने संस्करण में वापस ला सकूं। 3) डेटाबेस को डाउनग्रेड करें और ड्राइंग बोर्ड पर वापस जाएं। मैंने पहला विकल्प चुना। जैसा कि मेरे करियर के दौरान हमेशा होता है। लेकिन क्या होगा अगर वह पर्याप्त नहीं था? मुद्दों को हल करने में समय लग सकता है। कुछ व्यवसाय उस तरह के नकारात्मक प्रभाव . के साथ बस इतना समय नहीं दे सकते व्यापार को। कितनी वेबसाइटों को छोड़ दिया गया है क्योंकि प्रदर्शन भयानक था या चीजें ठीक से काम नहीं कर रही थीं? और वहां मौजूद अधिकांश उत्पादन डेटाबेस के लिए, विकल्प 2 का बहुत ही भयानक प्रभाव . है व्यापार के लिए! अपग्रेड पूरा होने के बाद आप लेन-देन खो देंगे! डेटाबेस को पुराने संस्करण में रखते हुए डीबीए अपग्रेड के आगे आगे बढ़ने में सक्षम नहीं होगा, इसलिए डेटा खो जाएगा और कई उत्पादन डेटाबेस के लिए, यह अस्वीकार्य है। व्यवसाय एक घंटे का डेटा हानि वहन करने में सक्षम हो सकता है, लेकिन अपग्रेड के एक घंटे के भीतर कितने लोग इस कार्रवाई पर ट्रिगर खींचेंगे? पूरी संभावना है कि यह कार्रवाई अपग्रेड और प्रभाव . के कुछ दिनों बाद की जाएगी उस तरह के डेटा हानि के लिए व्यवसाय के लिए बहुत अधिक है। ताकि विकल्प 3 को विकल्प के रूप में सबसे कम प्रभाव . के साथ छोड़ दिया जाए अपग्रेड के बाद व्यवसाय पर जो भी प्रभाव पड़ रहा है, उसे हल करने में मदद करने के लिए व्यवसाय को।
आप शायद उस अंतिम पैराग्राफ से बता सकते हैं कि मुझे लगता है कि ओरेकल डीबीए के लिए यह जानना महत्वपूर्ण है कि अपग्रेड पूरा होने के बाद अपने डेटाबेस को डाउनग्रेड कैसे करें। मैं मानता हूँ कि संभावना डीबीए को डाउनग्रेड करने की आवश्यकता बहुत कम है। लेकिन प्रभाव डाउनग्रेडिंग नहीं करना व्यवसाय के लिए विनाशकारी हो सकता है। (वे दो शब्द फिर से हैं)। क्योंकि संभावना कम है, मैं अक्सर डाउनग्रेड का अभ्यास नहीं करता, लेकिन क्योंकि प्रभाव डाउनग्रेड न कर पाने की बात बहुत अधिक है, मैं कभी-कभार इनका अभ्यास करता हूं।
तो अंत में, मैं फिर से उस मर्फी के नियम पर वापस जा रहा हूँ। ब्रह्मांड मेरे खिलाफ साजिश नहीं कर रहा है, लेकिन डेटा गार्जियन के रूप में, मुझे अच्छे जोखिम प्रबंधन सिद्धांतों का अभ्यास करने की आवश्यकता है। इसका मतलब है कि मेरे परिवर्तन द्वारा लगाए गए जोखिम मदों की संभावना और प्रभाव का आकलन करना। जबकि ब्रह्मांड और देवता मर्फी के नियम या उसके चचेरे भाइयों को गियर में नहीं ला सकते हैं, मैं जोखिम वाली वस्तुओं को कम करके खुद को कोई एहसान नहीं कर रहा हूं। मैं संभावना को थोड़ा कम नहीं कर रहा हूं।
