home

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

Oracle EBS Disaster Recovery: ขั้นตอนที่พิสูจน์แล้วสร้างระบบที่ทนทาน

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

บทนำ

ขั้นตอนในการสร้าง DR application site คล้ายกับขั้นตอนที่ใช้สร้างระบบ clone ในกรณีของภัยพิบัติ คุณต้องทำการเปลี่ยนแปลงบางอย่างในไฟล์ XML เช่น host names และระบบจะพร้อมรัน เพื่อให้ระบบอยู่ในสภาพ sync ให้รันสคริปต์ซิงโครไนซ์ใดๆ เช่น rsync ซึ่งอัปเดต DR site ด้วยการเปลี่ยนแปลงใดๆ นำแพตช์ไปใช้กับ DR DB databases รวมถึง DR site application nodes

ในขั้นตอนต่อไปนี้ สังเกตว่า physical standby database ถูกกำหนดค่ากับ primary database server แล้ว และทั้งคู่อยู่ในสภาพ sync

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

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

  1. ปิดใช้งาน archiving และแปลงระบบ DR จากโหมด physical standby เป็นโหมด snapshot standby
  2. คัดลอกแอปพลิเคชันจาก primary site ไป DR site โดยรัน preclone
  3. กำหนดค่า node1 ด้วย dualfs
  4. เพิ่มโหนดเพิ่มเติมเพื่อให้ตรงกับ PROD site
  5. ตรวจสอบบริการโดยการเริ่มและปิด node1
  6. ตั้งค่าระบบ DR กลับเป็น physical standby mode หลังจากตั้งค่า applications DR แล้ว

1. ตั้งค่าระบบ DR เป็น snapshot standby mode

รันโค้ดต่อไปนี้เพื่อปิด log apply และตั้งค่า DR database เป็น standby snapshot mode:

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

รันโค้ดต่อไปนี้เพื่อกำหนดค่า standby database ให้ใช้ flashback logging สำหรับการดำเนินการ flashback database:

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

รันโค้ดต่อไปนี้เพื่อ startup node2 ของ DR DB ในโหมด mount:

$ 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 nodes ในลำดับต่อไปนี้: node1, node2, node1

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

3. รัน dualfs

บน node1 DR applications tier ให้ไปที่ FS และรันโค้ดต่อไปนี้:

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

หากคุณเห็น prompt ต่อไปนี้ adcfgclone เสร็จสิ้นแล้ว และคุณสามารถเพิกเฉยต่อข้อผิดพลาด autoconfiguration ได้:

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

4. เพิ่มโหนดเพื่อให้ตรงกับ PROD site

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

$ 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

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

Source 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. ทดสอบ

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

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

รันโค้ดต่อไปนี้เพื่อตรวจสอบ URL, login และ shutdown แอปพลิเคชัน:

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

คล้ายกับกระบวนการ cloning ปกติ ให้เพิ่มโหนดเพิ่มเติมเพื่อให้ตรงกับโครงสร้างพื้นฐาน PROD รัน preclone บน target node1, RUN, และ PATCH FS จากนั้นเพิ่มโหนด เริ่ม admin server services สำหรับ 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.

เช่นเดียวกัน ให้เพิ่มโหนดอื่นๆ หรือ external tiers เพื่อให้ตรงกับระบบ PROD

6. แปลงระบบ DR เป็น physical standby mode

หลังจากคุณเพิ่มโหนดทั้งหมดแล้ว ให้ปิดบริการทั้งหมดบนระบบ DR แปลง DR DB กลับเป็น physical standby mode และตั้งค่า dataguard เป็น ON

รันโค้ดต่อไปนี้เพื่อปิดบริการบน DR DB, startup mount และแปลง DR DR เป็น physical standby mode:

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 site ที่ได้รับการตรวจสอบแล้ว หลังจากอัปเดตพารามิเตอร์บางอย่างใน context file ระบบจะทำงานได้ทันที คุณไม่ต้องดูแลรักษาสำรองข้อมูลของระบบแอปพลิเคชันทั้งหมด และกู้คืนระบบจาก backup คุณอาจต้องการตั้งค่ากระบวนการ rsync ระหว่าง PROD และ DR sites และนำ DB และ AD Online Patching (ADOP) patches ไปใช้กับ DR site พร้อมกับเวลาที่คุณนำไปใช้กับ PROD site

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

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

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

หากคุณต้องการข้อมูลเพิ่มเติมเกี่ยวกับโซลูชัน disaster recovery ของ Rackspace ดาวน์โหลด white paper นี้