이 게시물은 Oracle® E-business Suite®(EBS) R12.2.9용 재해 복구(DR) 시스템의 유지 관리 및 패치에 대해 다룹니다. Oracle 버전 12.2 애플리케이션 DR 시스템에 데이터베이스 DB 및 애플리케이션(APPS) 패치를 적용하는 일반적인 프로세스에 대해 설명합니다.
소개
DR 응용 사이트를 만드는 단계는 이전 블로그 게시물에서 다루었던 aclone 시스템을 만드는 단계와 거의 동일합니다.
재난 발생 시 호스트 이름에 대한 XML 파일을 약간만 변경하면 백업 시스템이 준비되어 실행됩니다. 시스템을 비동기적으로 유지하려면 데이터베이스 및 애플리케이션 서버 환경에 정기적으로 패치를 적용해야 합니다.
기본 데이터베이스 서버와 두 데이터베이스가 동기화된 물리적 대기 데이터베이스를 구성했는지 확인합니다. 그런 다음 모든 패치를 DR 응용 프로그램 시스템에 적용해야 합니다.
이 프로세스의 개략적인 단계는 다음과 같습니다.
- 보관을 비활성화하고 DR을 물리적 대기 상태에서 스냅샷 대기 상태로 변환합니다.
- DR 데이터베이스를 종료하여 데이터베이스 패치를 적용합니다.
- 대기 스냅샷 모드에서 DR 데이터베이스를 시작하고 노드 정리 스크립트를 실행합니다.
- PRODsystem과 일치하지 않는 경우 DR 응용 프로그램의 파일 시스템을 뒤집습니다.
- 시스템이 다운타임 모드일 때 패치를 적용합니다.
- 응용 프로그램 DR 서버 패치를 완료한 후 DR을 다시 물리적 대기 상태로 변환합니다.
이 프로세스에는 간단한 시스템을 설계하고 응용 프로그램 전환을 위해 배치하는 작업이 포함됩니다. 애플리케이션 측에서 재해가 발생하는 경우 이 시스템은 모든 패치 수준에서 기본 사이트와 동기화된 상태를 유지해야 합니다.
1. DR을 물리적 대기에서 스냅샷 대기로 변환
먼저 아카이브 로그 전달을 비활성화하고 기본 DR 데이터베이스를 대기 스냅샷 모드로 변환합니다.
-
기본 프로덕션 데이터베이스 node1에
oracle로 로그온합니다. . -
다음 명령을 실행하십시오.
$. 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
그런 다음 DR 데이터베이스에서 redo-log 응용 프로그램을 취소하고 스냅샷 대기 모드로 전환합니다.
-
DR 데이터베이스 node1에
oracle로 로그온합니다. . -
다음 명령을 실행하십시오.
$. 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. 데이터베이스 패치를 적용하기 위해 DR 데이터베이스 종료
두 노드에서 데이터베이스를 종료하고 데이터베이스 패치를 적용합니다. 다음 명령을 실행하여 데이터베이스 패치를 적용하십시오.
$. prodinstance.env
$ sqlplus / as sysdba
shut immediate;
$ cd $PATCH_DIR
$ opatch apply
이전 단계를 사용하여 모든 RAC(Real ApplicationCluster) 시스템 노드에 데이터베이스 패치를 적용합니다.
3. 데이터베이스를 스냅샷 모드로 변환
DR 데이터베이스를 스냅샷 대기 모드로 변환하고 노드 정리 후 auto-config를 실행합니다.
$. 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
이제 패치를 적용할 애플리케이션 DR 시스템을 준비합니다. 프로덕션 시스템에서 패치 주기가 완료된 후 파일 시스템은 컷오버 후 전환됩니다. 결과적으로 프로덕션 및 DR 파일 시스템이 동일하게 유지되지 않을 수 있습니다. 다음 단계는 이 문제를 해결합니다. DB 및APPS 노드에서 실행하는 이러한 단계는 DR 데이터베이스에서 모든 프로덕션 참조를 제거합니다.
노드 정리
다음 단계를 실행하여 노드 정리를 준비하십시오.
-
DR 데이터베이스 node1에
oracle로 로그온합니다. . -
다음 명령을 실행하십시오.
$. drinstance.env $ sqlplus apps/apps-passwd exec fnd_conc_clone.setup_clean; truncate table applsys.adop_valid_nodes;
모든 애플리케이션 및 데이터베이스 계층에서 Autoconfig 실행
adautoconfig 실행 데이터베이스 및 애플리케이션 노드에서.
DB 노드:
-
DR 데이터베이스 node1에
oracle로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.sh -
DR DB node2에
oracle로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.sh
애플리케이션 노드 - FS 실행:
-
DR 애플리케이션 node1에
applmgr로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR 애플리케이션 node2에
applmgr로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR 외부 애플리케이션 node1에
applmgr로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR 외부 애플리케이션 node2에
applmgr로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
애플리케이션 노드 - 패치 FS
-
DR 애플리케이션 node1에
applmgr로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR 애플리케이션 node2에
applmgr로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR 외부 애플리케이션 node1에
applmgr로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh -
DR 외부 애플리케이션 node2에
applmgr로 로그온합니다. 다음 명령을 실행하십시오:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
4. PROD 시스템과 일치하지 않는 경우 DR 앱의 파일 시스템을 뒤집습니다.
PROD 및 DR 서버의 RUN 및 PATCH 파일 시스템 간에 차이가 있는 경우에만 다음 단계를 실행해야 합니다. 동일하면 바로 패치 적용을 진행하시면 됩니다.
모든 DR APPS 계층 노드에서 다음 단계를 실행합니다.
-
모든 DR 응용 프로그램 노드(외부 및 내부)에 로그온하고 다음 명령을 실행합니다.
$. ./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> -
모든 노드에서 환경을 다시 소싱하여 파일 시스템이 전환되었는지 확인하십시오.
이제 DR이 애플리케이션 패치를 적용할 준비가 되었습니다.
5. 다운타임 모드에서 DR 애플리케이션 노드에 애플리케이션 패치 적용
첫째, DR에서 애플리케이션 서비스를 중단하기 때문에 다음 단계를 수행하여 가동 중지 모드에서 RUN 파일 시스템에 패치를 적용합니다.
-
DR 응용 프로그램 node1에 로그온합니다.
-
다음 명령을 실행하십시오.
$. drinstance.env $ adop phase=apply patches=<patch1, patch2> patchtop=/apps_stage/patch \ apply_mode=downtime options=nodbportion
다음과 같은 경고 메시지가 나타날 수 있습니다. 그렇다면 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
그런 다음 표준 절차를 사용하여 모든 FMW Tier 패치를 적용합니다.
실행 및 패치 파일 시스템을 동기화하려면 다음 명령을 실행하여 실행 파일 시스템에 대한 변경 사항이 패치 파일 시스템에 복제되도록 합니다.
$. drinstance.env$adop 단계=fs_clone
6. 애플리케이션 DR 패치가 완료된 후 DR을 다시 물리적 대기로 변환
마지막으로 DR 데이터베이스를 다시 물리적 대기 모드로 변환하고 redo apply을 활성화해야 합니다. DR 데이터베이스로 이동하고 PROD에서 DR 데이터베이스로 아카이브 로그 전달을 재개합니다.
먼저 DR 데이터베이스를 다시 물리적 대기 상태로 변환합니다.
-
DR 데이터베이스 node1에 로그온하고 다음 명령을 실행합니다.
$. 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; -
DR 데이터베이스 node2에 로그온하고 다음 명령을 실행하여 인스턴스를 시작합니다.
$. drinstance.env $ sqlplus / as sysdba; startup;
다음으로 다음 명령을 실행하여 기본 데이터베이스에서 아카이브 로그 전달을 활성화합니다.
1. Log onto the production database node1.
2. Run the following commands:
$. 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='*';
결론
이 게시물은 PROD EBS 12.2 사이트에 적용된 업데이트 및 패치로 재해 EBS 애플리케이션 시스템을 관리하는 방법에 대해 설명합니다. 모든 응용 프로그램 시스템의 백업을 유지한 다음 백업에서 시스템을 복원할 필요가 없습니다. rsync를 설정하고 싶을 수도 있습니다. PROD 사이트와 DR 사이트 간의 프로세스를 처리하고 데이터베이스 및 ADOP(AD Online Patching) 패치를 PROD 사이트에 적용할 때 DR 사이트에 적용합니다.
데이터 서비스에 대해 자세히 알아보세요.
피드백 탭을 사용하여 의견을 작성하거나 질문하십시오. 저희와 대화를 시작할 수도 있습니다.