इस पोस्ट में Oracle® E- Business Suite® (EBS) R12.2.9 के लिए डिजास्टर रिकवरी (DR) सिस्टम के रखरखाव और पैचिंग को शामिल किया गया है। यह Oracle संस्करण 12.2 एप्लिकेशन DR सिस्टम पर डेटाबेस DB और एप्लिकेशन (APPS) पैच लागू करने के लिए एक सामान्य प्रक्रिया का वर्णन करता है।
परिचय
DR एप्लिकेशन साइट बनाने के चरण लगभग एक्लोन सिस्टम बनाने के समान हैं, जिसे हमने पिछले ब्लॉग पोस्ट में कवर किया था।
आपदा के समय, आपको होस्टनामों के लिए XML फ़ाइलों में केवल कुछ परिवर्तन करने की आवश्यकता होती है, और आपके बैकअप सिस्टम तैयार और चल रहे हैं। सिस्टम को सिंक्रोनाइज़ करने के लिए, आपको डेटाबेस और एप्लिकेशनसर्वर वातावरण में पैच को नियमित रूप से लागू करने की आवश्यकता है।
सुनिश्चित करें कि आपने प्राथमिक डेटाबेस सर्वर के साथ एक भौतिक स्टैंडबाय डेटाबेस कॉन्फ़िगर किया है और दोनों डेटाबेस सिंक में हैं। फिर, आपको सभी पैच को DR एप्लिकेशन सिस्टम पर लागू करने की आवश्यकता है।
इस प्रक्रिया के लिए उच्च-स्तरीय चरणों में शामिल हैं:
- भौतिक स्टैंडबाय से संग्रह को अक्षम करें और DR को स्नैपशॉट स्टैंडबाय में बदलें।
- डेटाबेस पैच लागू करने के लिए DR डेटाबेस को शट डाउन करें।
- DR डेटाबेस को स्टैंडबाय स्नैपशॉट मोड में प्रारंभ करें और नोड क्लीनअप स्क्रिप्ट चलाएँ।
- डीआर अनुप्रयोगों के लिए फ़ाइल सिस्टम को फ़्लिप करें यदि वे PRODsystem से मेल नहीं खाते हैं।
- जब सिस्टम डाउनटाइम मोड में हो, तो पैच लागू करें।
- एप्लिकेशन DR सर्वर को पैच करना समाप्त करने के बाद DR को वापस भौतिक स्टैंडबाय में बदलें।
इस प्रक्रिया में एक सरल प्रणाली को डिजाइन करना और इसे एप्लिकेशन स्विचओवर के लिए लागू करना शामिल है। यदि आप अनुप्रयोग पक्ष में किसी आपदा का अनुभव करते हैं, तो यह सिस्टम सभी पैच स्तरों पर प्राथमिक साइट के साथ समन्वयित रहना चाहिए।
1. भौतिक स्टैंडबाय से DR को स्नैपशॉट स्टैंडबाय में बदलें
सबसे पहले, संग्रह लॉग शिपिंग को अक्षम करें और प्राथमिक DR डेटाबेस को स्टैंडबाय स्नैपशॉट मोड में बदलें:
-
प्राथमिक उत्पादन डेटाबेस नोड 1 पर
oracle. के रूप में लॉग ऑन करें । -
निम्नलिखित कमांड चलाएँ:
$. prodinstance.env $ sqlplus / as sysdba show parameter log_archive_dest_state_2; NAME TYPE VALUE ------------------------------------ ----------- -------------------- log_archive_dest_state_2 string enable alter system set log_archive_dest_state_2='Defer' scope=both sid='*'; show parameter log_archive_dest_state_2; NAME TYPE VALUE ------------------------------------ ----------- -------------------- log_archive_dest_state_2 string Defer
फिर, DR डेटाबेस पर रीडो-लॉग एप्लिकेशन को रद्द करें और इसे स्नैपशॉट स्टैंडबाय मोड में बदलें:
-
DR डेटाबेस नोड1 पर
oracle. के रूप में लॉग ऑन करें । -
निम्नलिखित कमांड चलाएँ:
$. drinstance.env $ sqlplus / as sysdba alter database recover managed standby database cancel; select FLASHBACK_ON, DATABASE_ROLE from v$database; FLASHBACK_ON DATABASE_ROLE ------------ ---------------- YES PHYSICAL STANDBY
2. डेटाबेस पैच लागू करने के लिए DR डेटाबेस को शट डाउन करें
दोनों नोड्स पर डेटाबेस को शट डाउन करें और डेटाबेस पैच लागू करें। डेटाबेस पैच लागू करने के लिए निम्नलिखित कमांड चलाएँ:
$. prodinstance.env
$ sqlplus / as sysdba
shut immediate;
$ cd $PATCH_DIR
$ opatch apply
सभी रियल एप्लिकेशन क्लस्टर (आरएसी) सिस्टम नोड्स पर डेटाबेस पैच लागू करने के लिए पिछले चरणों का उपयोग करें।
3. डेटाबेस को स्नैपशॉट मोड में बदलें
DR डेटाबेस को स्नैपशॉट स्टैंडबाय मोड में बदलें और नोड क्लीनअप के बाद ऑटो-कॉन्फ़िगरेशन चलाएँ:
$. prodinstance.env
$ sqlplus / as sysdba
SYS@PRODINSTANCE> startup mount;
SYS@PRODINSTANCE>alter database convert to snapshot standby;
SYS@PRODINSTANCE>alter database open;
SYS@PRODINSTANCE>select DB_UNIQUE_NAME, OPEN_MODE, DATABASE_ROLE from v$database;
DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE
-------------- ---------- ----------------
PRODINSTANCE READ WRITE SNAPSHOT STANDBY
अब, पैचिंग के लिए एप्लिकेशन DR सिस्टम तैयार करें। एक उत्पादन प्रणाली पर पैचिंग चक्र पूर्ण होने के बाद, फ़ाइल सिस्टम कटओवर के बाद फ़्लिप हो जाता है। परिणामस्वरूप, उत्पादन और DR फ़ाइल सिस्टम समान नहीं रह सकते हैं। निम्नलिखित कदम इस चिंता का समाधान करते हैं। ये चरण, जो आप डीबी और एपीपीएस नोड्स पर चलाते हैं, डीआर डेटाबेस में किसी भी उत्पादन संदर्भ को हटा देते हैं।
नोड्स को साफ करें
नोड्स को साफ करने के लिए तैयार करने के लिए निम्न चरणों को चलाएँ:
-
DR डेटाबेस नोड1 पर
oracle. के रूप में लॉग ऑन करें । -
निम्नलिखित कमांड चलाएँ:
$. drinstance.env $ sqlplus apps/apps-passwd exec fnd_conc_clone.setup_clean; truncate table applsys.adop_valid_nodes;
सभी एप्लिकेशन और डेटाबेस स्तरों पर Autoconfig निष्पादित करें
adautoconfigचलाएं डेटाबेस और एप्लिकेशन नोड्स पर।
डीबी नोड्स:
-
DR डेटाबेस नोड1 पर
oracle. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.sh -
DR DB node2 पर
oracle. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.sh
एप्लिकेशन नोड्स— FS चलाएँ:
-
DR एप्लिकेशन नोड1 पर
applmgr. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR एप्लिकेशन नोड2 पर
applmgr. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR बाहरी एप्लिकेशन नोड1 पर
applmgr. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR बाहरी एप्लिकेशन नोड2 पर
applmgr. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
एप्लिकेशन नोड्स—पैच FS
-
DR एप्लिकेशन नोड1 पर
applmgr. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR एप्लिकेशन नोड2 पर
applmgr. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR बाहरी एप्लिकेशन नोड1 पर
applmgr. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR बाहरी एप्लिकेशन नोड2 पर
applmgr. के रूप में लॉग ऑन करें और निम्न आदेश चलाएँ:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
4. DR ऐप्स के लिए फ़ाइल सिस्टम फ़्लिप करें यदि वे PROD सिस्टम से मेल नहीं खाते हैं
आपको निम्न चरणों को केवल तभी निष्पादित करने की आवश्यकता है जब PROD और DR सर्वर के लिए RUN और PATCH फ़ाइल सिस्टम के बीच अंतर हो। यदि वे समान हैं, तो आप सीधे पैच लगाने के साथ आगे बढ़ सकते हैं।
सभी DR APPS टियर नोड्स पर निम्न चरणों का पालन करें:
-
प्रत्येक DR एप्लिकेशन नोड (बाहरी और आंतरिक) पर लॉग ऑन करें और निम्नलिखित कमांड निष्पादित करें:
$. ./drinstance.env $ perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl -action=ctxupdate -contextfile=<full path of current run Context File on standby> -patchcontextfile=<full path of current patch file system Context File on standby> -outdir=<full path to out directory> -
फ़ाइल सिस्टम स्विच किया गया है या नहीं यह जाँचने के लिए सभी नोड्स पर पर्यावरण को फिर से स्रोत करें।
DR अब एप्लिकेशन पैचिंग के लिए तैयार है।
5. डाउनटाइम मोड में DR एप्लिकेशन नोड्स पर एप्लिकेशन पैच लागू करें
सबसे पहले, क्योंकि आप एप्लिकेशन सेवाओं को DR पर नीचे रखते हैं, आप निम्न चरणों का पालन करके डाउनटाइम मोड में RUN फ़ाइल सिस्टम में पैच लागू करते हैं:
-
DR एप्लिकेशन नोड1 पर लॉग ऑन करें।
-
निम्नलिखित कमांड चलाएँ:
$. drinstance.env $ adop phase=apply patches=<patch1, patch2> patchtop=/apps_stage/patch \ apply_mode=downtime options=nodbportion
आपको निम्न चेतावनी संदेश प्राप्त हो सकता है। यदि ऐसा है, तो Y . के साथ उत्तर देकर आगे बढ़ें :
[WARNING] adop has detected a configured disaster recovery site.
[WARNING] Follow the instructions in the section "Oracle E-Business Suite
[WARNING]
Maintenance with Standby Database" of Business Continuity for
[WARNING] Oracle E-Business Suite Release 12.2 depending on the database version used.
Do you want to continue with the apply phase [Y/N]? Y
इसके बाद, मानक प्रक्रिया का उपयोग करके सभी FMW टियर पैच लागू करें।
रन और पैच फ़ाइल सिस्टम को सिंक्रनाइज़ करने के लिए, निम्न कमांड चलाएँ ताकि RUN फ़ाइल सिस्टम में किए गए परिवर्तन पैच फ़ाइल सिस्टम पर क्लोन हो जाएँ:
$. drinstance.env$adop phase=fs_clone
6. एप्लिकेशन DR पैचिंग समाप्त होने के बाद DR को वापस भौतिक स्टैंडबाय में बदलें
अंत में, आपको DR डेटाबेस को वापस भौतिक स्टैंडबाय मोड में बदलने की आवश्यकता है, redo apply को सक्षम करें DR डेटाबेस में, और PROD से DR डेटाबेस में संग्रह-लॉग शिपिंग फिर से शुरू करें।
सबसे पहले, DR डेटाबेस को वापस भौतिक स्टैंडबाय में बदलें:
-
DR डेटाबेस नोड1 पर लॉग ऑन करें और निम्न कमांड चलाएँ:
$. drinstance.env $ sqlplus / as sysdba; shutdown immediate; startup mount; alter database convert to physical standby; SELECT open_mode, database_role FROM v$database; OPEN_MODE DATABASE_ROLE -------------------- ---------------- MOUNTED PHYSICAL STANDBY ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; -
DR डेटाबेस नोड2 पर लॉग ऑन करें और निम्न कमांड चलाकर इंस्टेंस को स्टार्टअप करें:
$. drinstance.env $ sqlplus / as sysdba; startup;
इसके बाद, निम्न आदेश चलाकर प्राथमिक डेटाबेस पर संग्रह लॉग शिपिंग सक्षम करें:
1. Log onto the production database node1.
2. Run the following commands:
$. prodinstance.env
$ sqlplus / as sysdba;
show parameter log_archive_dest_state_2;
alter system set log_archive_dest_state_2='enable' scope=both sid='*';
alter system set log_archive_dest_state_2='defer' scope=both sid='*';
alter system set log_archive_dest_state_2='enable' scope=both sid='*';
निष्कर्ष
यह पोस्ट बताता है कि PROD EBS 12.2 साइट पर लागू अपडेट और पैच के साथ आपदा EBS एप्लिकेशन सिस्टम को कैसे प्रबंधित किया जाए। आपको सभी एप्लिकेशन सिस्टम का बैकअप बनाए रखने और फिर सिस्टम को बैकअप से पुनर्स्थापित करने की आवश्यकता नहीं है। आप rsync सेट करना चाह सकते हैं PROD और DR साइटों के बीच प्रक्रियाएँ और डेटाबेस और AD ऑनलाइन पैचिंग (ADOP) पैच को DR साइट पर तब लागू करें जब आप उन्हें PROD साइट पर लागू करते हैं।
हमारी डेटा सेवाओं के बारे में अधिक जानें।
कोई टिप्पणी करने या प्रश्न पूछने के लिए प्रतिक्रिया टैब का उपयोग करें। आप हमारे साथ बातचीत भी शुरू कर सकते हैं।