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

ORA-04045
2026년 08월 22일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-04045 errors during recompilation/revalidation 는?

ORA-04045는 Oracle 데이터베이스에서 저장 프로시저, 함수, 패키지, 트리거, 뷰 등의 객체를 재컴파일하거나 재검증(revalidation)하는 과정에서 오류가 발생할 때 나타나는 에러입니다. 주로 의존하는 객체(테이블, 뷰, 다른 프로시저 등)가 변경되거나 삭제된 경우, 또는 해당 객체에 대한 권한이 변경되었을 때 발생합니다. 이 에러는 단독으로 발생하기보다는 다른 에러(예: ORA-00942, ORA-06508 등)와 함께 출력되는 경우가 많아, 원인 파악 시 전체 에러 스택을 꼼꼼히 살펴보는 것이 중요합니다.

주요 발생 원인

1. 의존 객체(Dependent Object)의 변경 또는 삭제

Oracle의 객체는 서로 의존 관계를 가집니다. 예를 들어 프로시저가 참조하는 테이블의 컬럼이 삭제되거나 데이터 타입이 변경되면, 해당 프로시저는 INVALID 상태가 되며 다음 실행 시 자동 재컴파일을 시도합니다. 이때 의존 객체의 변경 사항이 프로시저 내부 로직과 호환되지 않으면 ORA-04045가 발생합니다.

2. 권한(Privilege) 변경 또는 Role을 통한 권한 부여

저장 프로시저나 함수는 생성 당시의 권한 컨텍스트(Definer’s Right)로 실행됩니다. 만약 프로시저가 참조하는 객체에 대한 권한이 REVOKE되었거나, Role을 통해 부여된 권한을 기반으로 컴파일된 경우(Role을 통한 권한은 저장 객체 컴파일 시 인정되지 않음) 재컴파일 과정에서 ORA-04045가 발생할 수 있습니다. 특히 DBA나 보안 담당자가 권한을 정리하는 과정에서 예기치 않게 발생하는 경우가 많습니다.

3. 객체의 DDL 변경으로 인한 연쇄 INVALID 상태

하나의 객체가 INVALID 상태가 되면, 그 객체를 참조하는 모든 객체들도 연쇄적으로 INVALID 상태가 됩니다. 예를 들어 패키지 스펙(Spec)이 변경되면 해당 패키지를 사용하는 모든 프로시저와 함수가 INVALID가 되며, 이들이 재컴파일될 때 오류가 있는 경우 ORA-04045가 발생합니다. 대규모 스키마 변경 작업 후에 이러한 연쇄 에러가 집중적으로 발생하는 것을 현장에서 자주 목격하게 됩니다.

해결 방법

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;

-- 특정 스키마의 INVALID 객체 조회 (DBA 권한 필요)
SELECT owner, object_name, object_type, status, last_ddl_time
FROM   dba_objects
WHERE  status = 'INVALID'
ORDER BY owner, object_type, object_name;

2단계: 의존성 관계 파악

어떤 객체가 어떤 객체를 참조하는지 확인합니다.

-- 특정 객체를 참조하는 객체 조회
SELECT name, type, referenced_name, referenced_type
FROM   user_dependencies
WHERE  referenced_name = 'YOUR_TABLE_NAME'  -- 변경된 테이블명 입력
ORDER BY type, name;

-- 재귀적으로 의존성 전체 조회 (계층 구조)
SELECT LEVEL, name, type, referenced_name, referenced_type
FROM   user_dependencies
START WITH referenced_name = 'YOUR_TABLE_NAME'
CONNECT BY PRIOR name = referenced_name
ORDER BY LEVEL;

3단계: 에러 상세 내용 확인

ORA-04045와 함께 발생한 상세 에러를 확인합니다.

-- 컴파일 에러 상세 조회
SELECT line, position, text
FROM   user_errors
WHERE  name = 'YOUR_PROCEDURE_NAME'  -- 에러가 발생한 객체명 입력
  AND  type = 'PROCEDURE'
ORDER BY sequence;

-- 모든 INVALID 객체의 에러 한번에 조회
SELECT e.name, e.type, e.line, e.text
FROM   user_errors e
WHERE  EXISTS (
    SELECT 1 FROM user_objects o
    WHERE  o.object_name = e.name
      AND  o.status = 'INVALID'
)
ORDER BY e.name, e.line;

4단계: 수동 재컴파일

원인을 파악한 후, 개별 객체 또는 전체 INVALID 객체를 재컴파일합니다.

-- 개별 객체 재컴파일
ALTER PROCEDURE your_procedure_name COMPILE;
ALTER FUNCTION  your_function_name  COMPILE;
ALTER PACKAGE   your_package_name   COMPILE;
ALTER PACKAGE   your_package_name   COMPILE BODY;
ALTER TRIGGER   your_trigger_name   COMPILE;
ALTER VIEW      your_view_name      COMPILE;

-- 패키지 스펙과 바디를 함께 재컴파일
ALTER PACKAGE your_package_name COMPILE PACKAGE;

5단계: UTL_RECOMP 패키지를 이용한 일괄 재컴파일 (권장)

Oracle에서 제공하는 UTL_RECOMP 패키지를 사용하면 INVALID 객체를 효율적으로 재컴파일할 수 있습니다.

-- 현재 스키마의 모든 INVALID 객체 재컴파일 (순차)
EXEC UTL_RECOMP.RECOMP_SCHEMA(schema_name => 'YOUR_SCHEMA');

-- 병렬 처리로 재컴파일 (대규모 환경에서 권장, 4개 스레드 사용)
EXEC UTL_RECOMP.RECOMP_SCHEMA(schema_name => 'YOUR_SCHEMA', num_threads => 4);

-- 데이터베이스 전체 INVALID 객체 재컴파일 (DBA 권한 필요)
EXEC UTL_RECOMP.RECOMP_PARALLEL(num_threads => 4);

6단계: 권한 문제인 경우 해결

-- 프로시저가 참조하는 객체에 대한 직접 권한 부여 확인
SELECT grantee, table_name, privilege, grantable
FROM   dba_tab_privs
WHERE  grantee = 'YOUR_SCHEMA';

-- Role이 아닌 직접 권한 부여 (저장 객체 컴파일을 위해 반드시 직접 부여)
GRANT SELECT ON schema_owner.table_name TO your_schema;
GRANT EXECUTE ON schema_owner.package_name TO your_schema;

-- 권한 부여 후 재컴파일
ALTER PROCEDURE your_schema.procedure_name COMPILE;

예방 방법

1. 스키마 변경 후 자동 재컴파일 스크립트 실행 자동화

운영 환경에서 DDL 변경 작업(테이블 컬럼 추가/삭제, 타입 변경, 패키지 수정 등) 후에는 반드시 INVALID 객체 재컴파일 절차를 표준화하여 자동화해야 합니다. Jenkins, cron job, 또는 Oracle Scheduler를 활용하여 DDL 변경 후 자동으로 UTL_RECOMP를 실행하는 파이프라인을 구축하면 운영 중 ORA-04045로 인한 장애를 사전에 방지할 수 있습니다.

-- Oracle Scheduler를 이용한 재컴파일 자동화 예시
BEGIN
  DBMS_SCHEDULER.CREATE_JOB(
    job_name        => 'RECOMP_INVALID_OBJECTS',
    job_type        => 'PLSQL_BLOCK',
    job_action      => 'BEGIN UTL_RECOMP.RECOMP_PARALLEL(4); END;',
    start_date      => SYSTIMESTAMP,
    repeat_interval => 'FREQ=DAILY; BYHOUR=2; BYMINUTE=0',
    enabled         => TRUE,
    comments        => 'Daily recompilation of invalid objects'
  );
END;
/

2. 의존성 분석을 포함한 변경 영향도 평가(Impact Analysis) 프로세스 수립

DDL 변경 작업 전에 반드시 의존성 분석을 수행하고, 영향받는 객체 목록을 사전에 파악하는 프로세스를 정착시켜야 합니다. DBA_DEPENDENCIES 뷰를 활용하거나 Oracle SQL Developer의 ‘Find DB Objects’ 기능, 또는 별도의 변경 관리 도구(예: Flyway, Liquibase)를 통해 변경 전 영향도를 분석하는 것이 Best Practice입니다.

-- 변경 예정 객체의 영향 범위를 사전에 파악하는 스크립트
SELECT COUNT(*) AS impacted_objects,
       object_type
FROM   dba_dependencies
WHERE  referenced_owner = 'TARGET_SCHEMA'
  AND  referenced_name  = 'TARGET_OBJECT'
GROUP BY object_type
ORDER BY COUNT(*) DESC;