संस्करण-आधारित पुनर्परिभाषित। भाग २

नमस्ते! जैसा कि संस्करण-आधारित पुनर्वित्त के बारे में पिछली पोस्ट में वादा किया गया था - यह दूसरा भाग है।



तो हम किसके साथ काम कर रहे हैं? हमारा मुख्य प्रोडक्शन सर्वर ओरेकल 12 सी, एंटरप्राइज एडिशन है। और, जो नोट करना महत्वपूर्ण है, कई दर्जन अनुप्रयोग एक साथ उस पर चल रहे हैं। हम इस पर ध्यान क्यों दे रहे हैं? प्रौद्योगिकी अपेक्षाकृत नई है, यह बहुत अच्छी तरह से रन-इन नहीं है। और इसके लिए कुछ महत्वपूर्ण प्रणालियों को तुरंत स्थानांतरित करना अतार्किक होगा। इसलिए, हमने अपने लिए फैसला किया कि हम धीरे-धीरे कम महत्वपूर्ण प्रणालियों से अधिक महत्वपूर्ण लोगों की ओर बढ़ेंगे। तदनुसार, अगली समस्या जिसे हमें समझने की आवश्यकता है: ईबीआर तकनीक के साथ कैसे काम करना है और उस स्थिति में एकीकरण कैसे व्यवस्थित करें जब हमारे पास एक संस्करण है और दूसरा नहीं। ओरेकल के संस्करण 12 में, जैसा कि यह निकला, आप बहुत एकीकरण को व्यवस्थित करने के लिए एक संस्करण योजना में गैर-विसर्जित वस्तुएं, अनवांटेड पैकेज, अनवांटेड प्रतिनिधित्व बना सकते हैं।

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

संस्करण को स्थापित करने के लिए कई विकल्प हैं:

• पूरे डेटाबेस के लिए डिफ़ॉल्ट संस्करण मान सेट करें
• पूरे डेटाबेस पर फिर से पर्यावरण स्थापित करें।

इन विकल्पों को तुरंत खारिज कर दिया जाता है क्योंकि कम से कम कुछ एप्लिकेशन ईबीआर का उपयोग करने के लिए स्विच नहीं करेंगे।

संस्करण को निर्धारित करने के लिए एक सेवा बनाना, या एप्लिकेशन को सर्किट से कनेक्ट करते समय संस्करण का निर्धारण करना भी संभव है। यह सुविधाजनक है अगर हम कुछ तृतीय-पक्ष एप्लिकेशन के माध्यम से डेटाबेस से कनेक्ट करते हैं।

और अगर हमें शेड्यूल पर चलने और कुछ विशिष्ट संस्करण में काम करने के लिए नौकरियों की आवश्यकता है? तदनुसार, एक नया संस्करण पर स्विच करने के लिए एक और विकल्प है - यह वर्तमान सत्र को एक विशिष्ट संस्करण के लिए उन्मुख करना है ।

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



तर्क के एकीकरण और दोहराव पर लौटना। ऐसे कार्य हैं: मैं अपनी योजना के अंदर कुछ प्रकार के एप्लिकेशन लॉजिक का संस्करण बनाना चाहता हूं, और मुझे इसे गैर-प्रसार उपयोगकर्ता के सामने लाने की भी आवश्यकता है। पहले, ऐसा लगता था कि इसे लागू नहीं किया जा सकता है, लेकिन सवाल में देरी करने के बाद, हमने देखा कि सामान्य dbms_sql पैकेज, जो सिद्धांत रूप में कुछ प्रकार के गतिशील प्रश्नों का प्रदर्शन करने के उद्देश्य से है, इस समस्या को हल करने में मदद कर सकता है। कैसे? बहुत सरल - जब किसी अनुरोध को संसाधित करना या किसी अनाम ब्लॉक को कॉल करना, हम एक पैरामीटर के रूप में स्थिति का नाम फेंक सकते हैं, जिससे उस संस्करण का संकेत मिलता है जिसमें इस कोड को पार्स और निष्पादित किया जाएगा। अगर हमें अपने अंदर कुछ प्रक्रिया का उपयोग करने की और उसी प्रक्रिया को किसी थर्ड-पार्टी स्कीम को देने की आवश्यकता है, तो हम बस इसे dbms_sql.parse प्रक्रिया में कॉल के साथ लपेटते हैं, इस प्रकार एक रैपर बनाते हैं जिसे एक गैर-वस्तु ऑब्जेक्ट में रखा जा सकता है और - कृपया, हम अपने संस्करण ऑब्जेक्ट का उपयोग कर सकते हैं नॉनवेज यूजर।

आप यहाँ क्या सामना कर रहे हैं? किसी कारण से, स्थिति निर्दिष्ट करते समय, प्रक्रियाओं में आउट पैरामीटर जारी नहीं किए जाते हैं। क्यों - यह स्पष्ट नहीं है, लेकिन उन योजनाओं में जिनमें हमने काम किया, यह अक्सर उपयोग नहीं किया जाता है। हो सकता है कि हम किसी तरह तर्क को पुनः प्राप्त करें, या हम कुछ और समाधानों की तलाश करेंगे।



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

इसलिए, पाइपलाइन कार्यों के उपयोग पर लौटते हुए, यह पता चला कि यदि निर्मित किया जा रहा प्रकार संस्करण पैकेज में नहीं बनाया जा रहा है और इसे पहली बार बनाया जा रहा है, तो पैकेज केवल संकलन नहीं करता है और अलग हो जाता है। तुरंत कोई समाधान नहीं आया, खोज करने के लिए रवाना हो गए, साथी प्रोग्रामरों ने क्या सुझाव दिया था? किसी ने कहा कि पैकेज के शून्य संस्करण में इस प्रकार का निर्माण करना आवश्यक है, या डेटाबेस के शून्य संस्करण में संबंधित प्रकार के साथ एक पैकेज बनाना है। यह स्पष्ट नहीं था कि ऐसा क्यों करना है। उन्होंने एक समाधान पाया कि ये प्रकार, जो पैकेज तैयार किए जाने पर निहित रूप से बनाए जाते हैं, बस एक अलग प्रकार में डेटाबेस ऑब्जेक्ट के रूप में डाले जा सकते हैं। जिससे कन्वेयर फंक्शन की समस्या दूर हो जाती है।
अगली विशेषता जिस पर हमने ठोकर खाई, वह संस्करण विचारों का गैर-मानक व्यवहार है।

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

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

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



मैं निष्कर्ष में क्या कहना चाहूंगा? संस्करण-आधारित पुनर्परिभाषित, किसी विमोचन या हॉटफ़िक्स को ऑनलाइन रोल करने के वास्तविक अवसर के लिए, उपयोगकर्ता मोड में एक प्रभावी तकनीक है। हमने एक सर्वर पर एकीकरण को स्पर्श किया, महसूस किया, महसूस किया कि जब सभी योजनाएं इस तकनीक का उपयोग करने के लिए आगे नहीं बढ़ेंगी, तो यह वास्तविक है, यह उल्लेख नहीं करने के लिए कि संस्करण योजना एक समर्पित सर्वर या एक अलग कंटेनर डेटाबेस पर काम कर सकती है।

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

दरअसल, बस इतना ही। आपका ध्यान के लिए धन्यवाद।