이 블로그는 Oracle® EBS(Enterprise Business Suite) 애플리케이션용 재해 복구(DR) 시스템의 생성 및 유지 관리에 대해 설명하고 테스트 영역에서 버전 12.2.5 시스템을 사용하여 버전 12.2 애플리케이션 DR 시스템을 생성하는 일반적인 프로세스를 설명합니다.
소개
DR 응용 프로그램 사이트를 만드는 단계는 복제 시스템을 만드는 데 사용되는 단계와 유사합니다. 재해가 발생한 경우 호스트 이름과 같은 XML 파일을 약간 변경해야 시스템을 실행할 수 있습니다. 시스템을 동기화 상태로 유지하려면 rsync와 같은 동기화 스크립트를 실행하십시오. , 모든 변경 사항으로 DRsite를 업데이트합니다. DR DB 데이터베이스와 DR 사이트 애플리케이션 노드에 패치를 적용합니다.
다음 단계에서 물리적 대기 데이터베이스가 기본 데이터베이스 서버와 이미 구성되어 있고 둘 다 동기화되어 있음을 확인합니다.
DR 구성 단계
이 문서에서는 DR 시스템을 구성하기 위한 다음과 같은 높은 수준의 단계를 살펴봅니다.
- 보관을 비활성화하고 DR 시스템을 물리적 대기에서 변환 스냅샷 대기 모드 모드.
preclone을 실행하여 기본 사이트에서 DR 사이트로 애플리케이션 복사 .dualfs으로 node1 구성 .- PROD 사이트와 일치하도록 노드를 추가합니다.
- node1을 시작하고 종료하여 서비스를 확인합니다.
- applicationDR이 설정된 후 DR 시스템을 물리적 대기 모드로 다시 설정합니다.
1. DR 시스템을 스냅샷 대기 모드로 설정
다음 코드를 실행하여 로그 적용을 비활성화하고 DR 데이터베이스를 대기 스냅샷 모드로 설정합니다.
$ dgmgrl /
$ edit database "TESTDR" set state=apply-off;
다음 코드를 실행하여 플래시백 데이터베이스 작업에 플래시백 로깅을 사용하도록 대기 데이터베이스를 구성합니다.
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;
DR DB의 node1에서 다음 코드를 실행합니다.
$ 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
마운트 모드에서 DR DB의 node2를 시작하려면 다음 코드를 실행하십시오.
$ sqlplus '/as sysdba'
SQL> startup mount;
2. 사전 복제를 실행하고 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 파일 시스템(FS) 노드1에서 해당 DR 응용 프로그램 계층 노드1 FS로 복사합니다.
3. 이중화 실행
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 실행 대상 node1, 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 시스템을 물리적 대기 모드로 전환
모든 노드를 추가한 후 DR 시스템에서 모든 서비스를 종료하고 DR DB를 다시 물리적 대기 모드로 변환하고 dataguard를 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)
결론
이 블로그는 검증된 DR 사이트가 있는 EBS 애플리케이션의 재해에 대비하는 방법을 설명합니다. 컨텍스트 파일에서 몇 가지 매개변수를 업데이트하면 시스템이 가동되고 실행됩니다. 모든 응용 프로그램 시스템의 백업을 유지 관리한 다음 백업에서 시스템을 복원할 필요가 없습니다. rsync를 설정하고 싶을 수도 있습니다. PROD와 DR 사이트 간의 프로세스를 처리하고 PROD 사이트에 적용함과 동시에 DB 및 ADOP(ADOnline Patching) 패치를 DR 사이트에 적용합니다.
피드백 탭을 사용하여 의견을 남기거나 질문하십시오.
데이터베이스 서비스에 대해 자세히 알아보십시오.
우리는 Oracle 제품의 전문가이므로 Rackspace를 통해 Oracle 투자를 극대화할 수 있습니다.
Rackspace 재해 복구 솔루션에 대한 자세한 내용을 보려면 이 백서를 다운로드하십시오.