Computer >> Hướng Dẫn Máy Tính >  >> Lập Trình >> Cơ Sở Dữ Liệu

Hướng Dẫn Bước Đi Patching APPS & DR Instances Trong Oracle EBS 12.2

Bài viết bao gồm bảo trì và patching hệ thống disaster recovery (DR) cho Oracle® E-business Suite® (EBS) R12.2.9. Nó mô tả quy trình chung để áp dụng patch database DB và application (APPS) cho hệ thống DR Oracle phiên bản 12.2 Applications.

Giới thiệu

Các bước tạo site DR application gần như giống như tạo hệ thống clone, chúng tôi đã bao gồm trong bài blog trước.

Trong thời điểm thảm họa, bạn chỉ cần thực hiện một vài thay đổi cho file XML về hostname, và hệ thống backup của bạn đã sẵn sàng chạy. Để giữ hệ thống in sync, bạn cần thường xuyên áp dụng patch cho môi trường database và application server.

Đảm bảo bạn đã cấu hình physical standby database với primary database server và cả hai database đều in sync. Sau đó, bạn cần áp dụng tất cả patch cho hệ thống DR applications.

Các bước cấp cao cho quy trình này bao gồm:

  1. Tắt archiving và chuyển DR sang snapshot standby từ physical standby.
  2. Tắt DR database để áp dụng database patch.
  3. Khởi động DR database ở chế độ standby snapshot và chạy script dọn dẹp node.
  4. Flip file systems cho DR applications nếu chúng không khớp với hệ thống PROD.
  5. Khi hệ thống ở chế độ downtime, áp dụng patch.
  6. Chuyển DR về physical standby sau khi hoàn tất patching application DR servers.

Quy trình liên quan đến thiết kế một hệ thống đơn giản và đặt nó cho application switchover. Nếu bạn gặp thảm họa phía application, hệ thống này phải luôn in sync với primary site ở mọi cấp độ patch.

1. Chuyển DR sang Snapshot Standby từ Physical Standby

Đầu tiên, tắt archive log shipping và chuyển primary DR database sang chế độ standby snapshot:

  1. Đăng nhập primary production database node1 với oracle.
  2. Chạy các lệnh sau: 
    $. 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

Sau đó, hủy redo-log application trên DR database và chuyển sang snapshot standby mode:

  1. Đăng nhập DR database node1 với oracle.
  2. Chạy các lệnh sau: 
    $. 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. Tắt DR database để áp dụng database patches

Tắt database trên cả hai node và áp dụng database patches. Chạy các lệnh sau để áp dụng database patches:

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

Sử dụng các bước trước để áp dụng database patches trên tất cả các node hệ thống Real Application Cluster (RAC).

3. Chuyển database sang snapshot mode

Chuyển DR database sang snapshot standby mode và chạy auto-config sau khi dọn dẹp node:

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

Bây giờ, chuẩn bị hệ thống application DR cho patching. Sau khi chu kỳ patching hoàn tất trên production system, file system flip sau cutover. Kết quả là, production và DR file systems có thể không giữ nguyên. Các bước sau giải quyết vấn đề này. Các bước này, bạn chạy trên DB và APPS nodes, loại bỏ mọi tham chiếu production trong DR database.

Dọn dẹp các node

Chạy các bước sau để chuẩn bị dọn dẹp node:

  1. Đăng nhập DR database node1 với oracle.
  2. Chạy các lệnh sau: 
    $. drinstance.env $ sqlplus apps/apps-passwd exec fnd_conc_clone.setup_clean; truncate table applsys.adop_valid_nodes;

Thực thi Autoconfig trên tất cả application và database tiers

Chạy adautoconfig trên database và application nodes.

DB nodes:

  1. Đăng nhập DR database node1 với oracle và chạy các lệnh sau: 
    $. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.sh
  2. Đăng nhập DR DB node2 với oracle và chạy các lệnh sau: 
    $. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.sh

Application nodes—Run FS:

  1. Đăng nhập DR application node1 với applmgr và chạy các lệnh sau: 
    $. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
  2. Đăng nhập DR application node2 với applmgr và chạy các lệnh sau: 
    $. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
  3. Đăng nhập DR external application node1 với applmgr và chạy các lệnh sau: 
    $. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
  4. Đăng nhập DR external application node2 với applmgr và chạy các lệnh sau: 
    $. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh

Application nodes—Patch FS

  1. Đăng nhập DR application node1 với applmgr và chạy các lệnh sau: 
    $. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
  2. Đăng nhập DR application node2 với applmgr và chạy các lệnh sau: 
    $. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
  3. Đăng nhập DR external application node1 với applmgr và chạy các lệnh sau: 
    $. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
  4. Đăng nhập DR external application node2 với applmgr và chạy các lệnh sau: 
    $. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh

4. Flip file systems cho DR apps nếu không khớp với hệ thống PROD

Bạn chỉ cần thực hiện các bước sau nếu có sự khác biệt giữa RUN và PATCH file systems cho PROD và DR servers. Nếu chúng giống nhau, bạn có thể trực tiếp tiến hành áp dụng patch.

Thực hiện các bước sau trên tất cả DR APPS tier nodes:

  1. Đăng nhập mọi DR application node (external và internal) và thực thi các lệnh sau: 
    $. ./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 lại trên tất cả node để kiểm tra xem file system đã chuyển chưa.

DR giờ đã sẵn sàng cho application patching.

5. Áp dụng application patches cho DR application nodes ở chế độ downtime

Đầu tiên, vì bạn giữ application services ở DR down, bạn áp dụng patch cho RUN file system ở chế độ downtime bằng cách thực hiện các bước sau:

  1. Đăng nhập DR application node1.
  2. Chạy các lệnh sau: 
    $. drinstance.env $ adop phase=apply patches=<patch1, patch2> patchtop=/apps_stage/patch \ apply_mode=downtime options=nodbportion

Bạn có thể nhận được thông báo cảnh báo sau. Nếu có, tiếp tục bằng cách trả lời 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

Tiếp theo, áp dụng tất cả FMW Tier patches bằng quy trình chuẩn.

Để đồng bộ Run và Patch file systems, chạy các lệnh sau để các thay đổi trên RUN file system clone sang Patch file system:

$. drinstance.env $adop phase=fs_clone

6. Chuyển DR về physical standby sau khi application DR patching hoàn tất

Cuối cùng, bạn cần chuyển DR database về physical standby mode, bật redo apply cho DR database, và tiếp tục archive-log shipping từ PROD sang DR database.

Đầu tiên, chuyển DR database về physical standby:

  1. Đăng nhập DR database node1 và chạy các lệnh sau: 
    $. 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. Đăng nhập DR database node2 và khởi động instance bằng các lệnh sau: 
    $. drinstance.env $ sqlplus / as sysdba; startup;

Tiếp theo, bật archive log shipping trên primary database bằng các lệnh sau:

 1. Đăng nhập production database node1. 2. Chạy các lệnh sau: $. 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='*';

Kết luận

Bài viết mô tả cách quản lý hệ thống EBS application disaster với cập nhật và patch áp dụng cho site PROD EBS 12.2. Bạn không cần maintain backup của tất cả hệ thống application và restore từ backup. Bạn có thể muốn thiết lập quy trình rsync giữa PROD và DR sites và áp dụng database và AD Online Patching (ADOP) patches cho DR site khi bạn áp dụng cho PROD site.

Tìm hiểu thêm về dịch vụ Data của chúng tôi.

Sử dụng tab Feedback để đưa ra nhận xét hoặc đặt câu hỏi. Bạn cũng có thể bắt đầu cuộc trò chuyện với chúng tôi.