यह पोस्ट Oracle® E-business Suite® (EBS) R12.2.9 के लिए डिजास्टर रिकवरी (DR) सिस्टम के रखरखाव और पैचिंग को कवर करती है। यह Oracle संस्करण 12.2 एप्लिकेशन DR सिस्टम पर डेटाबेस DB और एप्लिकेशन (APPS) पैच लागू करने के लिए एक सामान्य प्रक्रिया का वर्णन करती है।
परिचय
DR एप्लिकेशन साइट बनाने के चरण क्लोन सिस्टम बनाने के समान हैं, जिसे हमने पिछले ब्लॉग पोस्ट में कवर किया था।
आपदा के समय, आपको होस्टनाम के लिए XML फ़ाइलों में केवल कुछ परिवर्तन करने की आवश्यकता होती है, और आपके बैकअप सिस्टम तैयार और चल रहे होते हैं। सिस्टम को सिंक में रखने के लिए, आपको डेटाबेस और एप्लिकेशन सर्वर वातावरण पर नियमित रूप से पैच लागू करने की आवश्यकता होती है।
सुनिश्चित करें कि आपने प्राथमिक डेटाबेस सर्वर के साथ एक भौतिक स्टैंडबाय डेटाबेस कॉन्फ़िगर किया है और दोनों डेटाबेस सिंक में हैं। फिर, आपको DR एप्लिकेशन सिस्टम पर सभी पैच लागू करने की आवश्यकता है।
इस प्रक्रिया के लिए उच्च-स्तरीय चरणों में शामिल हैं:
- आर्काइविंग अक्षम करें और DR को भौतिक स्टैंडबाय से स्नैपशॉट स्टैंडबाय में बदलें।
- डेटाबेस पैच लागू करने के लिए DR डेटाबेस को बंद करें।
- DR डेटाबेस को स्टैंडबाय स्नैपशॉट मोड में शुरू करें और नोड क्लीनअप स्क्रिप्ट चलाएं।
- यदि वे PROD सिस्टम से मेल नहीं खाते हैं तो DR एप्लिकेशन के लिए फाइल सिस्टम फ्लिप करें।
- जब सिस्टम डाउनटाइम मोड में हो तो पैच लागू करें।
- एप्लिकेशन DR सर्वर पैचिंग समाप्त करने के बाद DR को भौतिक स्टैंडबाय में वापस बदलें।
इस प्रक्रिया में एप्लिकेशन स्विचओवर के लिए एक सरल सिस्टम डिजाइन करना और उसे रखना शामिल है। यदि आप एप्लिकेशन पक्ष पर आपदा का अनुभव करते हैं, तो यह सिस्टम सभी पैच स्तरों पर प्राथमिक साइट के साथ सिंक में रहना चाहिए।
1. DR को भौतिक स्टैंडबाय से स्नैपशॉट स्टैंडबाय में बदलें
सबसे पहले, आर्काइव लॉग शिपिंग अक्षम करें और प्राथमिक DR डेटाबेस को स्टैंडबाय स्नैपशॉट मोड में बदलें:
oracleके रूप में प्राथमिक उत्पादन डेटाबेस नोड 1 पर लॉग ऑन करें।- निम्नलिखित कमांड चलाएं:
$. 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 डेटाबेस पर रीडो-लॉग एप्लिकेशन रद्द करें और इसे स्नैपशॉट स्टैंडबाय मोड में बदलें:
oracleके रूप में DR डेटाबेस नोड 1 पर लॉग ऑन करें।- निम्नलिखित कमांड चलाएं:
$. 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
सभी रियल एप्लिकेशन क्लस्टर (RAC) सिस्टम नोड्स पर डेटाबेस पैच लागू करने के लिए पहले के चरणों का उपयोग करें।
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 फाइल सिस्टम समान नहीं रह सकते हैं। निम्नलिखित चरण इस चिंता को संबोधित करते हैं। ये चरण, जिन्हें आप DB और APPS नोड्स पर चलाते हैं, DR डेटाबेस में किसी भी उत्पादन संदर्भ को हटा देते हैं।
नोड्स को साफ करें
नोड्स को साफ करने की तैयारी के लिए निम्नलिखित चरण चलाएं:
oracleके रूप में DR डेटाबेस नोड 1 पर लॉग ऑन करें।- निम्नलिखित कमांड चलाएं:
$. drinstance.env $ sqlplus apps/apps-passwd exec fnd_conc_clone.setup_clean; truncate table applsys.adop_valid_nodes;
सभी एप्लिकेशन और डेटाबेस टियर पर ऑटोकॉन्फिग निष्पादित करें
डेटाबेस और एप्लिकेशन नोड्स पर adautoconfig चलाएं।
DB नोड्स:
oracleके रूप में DR डेटाबेस नोड 1 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.shoracleके रूप में DR DB नोड 2 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.sh
एप्लिकेशन नोड्स - रन FS:
applmgrके रूप में DR एप्लिकेशन नोड 1 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgrके रूप में DR एप्लिकेशन नोड 2 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgrके रूप में DR बाहरी एप्लिकेशन नोड 1 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgrके रूप में DR बाहरी एप्लिकेशन नोड 2 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
एप्लिकेशन नोड्स - पैच FS
applmgrके रूप में DR एप्लिकेशन नोड 1 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgrके रूप में DR एप्लिकेशन नोड 2 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgrके रूप में DR बाहरी एप्लिकेशन नोड 1 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgrके रूप में DR बाहरी एप्लिकेशन नोड 2 पर लॉग ऑन करें और निम्नलिखित कमांड चलाएं:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
4. यदि वे PROD सिस्टम से मेल नहीं खाते हैं तो DR ऐप्स के लिए फाइल सिस्टम फ्लिप करें
आपको निम्नलिखित चरण केवल तभी निष्पादित करने होंगे यदि PROD और DR सर्वर के लिए RUN और PATCH फाइल सिस्टम में अंतर है। यदि वे समान हैं, तो आप सीधे पैच लागू करने के लिए आगे बढ़ सकते हैं।
सभी DR APPS टियर नोड्स पर निम्नलिखित चरण निष्पादित करें:
- प्रत्येक DR एप्लिकेशन नोड (बाहरी और आंतरिक) पर लॉग ऑन करें और निम्नलिखित कमांड निष्पादित करें:
$. ./drinstance.env $ perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl -action=ctxupdate -contextfile=<स्टैंडबाय पर वर्तमान रन कॉन्टेक्स्ट फ़ाइल का पूर्ण पथ> -patchcontextfile=<स्टैंडबाय पर वर्तमान पैच फाइल सिस्टम कॉन्टेक्स्ट फ़ाइल का पूर्ण पथ> -outdir=<आउट निर्देशिका का पूर्ण पथ> - सभी नोड्स पर वातावरण को फिर से स्रोत करें ताकि यह जांचा जा सके कि फाइल सिस्टम स्विच हो गया है।
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 टियर पैच लागू करें।
रन और पैच फाइल सिस्टम को सिंक्रनाइज़ करने के लिए, निम्नलिखित कमांड चलाएं ताकि रन फाइल सिस्टम पर किए गए परिवर्तन पैच फाइल सिस्टम पर क्लोन हो जाएं:
$. drinstance.env $adop phase=fs_clone
6. एप्लिकेशन DR पैचिंग समाप्त होने के बाद DR को भौतिक स्टैंडबाय में वापस बदलें
अंत में, आपको DR डेटाबेस को वापस भौतिक स्टैंडबाय मोड में बदलने, DR डेटाबेस पर redo apply सक्षम करने, और 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. प्रोडक्शन डेटाबेस नोड 1 पर लॉग ऑन करें।
2. निम्नलिखित कमांड चलाएं:
$. 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 एप्लिकेशन सिस्टम को कैसे प्रबंधित किया जाए। आपको सभी एप्लिकेशन सिस्टम का बैकअप बनाए रखने और फिर सिस्टम को बैकअप से पुनर्स्थापित करने की आवश्यकता नहीं है। आप PROD और DR साइटों के बीच rsync प्रक्रियाएं सेट अप करना चाह सकते हैं और जब आप उन्हें PROD साइट पर लागू करते हैं तो DR साइट पर डेटाबेस और AD ऑनलाइन पैचिंग (ADOP) पैच लागू करें।
हमारी डेटा सेवाओं के बारे में अधिक जानें।
कोई टिप्पणी करने या प्रश्न पूछने के लिए फीडबैक टैब का उपयोग करें। आप हमसे बातचीत भी शुरू कर सकते हैं।