Blog này đề cập đến việc tạo và bảo trì hệ thống khôi phục sau thảm họa (DR) cho các ứng dụng Oracle® Enterprise Business Suites (EBS) và mô tả quy trình cấp thời gian để tạo ứng dụng phiên bản 12.2 hệ thống DR bằng cách sử dụng hệ thống phiên bản 12.2.5 trong khu vực thử nghiệm.
Giới thiệu
Các bước để tạo một trang ứng dụng DR tương tự như các bước được sử dụng để tạo hệ thống sao chép. Trong trường hợp xảy ra sự cố, bạn cần thực hiện một số thay đổi đối với tệp XML, chẳng hạn như tên máy chủ và hệ thống sẽ sẵn sàng chạy. Để giữ cho hệ thống được đồng bộ hóa, hãy chạy bất kỳ tập lệnh đồng bộ hóa nào, chẳng hạn như rsync , cập nhật DRsite với bất kỳ thay đổi nào. Áp dụng các bản vá cho cơ sở dữ liệu DR DB cũng như cho các nút ứng dụng trang webDR.
Trong các bước sau, hãy lưu ý rằng cơ sở dữ liệu dự phòng vật lý được cấu hình thay đổi cấu hình với máy chủ cơ sở dữ liệu chính và cả hai đều được đồng bộ hóa.
Các bước cấu hình DR
Bài viết này khám phá các bước cấp cao sau để định cấu hình hệ thống DR:
- Tắt tính năng lưu trữ và chuyển đổi hệ thống DR từ chế độ chờ vật lý chế độ sang chế độ chờ chụp nhanh chế độ.
- Sao chép các ứng dụng từ trang chính sang trang DR bằng cách chạy
preclone. - Định cấu hình node1 với
dualfs. - Thêm các nút bổ sung để phù hợp với trang PROD.
- Kiểm tra các dịch vụ bằng cách khởi động và tắt node1.
- Đặt hệ thống DR trở lại chế độ chờ vật lý sau khi các ứng dụngDR được thiết lập.
1. Đặt hệ thống DR ở chế độ chờ chụp nhanh
Chạy mã sau để tắt áp dụng nhật ký và đặt cơ sở dữ liệu DR ở chế độ ảnh chụp đứng:
$ dgmgrl /
$ edit database "TESTDR" set state=apply-off;
Chạy mã sau để định cấu hình cơ sở dữ liệu dự phòng để sử dụng flashbacklogging cho các hoạt động của cơ sở dữ liệu flashback:
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;
Chạy mã sau trên node1 của 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
Chạy mã sau để khởi động node2 của DR DB ở chế độ gắn kết:
$ sqlplus '/as sysdba'
SQL> startup mount;
2. Chạy prelone và dọn dẹp fnd_nodes
Chạy mã sau để xóa fnd_nodes :
SQL> exec fnd_conc_clone.setup_clean;
SQL> exec ad_zd_fixer.clear_valid_nodes_info;
Chạy auto-config trên các nút DR DB theo trình tự sau:nút1, nút2, nút1.
Chạy preclone trên tầng ứng dụng PROD và sao chép các tệp ứng dụng từ hệ thống tệp RUN (FS) node1 sang các ứng dụng DR tương ứng tầng 1 FS.
3. Chạy dualfs
Trên tầng ứng dụng DR của node1, hãy duyệt đến FS và chạy mã sau:
$ perl adcfgclone.pl appsTier dualfs from <APPL_BASE>/<SID>/apps/<RUN-FS>/EBSapps/comn/clone/bin
Nếu bạn thấy lời nhắc sau, adcfgclone đã hoàn tất thành công và bạn có thể bỏ qua bất kỳ lỗi cấu hình tự động nào:
Do you want to startup the Application Services for ……..? (y/n) [n] :
4. Thêm các nút để khớp với trang PROD
Trên mỗi nút ứng dụng, sao chép env tệp từ PROD đến các nútDR tương đương. Chạy mã sau, thực hiện bất kỳ thay đổi tên tệp hoặc thư mục bắt buộc nào:
$ 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
Lặp lại các lệnh trước cho tất cả các nút khác.
Nguồn env và chạy auto-config cho RUN và PATCH FS. Các ví dụ sau đây cho thấy kết quả mong đợi:
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.
Lưu ý: Bỏ qua mọi lỗi PATCH FS.
5. Kiểm tra
Chạy mã sau để kiểm tra cấu hình bằng cách xoay nút đầu tiên:
$ . ./proddr.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adstrtal.sh apps/<passwd>
Chạy mã sau để kiểm tra URL, đăng nhập và tắt ứng dụng:
$ cd $ADMIN_SCRIPTS_HOME
$ ./adstpall.sh apps/<passwd>
Tương tự như quy trình nhân bản thông thường, hãy thêm các nút bổ sung để phù hợp với cơ sở hạ tầng PROD. Chạy preclone trên nút đích1, RUN và PATCH FS. Sau đó, thêm các nút. Khởi động các dịch vụ máy chủ quản trị cho RUN và PATCH FS và chạy preclone như được hiển thị trong đoạn mã sau:
$ . ~/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
Chạy mã sau để định cấu hình 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.
Tương tự, thêm các nút khác hoặc các lớp bên ngoài để phù hợp với hệ thống PROD.
6. Chuyển đổi hệ thống DR sang chế độ chờ vật lý
Sau khi bạn thêm tất cả các nút, hãy tắt tất cả các dịch vụ trên hệ thống DR, chuyển đổi DR DB trở lại chế độ chờ vật lý và đặt dataguardto ON .
Chạy mã sau để tắt các dịch vụ trên DR DB, khởi động mount và chuyển DR DR sang chế độ chờ vật lý:
SQL> alter database convert to physical standby;
DGMGRL> edit database "TESTDR" set state=apply-on;
Xác thực việc đồng bộ hóa. Bạn sẽ thấy kết quả tương tự như ví dụ sau:
### 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)
Kết luận
Blog này mô tả cách chuẩn bị cho một thảm họa trên các ứng dụng EBS với trang DR đã được xác thực. Sau khi cập nhật một vài tham số trong tệp ngữ cảnh, hệ thống sẽ hoạt động. Bạn không cần phải duy trì một bản sao lưu của tất cả các hệ thống ứng dụng và sau đó khôi phục hệ thống từ bản sao lưu. Bạn có thể muốn thiết lập rsync xử lý giữa các trang PROD và DR và áp dụng các bản vá DB và ADOnline Patch (ADOP) cho trang DR cùng lúc mà bạn áp dụng cho trang PROD.
Sử dụng tab Phản hồi để đưa ra bất kỳ nhận xét hoặc đặt câu hỏi nào.
Tìm hiểu thêm về các dịch vụ cơ sở dữ liệu của chúng tôi.
Chúng tôi là chuyên gia về các sản phẩm Oracle, vì vậy hãy để Rackspace giúp bạn tối đa hóa khoản đầu tư vào Oracle của mình.
Nếu bạn muốn biết thêm thông tin về các giải pháp khôi phục sau thảm họa Rackspace, hãy tải xuống sách trắng này.