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

ORA-04064 not executed, invalidated 는?

ORA-04064 에러는 Oracle에서 저장 프로시저(Stored Procedure), 함수(Function), 패키지(Package), 트리거(Trigger) 등의 PL/SQL 객체가 무효화(Invalidated) 상태가 되어 실행이 불가능할 때 발생하는 에러입니다. 이 에러는 주로 해당 PL/SQL 객체가 참조하는 테이블, 뷰, 시퀀스, 또는 다른 프로시저/함수 등이 변경되거나 삭제되었을 때 Oracle이 자동으로 객체를 INVALID 상태로 표시하면서 발생합니다. 실무 환경에서는 DDL 작업 후 또는 배포 작업 중에 빈번하게 나타나며, 제때 처리하지 않으면 애플리케이션 전체에 영향을 줄 수 있는 심각한 에러입니다.

---

주요 발생 원인

1. 의존 객체(Dependent Object)의 DDL 변경

가장 빈번한 원인으로, 프로시저나 함수가 참조하는 테이블에 컬럼 추가/삭제/타입 변경 등의 DDL 작업이 수행되면 Oracle은 해당 PL/SQL 객체를 자동으로 INVALID 상태로 변경합니다. 예를 들어 ALTER TABLE, DROP TABLE, CREATE OR REPLACE VIEW 등의 작업 이후에 관련 PL/SQL 객체들이 일괄적으로 INVALID 처리되는 경우가 많습니다. 특히 대규모 배포나 마이그레이션 작업 후에는 수십, 수백 개의 객체가 한꺼번에 INVALID 상태가 될 수 있으므로 주의가 필요합니다.

2. 참조 객체의 삭제 또는 재생성

프로시저 내부에서 호출하는 다른 프로시저, 함수, 패키지가 DROP 되거나 CREATE OR REPLACE로 재생성될 경우, 이를 참조하는 상위 객체들도 연쇄적으로 INVALID 상태가 됩니다. 이 현상은 패키지(Package)의 경우 특히 두드러지는데, 패키지 스펙(Spec)이 변경되면 해당 패키지 바디(Body)뿐만 아니라 그 패키지를 사용하는 모든 PL/SQL 객체가 무효화됩니다. 복잡한 의존 관계를 가진 시스템에서는 단 하나의 객체 변경이 수십 개의 연쇄 무효화를 일으킬 수 있습니다.

3. 권한(Privilege) 변경 또는 시노님(Synonym) 문제

객체에 부여된 실행 권한(EXECUTE GRANT)이 회수(REVOKE)되거나, 참조하는 시노님(Synonym)이 삭제 또는 변경된 경우에도 ORA-04064 에러가 발생할 수 있습니다. 특히 다른 스키마의 객체를 참조할 때 DBA가 권한을 변경하는 경우 해당 객체가 즉시 INVALID 상태로 전환됩니다. 권한 기반 무효화는 눈에 잘 띄지 않아 원인 파악에 시간이 걸리는 경우가 많습니다.

---

해결 방법

STEP 1: INVALID 객체 현황 파악

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

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

-- 특정 객체의 의존성 확인
SELECT name,
       type,
       referenced_name,
       referenced_type,
       referenced_owner
FROM   user_dependencies
WHERE  referenced_name = 'YOUR_TABLE_OR_OBJECT_NAME';

STEP 2: 개별 객체 재컴파일

특정 객체를 수동으로 재컴파일하여 VALID 상태로 전환합니다.

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

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

-- 패키지 스펙 및 바디 재컴파일
ALTER PACKAGE package_name COMPILE SPECIFICATION;
ALTER PACKAGE package_name COMPILE BODY;

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

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

STEP 3: UTL_RECOMP 패키지를 활용한 일괄 재컴파일

대량의 INVALID 객체가 있을 경우 Oracle 제공 패키지를 사용합니다.

-- 단일 스키마의 모든 INVALID 객체 재컴파일 (순차 방식)
EXEC UTL_RECOMP.RECOMP_SERIAL('SCHEMA_NAME');

-- 병렬 방식 재컴파일 (CPU 코어 수만큼 병렬 처리)
EXEC UTL_RECOMP.RECOMP_PARALLEL(4, 'SCHEMA_NAME');

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

STEP 4: utlrp.sql 스크립트 활용

DBA 레벨에서 데이터베이스 전체의 INVALID 객체를 일괄 재컴파일합니다.

-- SYS 또는 SYSDBA 권한으로 실행
-- sqlplus / as sysdba
@?/rdbms/admin/utlrp.sql

-- 재컴파일 후 결과 확인
SELECT object_type,
       COUNT(*) AS total_count,
       SUM(CASE WHEN status = 'INVALID' THEN 1 ELSE 0 END) AS invalid_count,
       SUM(CASE WHEN status = 'VALID'   THEN 1 ELSE 0 END) AS valid_count
FROM   dba_objects
WHERE  object_type IN ('PROCEDURE','FUNCTION','PACKAGE',
                       'PACKAGE BODY','TRIGGER','VIEW')
GROUP  BY object_type
ORDER  BY object_type;

STEP 5: 재컴파일 후에도 INVALID가 유지될 경우

재컴파일 후에도 INVALID 상태가 지속된다면 컴파일 에러를 확인해야 합니다.

-- 특정 객체의 컴파일 에러 조회
SELECT line,
       position,
       text AS error_message
FROM   user_errors
WHERE  name = 'YOUR_OBJECT_NAME'
  AND  type = 'PROCEDURE'  -- FUNCTION, PACKAGE, TRIGGER 등으로 변경 가능
ORDER  BY sequence;

-- 모든 INVALID 객체의 에러 한번에 조회
SELECT name,
       type,
       line,
       text AS error_message
FROM   user_errors
ORDER  BY name, type, sequence;

---

예방 방법

1. 배포 프로세스에 재컴파일 단계 의무화

DDL 변경 작업(ALTER TABLE, DROP/CREATE 등) 이후에는 반드시 자동화된 재컴파일 단계를 배포 스크립트에 포함시켜야 합니다. CI/CD 파이프라인에 UTL_RECOMP.RECOMP_SERIAL 또는 utlrp.sql 실행 단계를 추가하고, 배포 완료 후 INVALID 객체 수를 모니터링하는 검증 쿼리를 실행하여 0건임을 확인하는 절차를 표준화하는 것이 좋습니다.

-- 배포 후 검증 쿼리 예시
SELECT COUNT(*) AS invalid_count
FROM   user_objects
WHERE  status = 'INVALID';
-- 결과가 0이어야 정상

2. 의존성 분석 도구 활용 및 영향도 사전 파악

DDL 작업 전에 반드시 USER_DEPENDENCIES 또는 ALL_DEPENDENCIES 뷰를 이용하여 영향받는 객체 목록을 사전에 파악하고, 변경 작업의 영향 범위를 문서화해야 합니다. Oracle SQL Developer나 Toad 같은 IDE의 의존성 트리(Dependency Tree) 기능을 적극 활용하고, 프로덕션 환경 반영 전 테스트 환경에서 DDL 변경의 파급 효과를 먼저 검증하는 습관을 갖는 것이 장기적으로 장애를 예방하는 최선의 방법입니다.

---

관련 에러

• ORA-04061: existing state of