이 블로그는 Oracle® Enterprise Business Suites (EBS) 애플리케이션의 재해 복구 (DR) 시스템 생성 및 유지 관리를 다루며, 테스트 영역에서 버전 12.2.5 시스템을 사용하여 버전 12.2 애플리케이션 DR 시스템을 생성하는 일반적인 프로세스를 설명합니다.
소개
DR 애플리케이션 사이트를 생성하는 단계는 클론 시스템을 생성하는 데 사용되는 단계와 유사합니다. 재해 발생 시, 호스트 이름과 같은 XML 파일에 몇 가지 변경만 하면 시스템이 실행 준비가 됩니다. 시스템을 동기화 상태로 유지하려면 rsync와 같은 동기화 스크립트를 실행하여 변경 사항으로 DR 사이트를 업데이트하세요. DR DB 데이터베이스뿐만 아니라 DR 사이트 애플리케이션 노드에도 패치를 적용하세요.
다음 단계에서 물리적 스탠바이 데이터베이스가 이미 기본 데이터베이스 서버와 구성되어 있고 둘 다 동기화되어 있음을 알 수 있습니다.
DR 구성 단계
이 문서는 DR 시스템을 구성하기 위한 다음 높은 수준의 단계를 탐구합니다:
- 물리적 스탠바이 모드에서 스냅샷 스탠바이 모드로 아카이빙을 비활성화하고 DR 시스템을 변환합니다.
preclone을 실행하여 기본 사이트에서 DR 사이트로 애플리케이션을 복사합니다.dualfs로 node1을 구성합니다.- PROD 사이트와 일치하도록 추가 노드를 추가합니다.
- node1을 시작하고 종료하여 서비스를 확인합니다.
- 애플리케이션 DR이 설정된 후 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. preclone 실행 및 fnd_nodes 정리
fnd_nodes를 정리하려면 다음 코드를 실행하세요:
SQL> exec fnd_conc_clone.setup_clean; SQL> exec ad_zd_fixer.clear_valid_nodes_info; DR DB 노드에서 다음 순서로 auto-config를 실행하세요: node1, node2, node1.
PROD 애플리케이션 티어에서 preclone을 실행하고 RUN 파일 시스템 (FS) node1에서 해당 DR 애플리케이션 티어 node1 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 사이트와 일치하도록 노드 추가
각 애플리케이션 노드에서 PROD에서 해당 DR 노드로 env 파일을 복사하세요. 필요한 디렉토리 또는 파일 이름 변경으로 다음 코드를 실행하세요:
$ 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를 소스하고 RUN 및 PATCH FS에 대해 auto-config를 실행하세요. 다음 예제는 예상 결과를 보여줍니다:
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 인프라와 일치하도록 추가 노드를 추가하세요. 대상 node1, RUN, PATCH FS에서 preclone을 실행하세요. 그런 다음 노드를 추가하세요. 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> -- 모든 포트 정보는 컨텍스트 파일에 있습니다. 마찬가지로 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 애플리케이션의 재해에 대비하는 방법을 설명합니다. 컨텍스트 파일의 몇 가지 파라미터를 업데이트하면 시스템이 가동되어 실행됩니다. 모든 애플리케이션 시스템의 백업을 유지하고 백업에서 시스템을 복원할 필요가 없습니다. PROD와 DR 사이트 사이에 rsync 프로세스를 설정하고, PROD 사이트에 적용하는 동시에 DR 사이트에도 DB 및 AD 온라인 패칭 (ADOP) 패치를 적용하는 것이 좋습니다.
피드백 탭을 사용하여 의견을 남기거나 질문하세요.
데이터베이스 서비스에 대해 자세히 알아보세요.
우리는 Oracle 제품 전문가이므로 Rackspace가 귀하의 Oracle 투자를 극대화하는 데 도움을 드립니다.
Rackspace 재해 복구 솔루션에 대한 더 많은 정보를 원하시면 이 백서를 다운로드하세요.
