home

หน้าแรก
 Computer >> บทช่วยสอนคอมพิวเตอร์ >  >> การเขียนโปรแกรม >> ฐานข้อมูล

คู่มือ Patch APPS และ DR Instances ใน Oracle EBS 12.2 แบบขั้นตอน

บทความนี้ครอบคลุมการบำรุงรักษาและ patching ของ disaster recovery (DR) systems สำหรับ Oracle® E-business Suite® (EBS) R12.2.9 อธิบายกระบวนการทั่วไปในการ apply database DB และ application (APPS) patches ไปยัง Oracle version 12.2 Applications DR systems

บทนำ

ขั้นตอนในการสร้าง DR application site เกือบเหมือนกับการสร้าง clone system ซึ่งเราเคยครอบคลุมในบล็อกโพสต์ก่อนหน้า

ในช่วงเวลาที่เกิดภัยพิบัติ คุณต้องทำการเปลี่ยนแปลงเพียงเล็กน้อยใน XML files สำหรับ hostnames และระบบ backup ของคุณก็พร้อมทำงานแล้ว เพื่อให้ระบบอยู่ใน sync คุณต้อง apply patches ไปยัง database และ application server environments อย่างสม่ำเสมอ

ตรวจสอบให้แน่ใจว่าคุณได้กำหนดค่า physical standby database กับ primary database server และทั้งสอง databases ใน sync แล้ว จากนั้นคุณต้อง apply patches ทั้งหมดไปยัง DR applications systems

High-level steps สำหรับกระบวนการนี้รวมถึง:

  1. Disable archiving และ convert DR เป็น snapshot standby จาก physical standby
  2. Shut down DR database เพื่อ apply database patches
  3. Start DR databases ใน standby snapshot mode และรัน node cleanup scripts
  4. Flip file systems สำหรับ DR applications หากไม่ตรงกับ PROD system
  5. เมื่อระบบอยู่ใน downtime mode ให้ apply patches
  6. Convert DR กลับเป็น physical standby หลังจาก patching DR application servers เสร็จ

กระบวนการเกี่ยวข้องกับการออกแบบระบบง่ายๆ และวางไว้สำหรับ application switchover หากคุณประสบภัยพิบัติด้าน application ระบบนี้ต้องอยู่ใน sync กับ primary site ที่ทุกระดับ patch

1. Convert DR เป็น Snapshot Standby จาก Physical Standby

ก่อนอื่น disable archive log shipping และ convert primary DR database เป็น standby snapshot mode:

  1. ล็อกอิน primary production database 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

จากนั้น cancel redo-log application บน DR database และ convert เป็น snapshot standby mode:

  1. ล็อกอิน DR database 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. Shutdown DR Database เพื่อ Apply Database Patches

Shut down database บนทั้งสองโหนดและ apply database patches รันคำสั่งต่อไปนี้เพื่อ apply database patches:

 $. prodinstance.env
$ sqlplus / as sysdba
shut immediate;
$ cd $PATCH_DIR
$ opatch apply

ใช้ขั้นตอนก่อนหน้านี้เพื่อ apply database patches บนทุก Real Application Cluster (RAC) system nodes

3. Convert Database เป็น Snapshot Mode

Convert DR database เป็น snapshot standby mode และรัน auto-config หลังจาก nodes cleanup:

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

ตอนนี้เตรียม application DR system สำหรับ patching หลังจาก patching cycle เสร็จสิ้นบน production system file system จะ flip หลัง cutover ผลลัพธ์คือ production และ DR file systems อาจไม่เหมือนกัน ขั้นตอนต่อไปนี้จัดการกับข้อกังวลนี้ ขั้นตอนเหล่านี้ซึ่งรันบน DB และ APPS nodes จะลบ production references ใดๆ ใน DR database

Cleanup the Nodes (ทำความสะอาดโหนด)

รันขั้นตอนต่อไปนี้เพื่อเตรียม cleanup nodes:

  1. ล็อกอิน DR database node1 เป็น oracle
  2. รันคำสั่งต่อไปนี้: 
    $. drinstance.env
$ sqlplus apps/apps-passwd
exec fnd_conc_clone.setup_clean;
truncate table applsys.adop_valid_nodes;

Execute Autoconfig บน Application และ Database Tiers ทั้งหมด

รัน adautoconfig บน database และ application nodes

DB nodes:

  1. ล็อกอิน DR database 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

Application nodes—Run FS:

  1. ล็อกอิน DR application node1 เป็น applmgr และรันคำสั่งต่อไปนี้: 
    $. drinstance.env
$ cd $ADMIN_SCRIPTS_HOME
$ sh adautocfg.sh
  2. ล็อกอิน DR application node2 เป็น applmgr และรันคำสั่งต่อไปนี้: 
    $. drinstance.env
$ cd $ADMIN_SCRIPTS_HOME
$ sh adautocfg.sh
  3. ล็อกอิน DR external application node1 เป็น applmgr และรันคำสั่งต่อไปนี้: 
    $. drinstance.env
$ cd $ADMIN_SCRIPTS_HOME
$ sh adautocfg.sh
  4. ล็อกอิน DR external application node2 เป็น applmgr และรันคำสั่งต่อไปนี้: 
    $. drinstance.env
$ cd $ADMIN_SCRIPTS_HOME
$ sh adautocfg.sh

Application nodes—Patch FS

  1. ล็อกอิน DR application node1 เป็น applmgr และรันคำสั่งต่อไปนี้: 
    $. drinstance_patch.env
$ cd $ADMIN_SCRIPTS_HOME
$ sh adautocfg.sh
  2. ล็อกอิน DR application node2 เป็น applmgr และรันคำสั่งต่อไปนี้: 
    $. drinstance_patch.env
$ cd $ADMIN_SCRIPTS_HOME
$ sh adautocfg.sh
  3. ล็อกอิน DR external application node1 เป็น applmgr และรันคำสั่งต่อไปนี้: 
    $. drinstance_patch.env
$ cd $ADMIN_SCRIPTS_HOME
$ sh adautocfg.sh
  4. ล็อกอิน DR external application node2 เป็น applmgr และรันคำสั่งต่อไปนี้: 
    $. drinstance_patch.env
$ cd $ADMIN_SCRIPTS_HOME
$ sh adautocfg.sh

4. Flip File Systems สำหรับ DR Apps หากไม่ตรงกับ PROD System

คุณต้อง execute ขั้นตอนต่อไปนี้ก็ต่อเมื่อมีความแตกต่างระหว่าง RUN และ PATCH file systems สำหรับ PROD และ DR servers หากเหมือนกัน คุณสามารถดำเนินการ apply patches โดยตรงได้

Execute ขั้นตอนต่อไปนี้บน DR APPS tier nodes ทั้งหมด:

  1. ล็อกอินทุก DR application node (external และ internal) และ execute คำสั่งต่อไปนี้: 
    $. ./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. Source environment อีกครั้งบนทุกโหนดเพื่อตรวจสอบว่า file system switched แล้วหรือยัง

DR ตอนนี้พร้อมสำหรับ application patching แล้ว

5. Apply Application Patches ไปยัง DR Application Nodes ใน Downtime Mode

ก่อนอื่น เนื่องจากคุณเก็บ application services ที่ DR ไว้ down คุณ apply patches ไปยัง RUN file system ใน downtime mode โดยทำตามขั้นตอนต่อไปนี้:

  1. ล็อกอิน DR application node1
  2. รันคำสั่งต่อไปนี้: 
    $. drinstance.env
$ adop phase=apply patches=<patch1, patch2> patchtop=/apps_stage/patch \ apply_mode=downtime options=nodbportion

คุณอาจได้รับ warning message ต่อไปนี้ หากได้ ให้ดำเนินต่อโดยตอบ 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

ต่อไป apply FMW Tier patches ทั้งหมดโดยใช้ standard procedure

เพื่อ synchronize Run และ Patch file systems รันคำสั่งต่อไปนี้ เพื่อให้การเปลี่ยนแปลงที่ทำที่ RUN file system clone ไปยัง Patch file system:

$. drinstance.env $adop phase=fs_clone

6. Convert DR กลับเป็น Physical Standby หลังจาก Application DR Patching เสร็จ

สุดท้าย คุณต้อง convert DR database กลับเป็น physical standby mode เปิดใช้งาน redo apply ไปยัง DR database และ resume archive-log shipping จาก PROD ไป DR database

ก่อนอื่น convert DR database กลับเป็น physical standby:

  1. ล็อกอิน DR database 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 database node2 และ startup instance โดยรันคำสั่งต่อไปนี้: 
    $. drinstance.env
$ sqlplus / as sysdba;
startup;

ต่อไป เปิดใช้งาน archive log shipping บน primary database โดยรันคำสั่งต่อไปนี้:

 1. ล็อกอิน production database node1
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='*';

สรุป

บทความนี้อธิบายวิธีจัดการ disaster EBS application system ด้วย updates และ patches ที่ apply ไปยัง PROD EBS 12.2 site คุณไม่จำเป็นต้อง maintain backup ของ application systems ทั้งหมดแล้ว restore จาก backup คุณอาจต้องการตั้งค่า rsync processes ระหว่าง PROD และ DR sites และ apply database และ AD Online Patching (ADOP) patches ไปยัง DR site เมื่อคุณ apply ไปยัง PROD site

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

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