การแพตช์แอปและอินสแตนซ์ DR ใน EBS 12.2

โพสต์นี้ครอบคลุมถึงการบำรุงรักษาและการแก้ไขระบบการกู้คืนความเสียหาย (DR) สำหรับ Oracle® E-business Suite® (EBS) R12.2.9 อธิบายกระบวนการทั่วไปในการใช้โปรแกรมแก้ไขฐานข้อมูลและแอปพลิเคชัน (APPS) กับระบบ Oracle เวอร์ชัน 12.2 Applications DR

แนะนำตัว

ขั้นตอนในการสร้างไซต์แอปพลิเคชัน DR เกือบจะเหมือนกับการสร้างระบบโคลน ซึ่งเราได้กล่าวถึงในบล็อกโพสต์ก่อนหน้านี้

ในช่วงเวลาที่เกิดภัยพิบัติ คุณต้องทำการเปลี่ยนแปลงเพียงเล็กน้อยในไฟล์ XML สำหรับชื่อโฮสต์ และระบบสำรองข้อมูลของคุณก็พร้อมใช้งาน เพื่อให้ระบบไม่ซิงค์ คุณต้องใช้โปรแกรมแก้ไขกับฐานข้อมูลและสภาพแวดล้อมของเซิร์ฟเวอร์แอปพลิเคชันเป็นประจำ

ตรวจสอบให้แน่ใจว่าคุณกำหนดค่าฐานข้อมูลสแตนด์บายจริงด้วยเซิร์ฟเวอร์ฐานข้อมูลหลัก และฐานข้อมูลทั้งสองซิงค์กัน จากนั้น คุณต้องใช้แพตช์ทั้งหมดกับระบบแอปพลิเคชัน DR

ขั้นตอนระดับสูงสำหรับกระบวนการนี้ ได้แก่:

1. ปิดใช้งานการเก็บถาวรและแปลง DR เป็นสแตนด์บายสแน็ปช็อตจากโหมดสแตนด์บายจริง
2. ปิดฐานข้อมูล DR เพื่อใช้โปรแกรมแก้ไขฐานข้อมูล
3. เริ่มฐานข้อมูล DR ในโหมดสแน็ปช็อตสแตนด์บายและเรียกใช้สคริปต์การล้างโหนด
4. พลิกระบบไฟล์สำหรับแอปพลิเคชัน DR หากไม่ตรงกับระบบ PROD
5. เมื่อระบบอยู่ในโหมดหยุดทำงาน ให้ใช้โปรแกรมแก้ไข
6. แปลง DR กลับเป็นโหมดสแตนด์บายจริงหลังจากที่คุณแก้ไขเซิร์ฟเวอร์ DR ของแอปพลิเคชันเสร็จสิ้น

กระบวนการนี้เกี่ยวข้องกับการออกแบบระบบที่เรียบง่ายและวางระบบสำหรับการสลับแอปพลิเคชัน หากคุณประสบปัญหาด้านแอปพลิเคชัน ระบบนี้จะต้องซิงค์กับไซต์หลักในทุกระดับของแพตช์

1. แปลง DR เป็น Snapshot Standby จากโหมดสแตนด์บายจริง

ขั้นแรก ปิดใช้งานการจัดส่งบันทึกที่เก็บถาวรและแปลงฐานข้อมูล DR หลักเป็นโหมดสแนปชอตสแตนด์บาย:

1. เข้าสู่ระบบฐานข้อมูลการผลิตหลัก node1 ในชื่อ oracle .

2. เรียกใช้คำสั่งต่อไปนี้:

   $. 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 และแปลงเป็นโหมดสแตนด์บายสแนปช็อต:

1. เข้าสู่ระบบฐานข้อมูล DR node1 ในชื่อ oracle .

2. เรียกใช้คำสั่งต่อไปนี้:

   $. 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

ใช้ขั้นตอนก่อนหน้าเพื่อใช้โปรแกรมแก้ไขฐานข้อมูลกับโหนดระบบ Real ApplicationCluster (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

ล้างโหนด

เรียกใช้ขั้นตอนต่อไปนี้เพื่อเตรียมล้างโหนด:

1. เข้าสู่ระบบฐานข้อมูล DR node1 ในชื่อ oracle .

2. เรียกใช้คำสั่งต่อไปนี้:

   $. drinstance.env
   $ sqlplus apps/apps-passwd
   exec fnd_conc_clone.setup_clean;
   truncate table applsys.adop_valid_nodes;
   

ดำเนินการ Autoconfig บนทุกระดับแอปพลิเคชันและฐานข้อมูล

เรียกใช้ adautoconfig บนฐานข้อมูลและโหนดแอปพลิเคชัน

โหนดฐานข้อมูล:

1. เข้าสู่ระบบฐานข้อมูล DR node1 ในชื่อ oracle และรันคำสั่งต่อไปนี้:

   $. drinstance.env
   $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/
   $ sh adautocfg.sh
   

2. ล็อกออนเข้าสู่ DR DB node2 เป็น oracle และรันคำสั่งต่อไปนี้:

   $. drinstance.env
   $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/
   $ sh adautocfg.sh
   

โหนดแอปพลิเคชัน—เรียกใช้ FS:

1. เข้าสู่ระบบแอปพลิเคชัน DR node1 เป็น applmgr และรันคำสั่งต่อไปนี้:

   $. drinstance.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

2. เข้าสู่ระบบแอปพลิเคชัน DR node2 ด้วย applmgr และรันคำสั่งต่อไปนี้:

   $. drinstance.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

3. เข้าสู่ระบบ DR แอปพลิเคชันภายนอก node1 เป็น applmgr และรันคำสั่งต่อไปนี้:

   $. drinstance.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

4. เข้าสู่ระบบ DR แอปพลิเคชันภายนอก node2 เป็น applmgr และรันคำสั่งต่อไปนี้:

   $. drinstance.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

โหนดแอปพลิเคชัน—แพตช์ FS

1. เข้าสู่ระบบแอปพลิเคชัน DR node1 เป็น applmgr และรันคำสั่งต่อไปนี้:

   $. drinstance_patch.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

2. เข้าสู่ระบบแอปพลิเคชัน DR node2 ด้วย applmgr และรันคำสั่งต่อไปนี้:

   $. drinstance_patch.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

3. เข้าสู่ระบบ DR แอปพลิเคชันภายนอก node1 เป็น applmgr และรันคำสั่งต่อไปนี้:

   $. drinstance_patch.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

4. เข้าสู่ระบบ DR แอปพลิเคชันภายนอก node2 เป็น applmgr และรันคำสั่งต่อไปนี้:

   $. drinstance_patch.env
   $ cd $ADMIN_SCRIPTS_HOME
   $ sh adautocfg.sh
   

4. พลิกระบบไฟล์สำหรับแอป DR หากไม่ตรงกับระบบ PROD

คุณต้องดำเนินการตามขั้นตอนต่อไปนี้ก็ต่อเมื่อมีความแตกต่างระหว่างระบบไฟล์ RUN และ PATCH สำหรับเซิร์ฟเวอร์ PROD และ DR หากเหมือนกัน คุณสามารถใช้แพตช์ได้โดยตรง

ดำเนินการขั้นตอนต่อไปนี้บนโหนดระดับ DR APPS ทั้งหมด:

1. เข้าสู่ระบบทุกโหนดแอปพลิเคชัน 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>
   

2. จัดหาสภาพแวดล้อมอีกครั้งบนโหนดทั้งหมดเพื่อตรวจสอบว่าระบบไฟล์สลับหรือไม่

ตอนนี้ DR พร้อมสำหรับการแพตช์แอปพลิเคชันแล้ว

5. ใช้โปรแกรมแก้ไขแอปพลิเคชันกับโหนดแอปพลิเคชัน DR ในโหมดหยุดทำงาน

ประการแรก เนื่องจากคุณเก็บบริการแอปพลิเคชันไว้ที่ DR คุณจึงใช้โปรแกรมแก้ไขกับระบบไฟล์ RUN ในโหมดหยุดทำงานโดยทำตามขั้นตอนต่อไปนี้:

1. เข้าสู่ระบบ DR application node1.

2. เรียกใช้คำสั่งต่อไปนี้:

   $. 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 Tier ทั้งหมดโดยใช้ขั้นตอนมาตรฐาน

ในการซิงโครไนซ์ระบบไฟล์ Run และ Patch ให้รันคำสั่งต่อไปนี้เพื่อให้การเปลี่ยนแปลงที่ทำกับระบบไฟล์ RUN โคลนไปยังระบบไฟล์ Patch:

$. drinstance.env$adop phase=fs_clone

6. แปลง DR กลับเป็นโหมดสแตนด์บายจริงหลังจากโปรแกรมแก้ไข DR ของแอปพลิเคชันเสร็จสิ้น

สุดท้าย คุณต้องแปลงฐานข้อมูล DR กลับเป็นโหมดสแตนด์บายทางกายภาพ เปิดใช้งาน redo apply ไปยังฐานข้อมูล DR และดำเนินการจัดส่งบันทึกการเก็บถาวรต่อจาก thePROD ไปยังฐานข้อมูล DR

ขั้นแรก ให้แปลงฐานข้อมูล DR กลับเป็นโหมดสแตนด์บายจริง:

1. เข้าสู่ระบบฐานข้อมูล DR node1 และเรียกใช้คำสั่งต่อไปนี้:

   $. 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;
   

2. เข้าสู่ระบบฐานข้อมูล DR node2 และเริ่มต้นอินสแตนซ์โดยเรียกใช้คำสั่งต่อไปนี้:

   $. 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='*';

บทสรุป

โพสต์นี้อธิบายวิธีจัดการระบบแอปพลิเคชัน EBS ที่เกิดภัยพิบัติด้วยการอัปเดตและโปรแกรมแก้ไขที่ใช้กับไซต์ PROD EBS 12.2 คุณไม่จำเป็นต้องดูแลรักษาระบบสำรองของแอปพลิเคชันทั้งหมด จากนั้นกู้คืนระบบจากข้อมูลสำรอง คุณอาจต้องการตั้งค่า rsync ประมวลผลระหว่างไซต์ PROD และ DR และใช้ฐานข้อมูลและโปรแกรมแก้ไข AD Online Patching (ADOP) กับไซต์ DR เมื่อคุณนำไปใช้กับไซต์ PROD

เรียนรู้เพิ่มเติมเกี่ยวกับบริการข้อมูลของเรา

ใช้แท็บคำติชมเพื่อแสดงความคิดเห็นหรือถามคำถาม คุณสามารถเริ่มการสนทนากับเราได้