Oracle ORA-04063 오류 원인과 해결 방법 완벽 가이드

ORA-04063
2026년 08월 23일 | DBMS Error 가이드

이 글에서 다루는 내용

ORA-04063 에러의 원인 분석, 해결 SQL, 예방 방법을 실무 관점에서 정리합니다.

ORA-04063 has errors 는?

ORA-04063 에러는 Oracle 데이터베이스에서 뷰(View), 저장 프로시저(Stored Procedure), 함수(Function), 패키지(Package), 트리거(Trigger) 등의 객체에 컴파일 오류가 존재할 때 발생하는 에러입니다. 즉, 해당 객체가 “INVALID” 상태에 놓여 있어 정상적으로 실행되지 못하는 상황을 의미합니다. 주로 참조하는 테이블이나 컬럼이 변경되거나 삭제된 경우, 또는 의존 객체가 재컴파일에 실패한 경우에 빈번히 발생합니다.

주요 발생 원인

참조 객체(테이블, 뷰, 함수 등)의 변경 또는 삭제

가장 흔한 원인으로, 프로시저나 함수가 참조하는 테이블의 컬럼이 삭제되거나 데이터 타입이 변경된 경우입니다. Oracle은 의존성을 자동으로 추적하며, 참조 객체가 변경되면 해당 객체를 INVALID 상태로 표시합니다. 예를 들어, EMP 테이블의 SALARY 컬럼을 삭제했는데 해당 컬럼을 참조하는 프로시저가 존재한다면, 그 프로시저는 즉시 INVALID 상태가 됩니다.

패키지 스펙(Spec)과 바디(Body) 간의 불일치

패키지 스펙에 선언된 함수나 프로시저의 시그니처(매개변수 이름, 타입, 개수)가 패키지 바디의 구현과 일치하지 않을 때 발생합니다. 스펙만 수정하고 바디를 업데이트하지 않거나, 반대로 바디를 먼저 배포하는 경우에도 이 문제가 발생합니다. 이 경우 패키지 전체가 INVALID 상태가 되어 패키지 내 모든 함수/프로시저 호출이 실패합니다.

권한 변경 또는 누락

객체가 참조하는 다른 스키마의 테이블이나 뷰에 대한 접근 권한이 회수(REVOKE)되었을 때 발생합니다. DBA가 특정 권한을 정리하는 과정에서 의도치 않게 의존성이 깨지는 경우가 실무에서 자주 발생합니다. 특히 롤(Role)을 통해 부여된 권한은 PL/SQL 객체에서 직접 참조할 수 없기 때문에, 롤 기반 권한만으로 객체를 생성하면 이 에러가 빈번하게 나타납니다.

해결 방법

Step 1: INVALID 상태의 객체 확인

먼저 데이터베이스 내에서 INVALID 상태의 객체 목록을 조회합니다.

-- INVALID 상태의 모든 객체 조회
SELECT owner, object_name, object_type, status, last_ddl_time
FROM   dba_objects
WHERE  status = 'INVALID'
ORDER BY owner, object_type, object_name;

-- 현재 스키마의 INVALID 객체만 조회
SELECT object_name, object_type, status
FROM   user_objects
WHERE  status = 'INVALID'
ORDER BY object_type, object_name;

Step 2: 컴파일 에러 상세 내용 확인

-- 특정 객체의 컴파일 에러 상세 확인
SELECT line, position, text
FROM   user_errors
WHERE  name = 'YOUR_PROCEDURE_NAME'  -- 객체명 대문자로 입력
  AND  type = 'PROCEDURE'             -- PROCEDURE, FUNCTION, PACKAGE, TRIGGER, VIEW
ORDER BY sequence;

-- 또는 ALL_ERRORS 뷰를 통해 다른 스키마 객체 확인
SELECT owner, name, type, line, position, text
FROM   all_errors
WHERE  name = 'YOUR_OBJECT_NAME'
ORDER BY sequence;

Step 3: 원인별 해결

① 객체 재컴파일 (단일 객체)

-- 프로시저 재컴파일
ALTER PROCEDURE schema_name.procedure_name COMPILE;

-- 함수 재컴파일
ALTER FUNCTION schema_name.function_name COMPILE;

-- 패키지 스펙과 바디 재컴파일
ALTER PACKAGE schema_name.package_name COMPILE SPECIFICATION;
ALTER PACKAGE schema_name.package_name COMPILE BODY;
ALTER PACKAGE schema_name.package_name COMPILE;  -- 스펙+바디 동시 컴파일

-- 트리거 재컴파일
ALTER TRIGGER schema_name.trigger_name COMPILE;

-- 뷰 재컴파일
ALTER VIEW schema_name.view_name COMPILE;

② 스키마 전체 INVALID 객체 일괄 재컴파일 (UTL_RECOMP 사용)

-- 단일 스키마 재컴파일 (권장: 운영 시간 외 실행)
EXEC UTL_RECOMP.recomp_serial('SCOTT');

-- 병렬 재컴파일 (CPU 코어 수에 맞게 조정)
EXEC UTL_RECOMP.recomp_parallel(4, 'SCOTT');

-- 전체 데이터베이스 재컴파일
EXEC UTL_RECOMP.recomp_serial();

③ 의존성 체인 확인 후 순서대로 재컴파일

-- 특정 객체에 의존하는 객체 목록 조회
SELECT name, type, referenced_name, referenced_type
FROM   user_dependencies
WHERE  referenced_name = 'EMP'  -- 변경된 기본 객체명
ORDER BY type, name;

-- 의존성 역방향 추적 (어떤 객체를 참조하는지 확인)
SELECT d.name       AS dependent_object,
       d.type       AS dependent_type,
       d.referenced_name AS referenced_object,
       d.referenced_type AS referenced_type
FROM   dba_dependencies d
WHERE  d.referenced_owner = 'HR'
  AND  d.referenced_name  = 'EMPLOYEES'
ORDER BY d.type, d.name;

④ 권한 누락 해결

-- 누락된 권한 부여 (롤이 아닌 직접 권한 부여)
GRANT SELECT ON hr.employees TO scott;
GRANT EXECUTE ON hr.get_salary TO scott;

-- 권한 부여 후 객체 재컴파일
ALTER PROCEDURE scott.calc_bonus COMPILE;

⑤ DBMS_UTILITY를 이용한 빠른 재컴파일

-- 스키마 내 모든 객체 재컴파일
EXEC DBMS_UTILITY.compile_schema(schema => 'SCOTT', compile_all => FALSE);
-- compile_all => FALSE: INVALID 객체만 재컴파일
-- compile_all => TRUE : 모든 객체 재컴파일

예방 방법

DDL 변경 전 의존성 사전 점검 및 변경 관리 프로세스 수립

테이블의 컬럼을 변경하거나 삭제하기 전에 반드시 의존성 분석을 먼저 수행하는 절차를 팀 내 표준으로 정의해야 합니다. 아래 스크립트를 사전 점검 도구로 활용하면 운영 중 장애를 크게 줄일 수 있습니다.

“`sql

— DDL 변경 전 의존 객체 사전 확인 스크립트

SELECT o.object_name AS dependent_object,

o.object_type AS object_type,

o.status AS current_status

FROM dba_dependencies d

JOIN dba_objects o

ON o.owner = d.owner

AND o.object_name = d.name

AND o.object_type = d.type

WHERE d.referenced_owner = UPPER(‘&schema_name’)

AND d.referenced_name = UPPER(‘&object_name’)

ORDER BY o.object_type, o.object_name;

“`

배포 후 자동 재컴파일 스크립트를 CI/CD 파이프라인에 통합

애플리케이션 배포 후 자동으로 INVALID 객체를 재컴파일하고, 재컴파일 후에도 INVALID 상태가 남아있으면 배포 파이프라인이 실패하도록 구성해야 합니다. 이를 통해 운영 환경에서 INVALID 객체가 잔존하는 상황을 원천 차단할 수 있습니다.

“`sql

— 배포 후 검증 쿼리 (INVALID 객체가 0건이어야 정상)

SELECT COUNT(*)

FROM dba_objects

WHERE owner = ‘YOUR_SCHEMA’

AND status = ‘INVALID’;

“`