Oracle EBS ADOP(온라인 패칭) 주요 오류 유형과 해결 방법 총정리

이 글은 Tricore에서 2017년 8월 14일에 처음 게시한 내용을 바탕으로 재구성한 것입니다.

Oracle® E-Business Suite 환경에서 AD 온라인 패칭(ADOP, adop) 유틸리티를 사용하다 보면 다양한 오류에 직면하게 됩니다. 이 문서에서는 데이터베이스 관리자(DBA)들이 실무에서 자주 마주치는 대표적인 문제와 그 해결 방법을 정리했습니다.

데이터 딕셔너리 손상(Data Dictionary Corruption) 오류
adop prepare 단계 실패
Forms 객체 생성 실패
adop cutover 단계 중단(Hang)
패치 사이클 중단(Patch Abort)

1. 데이터 딕셔너리 손상 오류

데이터 딕셔너리 손상 오류는 주로 adop prepare 단계가 실패할 때 발생합니다.

오류 메시지

환경에 따라 오류 내용은 조금씩 다를 수 있으며, 대표적인 로그는 아래와 같습니다.

[EVENT]     Verifying data dictionary.
[UNEXPECTED]Data dictionary corrupted:
[UNEXPECTED]Data dictionary corruption - missing parent
5608975 ORA$BASE        IMAT            V_WORKFLOWWORKITEMII           VIEW
5608973 ORA$BASE        IMAT            V_WFSTAGETIME                  VIEW
5608973 ORA$BASE        IMAT            V_WFSTAGETIME                  VIEW
[UNEXPECTED]Data dictionary corruption detected. Provide details to
[UNEXPECTED]Oracle Support and ask for a bug to be opened against the
[UNEXPECTED]Online Patching component of Oracle Application Install.

/apps1/SID/fs_ne/EBSapps/log/adop/18/adop_xxxxx_xxxxx.log:

원인

이 문제는 개발자가 커스터마이징(Customization) 객체를 온라인 패칭 표준을 준수하지 않은 채 부적절하게 배포(promote)했을 때 발생합니다. 즉, EDITIONABLE/VIRTUAL COLUMN 등 온라인 패칭 규칙을 위반하는 방식으로 객체가 생성된 경우 논리적 데이터 딕셔너리 불일치가 생깁니다.

해결 방법

'missing parent' 형태의 데이터 딕셔너리 손상을 수정하려면 다음 순서대로 진행합니다.

손상 여부 확인: apps 사용자로 $AD_TOP/sql/ADZDDBCC.sql 스크립트를 실행하여 논리적 데이터 딕셔너리 손상 여부를 점검합니다. 스풀 로그(spool log)에서 손상된 객체 목록을 확인하세요.

손상 복구: sys 사용자로 $AD_TOP/patch/115/sql/adzddmpfix.sql 스크립트를 실행하여 손상을 복구합니다. 아래 예시에서는 12개의 손상 객체가 정상적으로 처리되었습니다.

 SQL> @adzddmpfix.sql

 "---- Fixing Data Dictionary Corruptions (missing parent) ----"
 12 rows deleted.
 Commit complete.
 System altered.
 "---- Compiling invalids ----"
 PL/SQL procedure successfully completed.
 Commit complete.

재점검: apps 사용자로 $AD_TOP/sql/ADZDDBCC.sql 스크립트를 다시 실행하여 손상이 남아 있는지 확인합니다.
a. 손상이 더 이상 발견되지 않으면 업그레이드 또는 adop 패치 사이클을 계속 진행합니다.
b. 여전히 손상이 감지되면 Oracle Support에 문의하여 버그 리포트를 등록해야 합니다.
재시도: 문제가 해결되면 adop prepare 단계를 다시 실행합니다.

2. adop prepare 단계 실패

간혹 adop prepare 단계가 예기치 않게 실패하는 경우가 있습니다. 여기서는 대표적인 prepare 오류 사례와 해결책을 소개합니다.

오류 메시지

아래 오류는 Oracle 버그에 해당하는 사례입니다.

Lines #(47-50):
runMSSrvPortsVal : oacore_server1:7252
ERROR: Run fs Context variable s_oacore_server_ports value cannot be NULL for oacore_server2
ERROR: Derived Patch managed server oacore_server2 port : NULL
ERROR: Failed to clone Run Context file to refresh Patch context file

해결 방법

다음 절차로 오류를 해결할 수 있습니다.

아래 명령어 샘플에서 대상 서버명과 SID를 오류 로그에 보고된 포트 및 경로 정보로 변경한 후 실행하여 문제를 수정합니다.

 perl $AD_TOP/patch/115/bin/adProvisionEBS.pl \
 ebs-delete-managedserver \
 -contextfile=/apps1/SID/fs1/inst/apps/SID_server/appl/admin/SID_server.xml -managedsrvname=oacore_server2 \
 -servicetype=oacore -logfile=$APPLRGF/TXK/delMS_oacore_server2.log

 perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl -contextfile=/apps1/SID/fs1/inst/apps/SID_server/appl/admin/SID_server.xml \
 -configoption=removeMS -oacore=server.cm.charter.com:7252

수정 작업이 완료되면 adop prepare를 다시 실행합니다.

3. Forms 객체 생성 실패

adop phase=apply patches=123456 형태로 패치를 적용하는 도중 Forms 객체(.fmx)가 정상적으로 생성되지 않는 경우가 있습니다. 이 경우 세션이 Patch continue prompt Y/N 확인 프롬프트 없이 종료됩니다.

오류 메시지

예를 들어 다음과 같은 Oracle Forms 객체가 생성에 실패했다고 가정합니다.

inv     forms/US        INVMWBIV.fmx

해결 방법

패치 디렉터리로 이동한 후 아래 명령으로 실패한 패치 세션을 재시작(restart)합니다.

cd /apps1/SID/fs_ne/EBSapps/patch
adop phase=apply patches=20609071 restart=yes flags=autoskip

flags=autoskip 옵션을 사용하면 생성에 실패한 객체를 건너뛰고 나머지 패치 작업을 계속 진행할 수 있습니다. 단, autoskip으로 건너뛴 객체는 이후 수동으로 재컴파일하고 검증해야 합니다.

4. adop cutover 중단(Hang)

cutover 단계가 멈추거나(hang), cutover 진행 중 서버에 크래시(crash)나 재부팅 문제가 발생한 경우에는 아래 절차로 복구한 뒤 패치 프로세스를 이어갈 수 있습니다.

해결 방법

PATCH 파일 시스템(fs2)에서 구동 중인 서비스나 프로세스가 없는지 먼저 확인합니다.
RUN 파일 시스템(fs1)에서 WebLogic Admin Server와 Node Manager가 정상 구동 중인지 확인합니다. 상태 점검은 아래 명령으로 수행합니다.
```
 $ adadminsrvctl.sh status
 $ adnodemgrctl.sh status
```

아래 명령을 순서대로 실행하여 현재 패치 사이클을 정리합니다.

 $ adop phase=abort
 $ adop phase=cleanup cleanup_mode=full
 $ adop phase=fs_clone force=yes

빈(empty) adop 사이클을 한 번 실행하여 cutover에 문제가 없는지 검증합니다.
```
 $adop phase=prepare, finalize, cutover, cleanup cleanup_mode=full
```
새로운 adop prepare를 시작하고 패치를 적용합니다.
apply 단계 완료 후 finalize, cutover, cleanup까지 나머지 adop 단계를 모두 마무리합니다.

5. 패치 사이클 중단(Patch Abort)

패치 사이클이 실패했는데 문제를 빠르게 해결하기 어렵다면, 해당 사이클을 중단(abort)하고 일반 운영 환경으로 되돌아갈 수 있습니다. 이 경우 패치 에디션(patch edition)은 삭제(drop)됩니다.

패치를 하나도 적용하지 않은 상태라면 아래 명령만으로 사이클을 포기할 수 있습니다.

$ adop phase=abort

중요: 이 명령은 cutover 단계가 성공적으로 완료되기 전에만 사용할 수 있습니다. cutover가 완료되면 시스템은 이미 새 에디션에서 구동 중이므로, 해당 패치 사이클에 대해 abort는 더 이상 불가능합니다.

패치 사이클을 중단하면 패치 에디션은 삭제되지만, 새로운 패치 사이클을 시작하기 전에 반드시 cleanup(full 모드)과 fs_clone 단계를 실행해야 합니다. 전체 흐름은 아래 예시와 같습니다.

$ adop phase=prepare
$ adop phase=apply patches=123456
[패치 적용 중 문제 발생 — 중단을 원할 경우]
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone

필요하다면 abort와 cleanup 명령을 하나로 합쳐 실행할 수도 있습니다.

$ adop phase=abort,cleanup cleanup_mode=full

참고: 핫패치(hotpatch) 모드(adop phase=apply apply_mode=hotpatch)로 적용한 패치는 중단(abort)할 수 없습니다.

맺음말

지금까지 살펴본 것처럼, adop 유틸리티의 알려진 오류들과 해결 방법을 미리 숙지해 두면 데이터베이스 관리자가 유사한 장애 상황에 직면했을 때 신속하게 대응할 수 있습니다. 특히 온라인 패칭 표준을 준수하는 개발 문화를 정착시키는 것이 데이터 딕셔너리 손상 같은 문제를 사전에 예방하는 가장 좋은 방법입니다.

내용에 대한 의견이나 질문이 있다면 피드백 탭을 통해 남겨 주세요.