이 글에서는 패치 파일 시스템의 WebLogic Server(WLS) 또는 Oracle® Fusion Middleware(FMW) 홈 디렉터리에 변경 사항이나 기술 패치를 적용한 후, fs_clone을 포함한 ADOP(Application DBA Online Patching Utility) 사이클을 실행해야 하는 이유를 살펴봅니다. 실제 문제 발생 시나리오를 통해 관련 이슈를 손쉽게 처리하는 방법까지 함께 안내합니다.
ADOP 사이클의 단계
다음 이미지는 ADOP 사이클의 각 단계를 보여줍니다.
이미지 출처: https://docs.oracle.com/cd/E26401_01/doc.122/e22954/T202991T531065.htm
문제 발생 배경
Oracle R12.2 인스턴스의 패치 파일 시스템에 Critical Patch Update(CPU) 패치를 적용한 뒤, ADOP가 전체 사이클(prepare, apply, finalize, cutover, cleanup)을 정상적으로 완료했습니다. 이후 다른 작업을 위해 한 번 더 ADOP 사이클을 실행했고, 해당 인스턴스는 다른 서버로 클론(clone)되었습니다.
그런데 새로 클론된 환경에 WLS 패치를 적용하는 과정에서 충돌이 발생했습니다. 패치 도구가 WLS 버전 불일치를 감지한 것입니다.
원인 분석
조사 결과, 이전에 WLS와 FMW Web Tier, Oracle common 홈 디렉터리에 적용했던 CPU 패치가 run 및 patch 파일 시스템에 포함되지 않은 것으로 확인되었습니다. ADOP 로그 파일을 추가로 분석한 결과, prepare 단계에서 파일 시스템 동기화는 수행되었지만, 패칭 사이클 중 Oracle_home과 FMW_home 디렉터리에 가해진 변경 사항은 반영되지 않았음을 알 수 있었습니다.
분석을 통한 결론
prepare 단계의 파일 동기화는 APPL_TOP에만 적용됩니다.
검토한 로그 파일에서도 run APPL_TOP에서 patch APPL_TOP으로 파일 시스템 변경 사항을 전파하는 내용만 확인되었습니다.
WebLogic 패치 적용 후 다음 ADOP 사이클을 시작하기 전에
fs_clone이 실행되지 않았습니다. 그 결과 두 번째 ADOP 사이클이 완료된 이후에도 새로운 패치가 run 파일 시스템에 나타나지 않았고, 클론된 인스턴트에도 반영되지 않았습니다.
권장 해결 방법
prepare 단계에서는 일반적으로 새로운 데이터베이스 에디션을 생성하여 패치 파일 시스템을 run 파일 시스템과 동기화합니다. 이는 애플리케이션 톱(application top)에서 변경된 파일들에 대한 기본적인 증분(incremental) 동기화 방식입니다.
적용된 패치를 동기화하려면 마지막 패칭 사이클 기준으로 run 파일 시스템의 $APPL_TOP에 대해 txkADOPPreparePhaseSynchronize.pl을 호출하거나, fs_clone을 실행하면 됩니다. 참고로 이 경우 실제 fs_clone 전체를 호출하는 것이 아니라, 동기화가 크게 어긋난 $APPL_TOP에 대해서는 FsCloneStage와 FsCloneApply만 호출하게 됩니다.
파일 시스템 동기화 방식은 Configuration Change Detector(adConfigChangeDetector.pl -detectConfigChanges)에 따라 자동으로 선택됩니다.
파일 동기화 방식은 다음 세 가지 옵션이 있습니다.
옵션 1 – 마지막 ADOP에서 데이터베이스에 적용된 패치를 식별한 후, 이를 병합(merge)하여 자동(silent)으로 재적용합니다. 적용되지 않은 패치만 처리하므로 소요 시간이 짧습니다.
옵션 2 – run 파일 시스템의 $APPL_TOP을 패치 파일 시스템의 $APPL_TOP으로 재생성(recreate) 또는 재클론(reclone)합니다. 동기화 상태가 매우 좋지 않은 경우에 사용하며, 리소스 소모가 큽니다.
옵션 3 – rsync 등 원하는 서드파티 소프트웨어를 사용해 파일 시스템을 동기화합니다.
prepare 단계에서 사용하는 파라미터
Prepare 단계에서는 다음 파라미터를 사용할 수 있습니다.
a) Skipsyncerror 옵션: 이전 패칭 사이클에서 패치 적용이 실패한 경우 발생할 수 있는 동기화 오류와 실패를 우회하기 위해, ADOP prepare 단계에서 오류와 경고를 무시하도록 설정합니다. 기본값은 NO입니다.
구문: adop phase=prepare skipsyncerror=yes
b) sync_mode 옵션: 패치 파일 시스템을 run 파일 시스템과 동기화하는 방식을 지정합니다.
구문: adop phase=prepare sync_mode=(delta|patch)
sync_mode patch – run 파일 시스템에 이미 적용된 패치를 다시 적용합니다(기본 모드).sync_mode delta – 모든 커스터마이징과 파일 변경 사항을 복사합니다. 이 모드는 delta_sync_drv.txt 파일의 동기화 명령을 사용하며, AD-TXK delta 8부터 도입된 신규 기능입니다.
ADOP fs_clone 명령어
fs_clone 명령은 패치 파일 시스템 전체를 재생성 또는 재클론하며, 모든 구성과 커스터마이징을 run 파일 시스템과 동일한 방식으로 패치 파일 시스템에 설정합니다. 이 작업은 run 파일 시스템을 전체 백업한 후 패치 파일 시스템을 새로 만드는 것만큼 리소스를 많이 소모합니다.
fs_clone에서 유용하게 사용할 수 있는 명령은 다음과 같습니다.
adop phase=fs_clone force=yes– 실패한 클론 작업을 처음부터 다시 시작합니다(기본값=NO).adop phase=fs_clone s_fs_backup_count=1– run 파일 시스템으로부터 패치 파일 시스템을 재생성하기 전에 보관할 백업 개수를 지정합니다(기본값=0, 백업 없음).
핵심 정리
prepare 단계는 모든 패칭 사이클의 시작 부분에서 실행되지만, opatch/Smart Update 유틸리티로 적용한 기술 스택(technology stack) 패치는 prepare 단계에서 동기화되지 않습니다.
또한 prepare 단계는 다음과 같은 수동 작업 내역도 동기화하지 않습니다.
- 사용자 정의 JSP 컴파일
- 서드파티 라이브러리 복사
- 사용자 정의 concurrent program 복사 및 컴파일
- 사용자 정의 forms 복사 및 생성
따라서 위와 같은 커스텀 패칭 작업은 prepare 단계의 커스텀 동기화 드라이버인 adop_sync.drv에 직접 추가해야 합니다.
adop_sync.drv 파일에는 다음 두 가지 유형의 명령이 존재합니다.
- 한 번만 실행되는 명령
- 파일 시스템 동기화 시마다 실행되는 명령
prepare 단계에서 커스터마이징과 파일 변경 사항을 복사하려면 다음 명령을 사용합니다.
ADOP phase=prepare sync_mode=(delta|patch)
패치 적용이 중단(aborted)되었거나, 유지보수(maintenance) 또는 Release Update Pack(RUP) 패치를 적용한 경우에는 마지막에 반드시 fs_clone을 실행하여 패치 파일 시스템을 run 파일 시스템과 완전히 동일한 상태로 재생성해야 합니다.
결론
E-Business Suite Release 12.2의 WebLogic Server 또는 Fusion Middleware 구성 요소에 변경 사항이 있을 때마다 데이터베이스 관리자는 반드시 fs_clone을 실행해야 합니다. 이를 통해 run 파일 시스템의 WLS나 FMW에 수행된 모든 최신 변경 사항이 패치 파일 시스템에도 올바르게 반영될 수 있습니다.
궁금한 점이나 의견이 있다면 피드백 탭을 활용해 주세요. 데이터베이스 서비스에 대한 자세한 내용도 확인해 보시기 바랍니다.