ORA-04063 has errors — PL/SQL 객체 컴파일 오류 에러 원인·해결·예방 완전 정리
PL/SQL 코드를 운영하다 보면 어느 순간 ORA-04063: package body "OWNER.NAME" has errors가 떨어지면서 모든 호출이 막히는 상황이 생긴다. 컴파일 시점에는 경고만 나오던 객체가 실행 시점에야 에러를 토하는 것이 이 에러의 특징으로, 보통 ORA-06508·ORA-06512와 함께 묶여 나타난다.
본 글은 ORA-04063의 의미, 6가지 발생 원인, 진단 SQL, 단건/일괄 재컴파일 방법, 그리고 운영 환경에서 INVALID 객체를 사전에 막는 예방 전략까지 정리한다.
이 글의 구성
01 에러 메시지와 ORA-04063의 의미
| 항목 | 내용 |
|---|---|
| 에러 코드 | ORA-04063 |
| 메시지 형식 | <object_type> "<owner>.<name>" has errors |
| 의미 | 호출된 PL/SQL 객체가 INVALID 상태(컴파일 에러 보유) |
| 발생 시점 | 컴파일이 아니라 실행(런타임) 시점 |
| 대상 객체 | 패키지·프로시저·함수·트리거·뷰·타입 |
| 동반 에러 | ORA-06508 · ORA-06512 (호출 위치 표시) |
ORA-04063은 객체 자체에 컴파일 에러가 있다는 사실만 알려 줄 뿐, 그 컴파일 에러가 무엇인지는 보여 주지 않는다. 실제 원인은 USER_ERRORS / DBA_ERRORS 뷰에 따로 저장되어 있어 진단의 첫 단계는 이 뷰의 line·position·text를 읽는 일이다.
핵심 관찰 — 컴파일은 통과하고 호출이 막힌다
CREATE OR REPLACE 시 SQL*Plus는 "Warning: created with compilation errors" 메시지만 띄우고 객체를 만들어 둔다. 객체는 데이터 사전에 등록되지만 STATUS는 INVALID다. 누군가 이 객체를 실행하는 순간에만 ORA-04063이 표면화되기 때문에, 배포 직후엔 멀쩡해 보이다가 사용자 호출 한 건에 장애로 번지는 패턴이 흔하다.
02 발생 원인 6가지
원인 1 — 의존 객체 변경에 따른 cascade invalidation
EMP 테이블에서 컬럼을 DROP하거나 자료형을 ALTER하면, 그 컬럼·테이블을 참조하던 패키지·뷰·트리거가 일제히 INVALID로 전환된다. 운영 중인 DDL 한 줄이 수십 개 객체를 동시 무효화시키는 가장 흔한 경로다.
원인 2 — 소스 코드 자체 컴파일 오류
변수명 오타, 세미콜론 누락, 시그니처 불일치 같은 직접 컴파일 오류가 남아 있는 상태로 배포됐을 때 발생한다. DBA_ERRORS의 text 컬럼에 line·position과 함께 정확한 PL/SQL 진단이 들어 있다.
원인 3 — 권한 누락(특히 definer-rights 패키지)
참조하는 다른 스키마 객체에 EXECUTE·SELECT 권한이 회수됐을 때 INVALID가 된다. 정의자 권한 패키지에서는 role 기반 권한이 적용되지 않으므로 직접 GRANT가 필수다(`GRANT EXECUTE ON sys.dbms_lock TO scott`).
원인 4 — 참조 객체 부재
참조하던 테이블·시퀀스·타입·시노님이 DROP된 뒤 재생성되지 않은 경우다. 뷰는 정의 쿼리가 깨졌을 때, 트리거는 :NEW·:OLD 컬럼이 사라졌을 때 같은 양상으로 ORA-04063이 발생한다.
원인 5 — 패키지 명세-본문 불일치
패키지 spec의 시그니처를 바꾸고 body를 재컴파일하지 않은 상태, 혹은 spec에 새로 추가한 함수가 body에 구현되지 않은 상태에서 발생한다. spec 수정 후에는 반드시 ALTER PACKAGE ... COMPILE BODY로 본문도 함께 컴파일해야 한다.
원인 6 — DB 업그레이드 후 SYS 객체 INVALID
11g→19c, 12c→19c 업그레이드 직후 DBMS_STATS·DBMS_DATAPUMP 같은 시스템 패키지가 INVALID로 남는 경우다. expdp 등 유틸리티가 ORA-04063과 ORA-06508을 함께 던진다. 표준 절차는 utlrp.sql 재실행으로 일괄 해소(MOS Doc ID 2735200.1).
03 진단 SQL과 의존성 추적
INVALID 객체 전수 조사
SELECT owner, object_name, object_type, status, last_ddl_time
FROM dba_objects
WHERE status = 'INVALID'
ORDER BY owner, object_type;
실제 컴파일 에러 메시지 확인
SELECT line, position, text
FROM user_errors
WHERE name = 'MY_PKG'
AND type = 'PACKAGE BODY'
ORDER BY sequence;
SQL*Plus 세션에서는 SHOW ERRORS PACKAGE BODY my_pkg 한 줄로 즉시 결과를 얻을 수 있다. 가장 빠른 디버깅 진입점이다.
의존성 트리 추적
-- EMP 테이블을 참조하는 모든 객체
SELECT owner, name, type
FROM dba_dependencies
WHERE referenced_name = 'EMP'
AND referenced_owner = 'SCOTT';
-- 변경 영향 사전 분석(utldtree.sql 설치 후)
EXEC deptree_fill('TABLE', 'SCOTT', 'EMP');
SELECT * FROM ideptree;
deptree_fill 프로시저는 ?/rdbms/admin/utldtree.sql을 한 번 실행해 둔 스키마에서 사용 가능하다. 운영 DDL 전에 영향 객체 목록을 미리 확보할 때 유용하다.
04 단건·일괄 재컴파일 방법
단건 재컴파일
ALTER PACKAGE scott.my_pkg COMPILE BODY;
ALTER PROCEDURE hr.calc_bonus COMPILE;
ALTER FUNCTION hr.tax_rate COMPILE;
ALTER TRIGGER scott.trg_audit COMPILE;
ALTER VIEW hr.v_emp_summary COMPILE;
-- spec과 body를 한 번에 컴파일(둘 다 재컴파일됨)
ALTER PACKAGE scott.my_pkg COMPILE PACKAGE;
-- body만 따로 컴파일
ALTER PACKAGE scott.my_pkg COMPILE BODY;
일괄 재컴파일
-- 스키마 단위 직렬 재컴파일
EXEC UTL_RECOMP.RECOMP_SERIAL('SCOTT');
-- 병렬 재컴파일(CPU·세션 여유 시)
EXEC UTL_RECOMP.RECOMP_PARALLEL(4, 'SCOTT');
-- DB 전체 표준 절차(SYSDBA로 실행)
@?/rdbms/admin/utlrp.sql
utlrp.sql은 내부적으로 UTL_RECOMP을 호출해 모든 INVALID 객체를 의존 순서에 따라 재컴파일한다. DB 업그레이드 직후, 대규모 패치 배포 직후, 운영 중 ORA-04063 폭증 시 가장 안전한 표준 절차다.
자동 재컴파일을 너무 신뢰하지 말 것
Oracle은 INVALID 객체를 호출 시점에 자동으로 재컴파일한다(deferred compilation). 그러나 진짜 컴파일 오류가 있는 객체는 자동 재컴파일도 실패하므로 ORA-04063이 그대로 떨어진다. 자동 재컴파일에 의존하면 사용자 트래픽이 첫 호출 비용을 떠안는 부작용도 있다. 운영 환경에서는 배포 직후 명시적 재컴파일이 안전하다.
05 예방 전략과 배포 절차
| 영역 | 권장 조치 |
|---|---|
| 배포 스크립트 | DDL 적용 후 utlrp.sql 자동 호출, dba_errors 0건 검증 후 다음 단계 |
| CI 파이프라인 | PL/SQL 빌드 단계에서 SHOW ERRORS 출력 캡처, 컴파일 경고 시 빌드 실패 |
| 의존성 관리 | 운영 DDL 전에 dba_dependencies로 영향 범위 확인 |
| 패키지 변경 | spec과 body를 단일 트랜잭션 스크립트로 묶어 배포 |
| 권한 관리 | definer-rights 패키지는 role이 아닌 직접 GRANT만 인정 |
| 업그레이드 후처리 | STARTUP RESTRICT 상태에서 utlrp.sql 실행 후 일반 모드 복귀 |
ORA-04063은 코드 결함이라기보다 배포 절차의 결함으로 봐야 하는 경우가 많다. DDL을 적용하고 의존 객체를 재컴파일하지 않은 채 배포를 끝내는 습관이 가장 큰 위험원이다.
대규모 시스템에서 invalidation 자체를 피하고 싶다면 Edition-Based Redefinition(EBR) 도입을 검토한다. 동일 객체의 이전·신규 버전을 동시에 유지하면서 무중단 전환이 가능하다.
06 인접 에러 ORA-06508·ORA-06512와의 차이
| 에러 코드 | 의미 | 조치 방향 |
|---|---|---|
| ORA-04063 | 객체 자체 INVALID 상태 | DBA_ERRORS 확인 후 재컴파일 |
| ORA-06508 | 세션의 패키지 상태가 재컴파일로 무효화됨 | 세션 재접속 또는 패키지 상태 변수 점검 |
| ORA-06512 | 예외 발생 위치(스택 트레이스) | at line N의 라인 번호로 원인 추적 |
| ORA-04068 | existing state of packages has been discarded | 06508과 유사, 세션 재시작 |
| ORA-06550 | PL/SQL 컴파일 시점 오류(런타임 아님) | 소스 수정 후 재컴파일 |
ORA-04063이 객체의 영속 상태(INVALID)를 가리킨다면, ORA-06508은 세션이 가진 패키지 인스턴스 상태가 깨졌음을 뜻한다. 동일 객체가 다른 세션에서는 멀쩡할 수 있다는 점이 결정적인 차이다. ORA-06512는 별도 에러가 아니라 모든 PL/SQL 예외에 따라붙는 위치 정보이고, ORA-06550은 런타임이 아닌 컴파일 시점 오류라는 점에서 ORA-04063과 보완 관계다.
07 자주 묻는 질문
Q1. ORA-04063만 떨어지면 어디부터 봐야 하나요?
USER_ERRORS 또는 DBA_ERRORS의 text 컬럼이 1순위다. 메시지에 표시된 객체(owner.name)와 type으로 필터링해 line·position 값을 확인하면 그 줄에 진짜 컴파일 에러가 적혀 있다. SQL*Plus라면 `SHOW ERRORS PACKAGE BODY my_pkg` 한 줄로 같은 정보를 얻는다.
Q2. utlrp.sql은 운영 시간에 돌려도 되나요?
기술적으로 가능하나 일부 객체에 잠시 락이 걸리므로 한가한 시간대를 권장한다. 핫픽스 상황이라면 RECOMP_SERIAL을 특정 스키마·객체 단위로 좁혀 호출하는 편이 안전하다.
Q3. 자동 재컴파일에 맡겨도 되지 않나요?
자동 재컴파일은 정상 객체에는 유효하지만, 실제 컴파일 오류가 있는 객체는 자동으로 고쳐 주지 못한다. 또한 사용자 트래픽이 첫 호출의 컴파일 비용을 떠안게 되므로 응답 지연이 발생한다. 운영 절차에서는 배포 직후 명시적 재컴파일이 정석이다.
Q4. 패키지 spec만 바꿔도 본문이 INVALID로 되나요?
예. spec 변경은 항상 body를 무효화한다. body가 spec과 일치하더라도 명시적 컴파일이 일어나기 전까지는 INVALID로 표시된다. spec 변경 후에는 반드시 ALTER PACKAGE ... COMPILE BODY를 함께 실행한다.
Q5. Edition-Based Redefinition을 꼭 써야 하나요?
필수는 아니다. EBR은 무중단 배포가 비즈니스 요구일 때 진가를 발휘한다. 일반적인 야간 배포 환경에서는 utlrp.sql 표준 절차만 잘 지켜도 ORA-04063은 안정적으로 통제된다.
마무리
ORA-04063은 메시지만 보면 막연하지만 본질은 명확하다. 호출 시점에 객체가 INVALID 상태였다는 사실 하나다. 진단의 첫 단계는 객체명을 그대로 DBA_ERRORS에 던지는 것이고, 두 번째 단계는 의존성 영향 범위를 파악해 단건 또는 일괄 재컴파일을 선택하는 일이다.
운영 안정성을 위해서는 (1) 배포 스크립트 마지막에 utlrp.sql 또는 명시적 ALTER COMPILE 호출, (2) CI에서 dba_errors 0건 검증, (3) 운영 DDL 전 의존성 사전 확인, 세 단계만 일관되게 지켜도 ORA-04063이 사용자 트래픽으로 흘러가는 일은 거의 없다.
ORA-04063 트러블슈팅 체크리스트
본 글은 Oracle Database PL/SQL 객체 컴파일 오류 ORA-04063의 일반적 원인과 해결 방법을 정리한 자료다. 운영 환경 적용 전 테스트 환경에서 충분히 검증한다.
#ORA04063 #hasErrors #오라클에러 #PLSQL컴파일오류 #INVALID객체 #UTL_RECOMP #utlrpsql #DBA_ERRORS #DBA_DEPENDENCIES #DBMS_UTILITY #PackageBody #DefinerRights #ORA06508 #ORA06512 #ORA06550
댓글