แอปพลิเคชัน Oracle EBS สำหรับการกู้คืนจากภัยพิบัติ

บล็อกนี้ครอบคลุมถึงการสร้างและบำรุงรักษาระบบการกู้คืนความเสียหาย (DR) สำหรับแอปพลิเคชัน Oracle® Enterprise Business Suites (EBS) และอธิบายขั้นตอนทั่วไปในการสร้างระบบ DR ของแอปพลิเคชันเวอร์ชัน 12.2 โดยใช้ระบบเวอร์ชัน 12.2.5 ในพื้นที่ทดสอบ

แนะนำตัว

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

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

ขั้นตอนการกำหนดค่า DR

บทความนี้สำรวจขั้นตอนระดับสูงต่อไปนี้ในการกำหนดค่าระบบ DR:

ปิดใช้งานการเก็บถาวรและแปลงระบบ DR จากสแตนด์บายทางกายภาพ โหมดสแน็ปช็อตสแตนด์บาย โหมด
คัดลอกแอปพลิเคชันจากไซต์หลักไปยังไซต์ DR โดยเรียกใช้preclone .
กำหนดค่า node1 ด้วย dualfs .
เพิ่มโหนดพิเศษเพื่อให้ตรงกับไซต์ PROD
ตรวจสอบบริการโดยเริ่มต้นและปิดโหนด1
ตั้งค่าระบบ DR กลับเป็นโหมดสแตนด์บายจริงหลังจากตั้งค่า ApplicationsDR แล้ว

1. ตั้งค่าระบบ DR เป็นโหมดสแตนด์บายสแน็ปช็อต

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

$ dgmgrl /
$ edit database "TESTDR" set state=apply-off;

เรียกใช้รหัสต่อไปนี้เพื่อกำหนดค่าฐานข้อมูลสแตนด์บายเพื่อใช้ flashbacklogging สำหรับการทำงานของฐานข้อมูลย้อนหลัง:

SQL> alter system set db_recovery_file_dest_size=1000G scope=both;
SQL> alter system set db_recovery_file_dest='+FRA' scope=both;
SQL> alter system set db_flashback_retention_target=1440 scope=both;

$ Shutdown node2 DR DB
$ sqlplus '/as sysdba'

SQL> shutdown immediate;

เรียกใช้รหัสต่อไปนี้บน node1 ของ DR DB:

$ sqlplus '/as sysdba'

SQL> shutdown immediate;

SQL> startup mount;
SQL> alter database convert to snapshot standby;
SQL> alter database open;
SQL> select name, DB_UNIQUE_NAME, OPEN_MODE, DATABASE_ROLE from v$database;

NAME      DB_UNIQUE_NAME                 OPEN_MODE            DATABASE_ROLE
--------- ------------------------------ -------------------- ----------------
TESTPRD  TESTDR                        READ ONLY WITH APPLY              SNAPSHOT STANDBY

เรียกใช้รหัสต่อไปนี้เพื่อเริ่มต้น node2 ของ DR DB ในโหมดต่อเชื่อม:

$ sqlplus '/as sysdba'

SQL> startup  mount;

2. เรียกใช้ preclone และล้าง fnd_nodes

เรียกใช้รหัสต่อไปนี้เพื่อล้าง fnd_nodes :

SQL> exec fnd_conc_clone.setup_clean;
SQL> exec ad_zd_fixer.clear_valid_nodes_info;

เรียกใช้ auto-config บนโหนด DR DB ตามลำดับต่อไปนี้:node1, node2,node1.

เรียกใช้ preclone บนระดับแอปพลิเคชัน PROD และคัดลอกไฟล์แอปพลิเคชันจาก RUN file system (FS) node1 ไปยังแอปพลิเคชัน DR tiernode1 FS ที่สอดคล้องกัน

3. เรียกใช้ dualfs

บนระดับแอปพลิเคชัน node1 DR ให้เรียกดู FS และเรียกใช้โค้ดต่อไปนี้:

$ perl adcfgclone.pl appsTier dualfs from <APPL_BASE>/<SID>/apps/<RUN-FS>/EBSapps/comn/clone/bin

หากคุณเห็นข้อความแจ้งต่อไปนี้ แสดงว่า adcfgclone เสร็จสมบูรณ์และคุณสามารถละเว้นข้อผิดพลาดในการกำหนดค่าอัตโนมัติได้:

Do you want to startup the Application Services for ……..? (y/n) [n] :

4. เพิ่มโหนดให้ตรงกับไซต์ PROD

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

$ scp prodnode1:/home/applmgr/prodprd.env /home/applmgr/proddr.env
$ scp prodnode1:/home/applmgr/prodprd_run.env /home/applmgr/proddr_run.env
$ scp prodnode1:/home/applmgr/prodprd_patch.env /home/applmgr/proddr_patch.env

ทำซ้ำคำสั่งก่อนหน้าสำหรับโหนดอื่นทั้งหมด

ที่มา env และเรียกใช้ auto-config สำหรับ RUN และ PATCH FS ตัวอย่างต่อไปนี้แสดงผลที่คาดหวัง:

Configuring OZF_TOP.......COMPLETED
Configuring CSD_TOP.......COMPLETED
Configuring IGC_TOP.......COMPLETED

AutoConfig completed successfully.

Configuring OZF_TOP.......COMPLETED
Configuring CSD_TOP.......COMPLETED
Configuring IGC_TOP.......COMPLETED

AutoConfig completed with errors.

หมายเหตุ: ละเว้นข้อผิดพลาด PATCH FS

5. ทดสอบ

รันโค้ดต่อไปนี้เพื่อทดสอบการกำหนดค่าโดยวนรอบโหนดแรก:

$ . ./proddr.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adstrtal.sh apps/<passwd>

เรียกใช้รหัสต่อไปนี้เพื่อตรวจสอบ URL เข้าสู่ระบบ และปิดแอปพลิเคชัน:

$ cd $ADMIN_SCRIPTS_HOME
$ ./adstpall.sh apps/<passwd>

คล้ายกับกระบวนการโคลนปกติ เพิ่มโหนดเพิ่มเติมเพื่อให้ตรงกับโครงสร้างพื้นฐานของ PROD เรียกใช้ preclone บนโหนดเป้าหมาย1, RUN และ PATCH FS จากนั้น เพิ่มโหนด เริ่มบริการเซิร์ฟเวอร์ผู้ดูแลระบบสำหรับ RUN และ PATCH FS และเรียกใช้preclone ดังแสดงในโค้ดต่อไปนี้:

$ . ~/testdr.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adpreclone.pl appsTier
$ . ~/testdr_patch.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adpreclone.pl appsTier
$ cd  <RUN_FS_TOP>/EBSapps/comn/clone/bin
$./adclonectx.pl addnode contextfile=<NODE1_RUNFS_CONTEXT.xml> pairsfile=/common_area/applcsf/testprd/pairsfile/mypairsfile.txt
dualfs=yes

เรียกใช้รหัสต่อไปนี้เพื่อกำหนดค่า node2:

$ cd  <RUN_FS_TOP>/EBSapps/comn/clone/bin
$ ./adclonectx.pl addnode contextfile=<NODE1_RUNFS_CONTEXT.xml> pairsfile=/common_area/applcsf/testprd/pairsfile/mypairsfile.txt
dualfs=yes
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \
  -contextfile=<RUN-FS-CONTEXT.xml \
  -configoption=addMS \
  -oacore=testdr2.sherwin.com:<port> \
  -oafm=testdr2.sherwin.com:<port> \
  -forms=testdr2.sherwin.com:<port> \
  -formsc4ws=testdr2.sherwin.com:<port>    -- All ports information is available in context file.

ในทำนองเดียวกัน เพิ่มโหนดอื่นหรือระดับภายนอกเพื่อให้ตรงกับระบบ PROD

6. แปลงระบบ DR เป็นโหมดสแตนด์บายทางกายภาพ

หลังจากที่คุณเพิ่มโหนดทั้งหมดแล้ว ให้ปิดบริการทั้งหมดบน DRsystem แปลง DR DB กลับเป็นโหมดสแตนด์บายทางกายภาพ และตั้งค่า dataguardto ON .

เรียกใช้รหัสต่อไปนี้เพื่อปิดบริการบน DR DB เริ่มต้นการต่อเชื่อม และแปลง DR DR เป็นโหมดสแตนด์บายทางกายภาพ:

SQL> alter database convert to physical standby;
DGMGRL> edit database "TESTDR" set state=apply-on;

ตรวจสอบการซิงโครไนซ์ คุณควรคาดหวังว่าจะได้เห็นผลลัพธ์ที่คล้ายกับตัวอย่างต่อไปนี้:

### Monitor to see Transport Lag and Apply Lag to be:
Transport Lag:      0 seconds (computed 0 seconds ago)
Apply Lag:          0 seconds (computed 0 seconds ago)

บทสรุป

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

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

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

เราเป็นผู้เชี่ยวชาญเกี่ยวกับผลิตภัณฑ์ Oracle ดังนั้นให้ Rackspace ช่วยคุณเพิ่มการลงทุน Oracle ของคุณให้สูงสุด

หากคุณต้องการข้อมูลเพิ่มเติมเกี่ยวกับโซลูชันการกู้คืนความเสียหายของ Rackspace ดาวน์โหลดเอกสารไวท์เปเปอร์นี้