Oracle CPU पैच तैनाती के लिए आवश्यक चेकलिस्ट

यह ब्लॉग किसी भी परिवर्तन या प्रौद्योगिकी पैच के बाद आपके पैच फ़ाइल सिस्टम पर Weblogic Server (WLS) या Oracle® Fusion Middleware (FMW) होम डायरेक्टरी में fs_clone के साथ ADOP (एप्लिकेशन DBA ऑनलाइन पैचिंग उपयोगिता) चक्र चलाने के महत्व की समीक्षा करता है। ब्लॉग एक समस्या परिदृश्य का पता लगाता है और बताता है कि संबंधित मुद्दों को आसानी से कैसे संभालें।

ADOP चक्र चरण

निम्नलिखित छवि ADOP चक्र के चरण दिखाती है:

छवि स्रोत: https://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531065.htm

समस्या इतिहास

Oracle संस्करण R12.2 इंस्टेंस पर पैच फ़ाइल सिस्टम पर क्रिटिकल पथ अपडेट (CPU) पैच लागू करने के बाद, ADOP ने एक पूर्ण चक्र रन पूरा किया (तैयारी, लागू करें, अंतिम रूप दें, कटओवर, और सफाई)। किसी अन्य गतिविधि के लिए एक और ADOP चक्र चलाने के बाद, इंस्टेंस को दूसरे सर्वर पर क्लोन किया गया।

हालांकि, नए क्लोन किए गए वातावरण पर WLS पैच लागू करते समय, सिस्टम को एक विरोध का सामना करना पड़ा। पैच WLS के संस्करण बेमेल की ओर इशारा कर रहा था।

विश्लेषण

शोध से पता चला कि WLS और FMW वेब टियर और Oracle कॉमन होम डायरेक्टरी पर पहले लागू किए गए CPU पैच रन और पैच फ़ाइल सिस्टम में शामिल नहीं थे। ADOP लॉगफाइल्स की आगे की जांच पर, हमने देखा कि तैयारी फ़ाइल ने फ़ाइल सिस्टम को सिंक्रनाइज़ किया, हालांकि हम पैचिंग चक्र के दौरान Oracle_home और FMW_home डायरेक्टरी में किए गए परिवर्तनों को नहीं देख सके।

निष्कर्ष:

हमारे विश्लेषण से, हम निम्नलिखित निष्कर्ष निकालते हैं:

1. तैयारी चरण में फ़ाइल सिंक्रनाइज़ेशन केवल APPL_TOP के लिए है।

   हमने जिन लॉग फ़ाइलों की समीक्षा की, उनमें रन APPL_TOP से पैच APPL_TOP तक फ़ाइल सिस्टम परिवर्तनों का प्रसार दिखाया गया।

2. Weblogic पैच लागू होने के बाद, अगले ADOP चक्र को शुरू करने से पहले fs_clone नहीं चलाया गया था। इस प्रकार, नए पैच लगातार दूसरे ADOP चक्र के पूरा होने के बाद भी क्रमिक रन में दिखाई नहीं देते हैं, और यह क्लोन किए गए इंस्टेंस में उपलब्ध नहीं था।

सिफारिश

तैयारी चरण में, पैच फ़ाइल सिस्टम को आमतौर पर एक नया डेटाबेस संस्करण बनाकर रन फ़ाइल सिस्टम के साथ सिंक्रनाइज़ किया जाता है। यह उन फ़ाइलों की डिफ़ॉल्ट वृद्धिशील सिंक्रनाइज़ेशन है जो एप्लिकेशन टॉप पर बदली गई हैं।

लागू पैच को सिंक्रनाइज़ करने के लिए, अंतिम पैचिंग चक्र से रन फ़ाइल सिस्टम के $APPL_TOP पर txkADOPPreparePhaseSynchronize.pl को आमंत्रित करें या fs_clone को आमंत्रित करें। इस मामले में, हम वास्तविक fs_clone को नहीं बुलाते। इसके बजाय, हम FsCloneStage और FsCloneApply को $APPL_TOP के लिए बुलाते हैं, जो बहुत अनसिंक्रनाइज़्ड है।

फ़ाइल सिस्टम सिंक्रनाइज़ेशन विधि कॉन्फ़िगरेशन चेंज डिटेक्टर (adConfigChangeDetector.pl -detectConfigChanges) के आधार पर स्वचालित रूप से चुनी जाती है।

विभिन्न फ़ाइल सिंक्रनाइज़ेशन विधियों में निम्नलिखित विकल्प शामिल हैं:

विकल्प 1 - डेटाबेस से उन पैच की पहचान करें जो पिछले ADOP में लागू किए गए थे। इन्हें साइलेंटली मर्ज करें और लागू करें। यह प्रक्रिया कम समय लेती है क्योंकि सिस्टम केवल अनलागू पैच लागू करता है।

विकल्प 2 - रन फ़ाइल सिस्टम $APPL_TOP को पैच फ़ाइल सिस्टम $APPL_TOP पर फिर से बनाएं या रीक्लोन करें। यह बेहद अनसिंक्रनाइज़्ड है और अधिक संसाधनों का उपभोग करता है।

विकल्प 3 - अपनी पसंद के थर्ड-पार्टी सॉफ़्टवेयर (जैसे rsync) का उपयोग करके फ़ाइल सिस्टम को सिंक्रनाइज़ करें।

तैयारी के साथ पास किए गए पैरामीटर

तैयारी निम्नलिखित पैरामीटर्स का उपयोग करता है:

a) पिछले पैचिंग चक्र में पैच एप्लिकेशन विफल होने पर सिंक्रनाइज़ेशन त्रुटियों और विफलताओं के लिए एक वर्कअराउंड के रूप में त्रुटियों और चेतावनियों को अनदेखा करने के लिए ADOP तैयारी चरण में Skipsyncerror विकल्प का उपयोग करें। डिफ़ॉल्ट मान नहीं है।

सिंटैक्स: adop phase=prepare skipsyncerror=yes

b) पैच फ़ाइल सिस्टम को रन फ़ाइल सिस्टम के साथ सिंक करने के लिए उपयोग की जाने वाली विधि निर्दिष्ट करने के लिए sync_mode विकल्प का उपयोग करें।

सिंटैक्स: adop phase=prepare sync_mode=(delta|patch)

sync_mode patch - रन फ़ाइल सिस्टम पर पहले से लागू पैच को फिर से लागू करता है (डिफ़ॉल्ट मोड)। sync_mode delta - सभी कस्टमाइज़ेशन और फ़ाइल परिवर्तनों को कॉपी करता है। यह मोड फ़ाइल delta_sync_drv.txt से सिंक्रनाइज़ेशन कमांड का उपयोग करता है और AD-TXK delta 8 से एक नई सुविधा है।

ADOP fs_clone कमांड

fs_clone कमांड पैच फ़ाइल सिस्टम को फिर से बनाता है या रीक्लोन करता है जिसमें पैच फ़ाइल सिस्टम पर सभी कॉन्फ़िगरेशन और कस्टमाइज़ेशन को उसी तरह सेट किया जाता है जैसे रन फ़ाइल सिस्टम पर। ऐसा करना रन फ़ाइल सिस्टम का पूर्ण बैकअप लेने और फिर पैच फ़ाइल सिस्टम बनाने के समान संसाधन-गहन है।

fs_clone में निम्नलिखित उपयोगी कमांड हैं:

• adop phase=fs_clone force=yes - विफल क्लोन को शुरुआत से पुनरारंभ करता है (डिफ़ॉल्ट=नहीं)।

• adop phase=fs_clone s_fs_backup_count=1 - पैच फ़ाइल सिस्टम के बैकअप की संख्या सेट करता है जिसे रन फ़ाइल सिस्टम से फिर से बनाने से पहले संरक्षित किया जाना है (डिफ़ॉल्ट=0 कोई बैकअप नहीं लिया जाता)।

मुख्य निष्कर्ष

भले ही तैयारी चरण हर पैचिंग चक्र की शुरुआत में चलता है, प्रौद्योगिकी स्टैक पैच (opatch/Smart update उपयोगिता द्वारा लागू) तैयारी चरण में सिंक नहीं होते हैं।

तैयारी मैन्युअली किए गए किसी भी परिवर्तन को सिंक्रनाइज़ नहीं करता है जैसे:

• उपयोगकर्ता-परिभाषित JSPs को कंपाइल करना।
• थर्ड-पार्टी लाइब्रेरी कॉपी करना।
• उपयोगकर्ता-परिभाषित समवर्ती प्रोग्राम कॉपी करना और कंपाइल करना।
• उपयोगकर्ता-परिभाषित फॉर्म कॉपी करना और जनरेट करना।

आपको कस्टम पैचिंग क्रियाओं (जैसे पहले वर्णित) को कस्टम सिंक्रनाइज़ेशन ड्राइवर, adop_sync.drv, में तैयारी चरण में जोड़ना होगा।

फ़ाइल adop_sync.drv में, निम्नलिखित श्रेणियों के कमांड मौजूद हैं:

• केवल एक बार चलाएं
• प्रत्येक फ़ाइल सिस्टम सिंक्रनाइज़ेशन पर चलाएं

तैयारी चरण में कस्टमाइज़ेशन और फ़ाइल परिवर्तनों को कॉपी करने के लिए, निम्नलिखित कमांड का उपयोग करें:

ADOP phase=prepare sync_mode=(delta|patch)

यदि कोई पैच रद्द हो गया या कोई रखरखाव या रिलीज़ अपडेट पैक (RUP) पैच लागू किए गए हैं, तो पैच फ़ाइल सिस्टम को रन फ़ाइल सिस्टम की सटीक प्रति के रूप में फिर से बनाने के लिए अंत में fs_clone चलाया जाना चाहिए।

निष्कर्ष

जब भी E-बिजनेस सुइट रिलीज़ 12.2 के Weblogic Server या Fusion Middleware घटकों में कोई परिवर्तन किया जाता है, तो यह अनिवार्य है कि डेटाबेस एडमिनिस्ट्रेटर fs_clone चलाएं ताकि यह सुनिश्चित हो सके कि पैच फ़ाइल सिस्टम रन फ़ाइल सिस्टम के WLS या FMW पर किए गए सभी नवीनतम परिवर्तनों के साथ अपडेट है।

टिप्पणी करने या प्रश्न पूछने के लिए फीडबैक टैब का उपयोग करें।

हमारी डेटाबेस सेवाओं के बारे में अधिक जानें।