이 글에서는 Oracle® E-Business Suite®(EBS) R12.2.9 환경에서 재해 복구(Disaster Recovery, DR) 시스템을 유지 관리하고 패치를 적용하는 방법을 소개합니다. Oracle 12.2 애플리케이션 DR 시스템에 데이터베이스(DB) 패치와 애플리케이션(APPS) 패치를 적용하는 표준 절차를 단계별로 설명합니다.
소개
DR 애플리케이션 사이트를 구축하는 과정은 이전 블로그 포스트에서 다룬 클론(Clone) 시스템 생성 절차와 거의 동일합니다.
재해 상황이 발생하면 XML 파일의 호스트명 정보만 몇 가지 수정하면 백업 시스템을 즉시 가동할 수 있습니다. 다만 시스템을 항상 동기화 상태로 유지하려면 데이터베이스와 애플리케이션 서버 환경에 정기적으로 패치를 적용해야 합니다.
작업을 시작하기 전에 기본(Primary) 데이터베이스 서버와 함께 물리적 스탠바이(Physical Standby) 데이터베이스가 구성되어 있고 두 데이터베이스가 동기화되어 있는지 반드시 확인하세요. 이후 모든 패치를 DR 애플리케이션 시스템에 적용하게 됩니다.
전체 작업의 주요 단계는 다음과 같습니다:
- 아카이브 로그 전송을 중지하고 물리적 스탠바이 상태의 DR을 스냅샷 스탠바이(Snapshot Standby)로 전환합니다.
- 데이터베이스 패치를 적용하기 위해 DR 데이터베이스를 종료합니다.
- DR 데이터베이스를 스냅샷 스탠바이 모드로 기동한 후 노드 클린업 스크립트를 실행합니다.
- PROD 시스템과 파일 시스템이 일치하지 않는 경우 DR 애플리케이션의 파일 시스템을 전환(Flip)합니다.
- 시스템이 다운타임 모드일 때 패치를 적용합니다.
- 애플리케이션 DR 서버 패치 작업이 완료되면 DR을 다시 물리적 스탠바이로 전환합니다.
이 프로세스의 핵심은 간단한 시스템을 설계하여 애플리케이션 스위치오버(Switchover)에 대비하는 것입니다. 애플리케이션 측에서 재해가 발생하더라도 DR 시스템은 항상 기본 사이트와 동일한 패치 수준을 유지해야 합니다.
1단계: 물리적 스탠바이에서 스냅샷 스탠바이로 DR 전환
먼저 아카이브 로그 전송을 비활성화하고 기본 DR 데이터베이스를 스냅샷 스탠바이 모드로 전환합니다:
oracle사용자로 기본 운영(Production) 데이터베이스 node1에 로그인합니다.다음 명령을 실행합니다:
$. 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) 적용을 취소하고 스냅샷 스탠바이 모드로 전환합니다:
oracle사용자로 DR 데이터베이스 node1에 로그인합니다.다음 명령을 실행합니다:
$. 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 Application Cluster) 시스템의 모든 노드에 데이터베이스 패치를 적용합니다.
3단계: 데이터베이스를 스냅샷 모드로 전환
DR 데이터베이스를 스냅샷 스탠바이 모드로 전환한 후, 노드 클린업을 마치고 AutoConfig를 실행합니다:
$. 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 시스템을 패치 작업 준비 상태로 만듭니다. 운영 시스템에서 패치 주기가 완료되면 Cutover 이후 파일 시스템이 전환됩니다. 그 결과 운영(PROD)과 DR의 파일 시스템이 서로 달라질 수 있습니다. 다음 단계가 바로 이 문제를 해결합니다. DB 노드와 APPS 노드에서 실행하는 이 단계들은 DR 데이터베이스에 남아 있는 운영 환경 참조 정보를 제거합니다.
노드 클린업
노드를 정리하려면 다음 단계를 실행합니다:
oracle사용자로 DR 데이터베이스 node1에 로그인합니다.다음 명령을 실행합니다:
$. drinstance.env $ sqlplus apps/apps-passwd exec fnd_conc_clone.setup_clean; truncate table applsys.adop_valid_nodes;
모든 애플리케이션 및 데이터베이스 계층에서 AutoConfig 실행
데이터베이스 노드와 애플리케이션 노드에서 adautoconfig를 실행합니다.
DB 노드:
oracle사용자로 DR 데이터베이스 node1에 로그인하여 다음 명령을 실행합니다:$. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.shoracle사용자로 DR DB node2에 로그인하여 다음 명령을 실행합니다:$. drinstance.env $ cd $ORACLE_HOME/appsutil/scripts/<CONTEXT_NAME>/ $ sh adautocfg.sh
애플리케이션 노드 — RUN FS:
applmgr사용자로 DR 애플리케이션 node1에 로그인하여 다음 명령을 실행합니다:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgr사용자로 DR 애플리케이션 node2에 로그인하여 다음 명령을 실행합니다:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgr사용자로 DR 외부 애플리케이션 node1에 로그인하여 다음 명령을 실행합니다:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgr사용자로 DR 외부 애플리케이션 node2에 로그인하여 다음 명령을 실행합니다:$. drinstance.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.sh
애플리케이션 노드 — PATCH FS:
applmgr사용자로 DR 애플리케이션 node1에 로그인하여 다음 명령을 실행합니다:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgr사용자로 DR 애플리케이션 node2에 로그인하여 다음 명령을 실행합니다:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgr사용자로 DR 외부 애플리케이션 node1에 로그인하여 다음 명령을 실행합니다:$. drinstance_patch.env $ cd $ADMIN_SCRIPTS_HOME $ sh adautocfg.shapplmgr사용자로 DR 외부 애플리케이션 node2에 로그인하여 다음 명령을 실행합니다:$. 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>모든 노드에서 환경을 다시 소싱(Source)하여 파일 시스템이 정상적으로 전환되었는지 확인합니다.
이제 DR 시스템은 애플리케이션 패치 적용 준비가 완료되었습니다.
5단계: 다운타임 모드에서 DR 애플리케이션 노드에 패치 적용
DR에서는 애플리케이션 서비스를 중단 상태로 유지하므로, 다음 절차에 따라 다운타임(Downtime) 모드로 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(Fusion Middleware) 계층 패치를 표준 절차에 따라 모두 적용합니다.
RUN 파일 시스템과 PATCH 파일 시스템을 동기화하려면 아래 명령을 실행하여 RUN 파일 시스템에 적용된 변경 사항을 PATCH 파일 시스템으로 복제합니다:
$. drinstance.env
$ adop phase=fs_clone
6단계: 애플리케이션 DR 패치 완료 후 물리적 스탠바이로 복원
마지막으로 DR 데이터베이스를 다시 물리적 스탠바이 모드로 전환하고, DR 데이터베이스에 redo apply를 활성화한 후, 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;
다음으로 기본(Primary) 데이터베이스에서 아카이브 로그 전송을 활성화합니다:
1. 운영 데이터베이스 node1에 로그인합니다.
2. 다음 명령을 실행합니다:
$. 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 애플리케이션 시스템을 관리하는 방법을 살펴보았습니다. 이 방식을 사용하면 모든 애플리케이션 시스템의 백업을 별도로 유지하고 백업본에서 복원할 필요가 없습니다. 필요하다면 PROD 사이트와 DR 사이트 간에 rsync 프로세스를 설정하고, PROD 사이트에 데이터베이스 및 AD 온라인 패칭(ADOP) 패치를 적용할 때 DR 사이트에도 동시에 적용하는 방식을 활용할 수 있습니다.
데이터 서비스에 대해 더 자세히 알아보세요.
피드백 탭을 통해 의견을 남기거나 질문할 수 있으며, 언제든 저희와 대화를 시작할 수 있습니다.