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

ORA-06564
2026년 09월 02일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-06564 object does not exist 는?

ORA-06564 에러는 PL/SQL 코드 내에서 RAISE_APPLICATION_ERROR 또는 내장 패키지/프로시저가 참조하는 특정 객체(테이블, 뷰, 시퀀스, 프로시저 등)가 데이터베이스에 존재하지 않을 때 발생합니다. 이 에러는 주로 DBMS_UTILITY, UTL_FILE, DBMS_METADATA 등의 Oracle 내장 패키지 사용 시, 또는 동적 SQL(Dynamic SQL) 실행 도중 객체를 찾을 수 없을 때 트리거됩니다. 개발 환경에서 운영 환경으로 마이그레이션하거나, 스키마 간 객체 이동이 있을 때 특히 자주 목격되는 에러입니다.

주요 발생 원인

참조 객체가 삭제되었거나 이름이 변경된 경우

PL/SQL 프로시저나 패키지가 컴파일 시점에는 정상이었으나, 이후 해당 객체가 DROP 또는 RENAME 되면서 런타임에 ORA-06564가 발생합니다. 특히 대규모 리팩토링 작업이나 테이블 재설계 후 기존 코드와 객체 간의 불일치가 생기는 상황이 전형적인 사례입니다. 이런 경우 USER_OBJECTS 또는 ALL_OBJECTS 뷰를 통해 객체 존재 여부를 사전 확인하는 것이 필수입니다.

스키마(Schema) 또는 권한(Privilege) 문제

현재 세션의 사용자가 참조하는 객체가 다른 스키마에 존재하거나, 해당 객체에 대한 SELECT, EXECUTE 등의 권한이 없는 경우 객체 자체가 존재하지 않는 것처럼 동작하여 이 에러가 발생합니다. 예를 들어 SCHEMA_A의 프로시저에서 SCHEMA_B의 테이블을 직접 참조할 때 동의어(Synonym)나 권한 설정이 누락되어 있으면 ORA-06564로 이어질 수 있습니다. 권한 부여와 동의어 생성 여부를 항상 함께 점검해야 합니다.

동적 SQL(Dynamic SQL) 또는 DBMS_SQL 사용 시 객체명 오타 및 대소문자 문제

EXECUTE IMMEDIATE 또는 DBMS_SQL을 통해 동적으로 SQL을 생성할 때, 객체 이름에 오타가 있거나 대소문자가 맞지 않으면 Oracle은 해당 객체를 찾지 못하고 ORA-06564를 반환합니다. Oracle에서 객체명은 기본적으로 대문자로 저장되므로, 동적 SQL에서 소문자 또는 혼합 대소문자를 사용하면 문제가 발생할 수 있습니다. 동적 SQL 작성 시에는 반드시 UPPER() 함수 또는 일관된 명명 규칙을 적용해야 합니다.

해결 방법

원인 1: 참조 객체 존재 여부 확인 및 재생성

먼저 ALL_OBJECTS 뷰로 해당 객체가 실제로 존재하는지 확인합니다.

-- 객체 존재 여부 확인
SELECT OBJECT_NAME, OBJECT_TYPE, STATUS, OWNER
FROM ALL_OBJECTS
WHERE OBJECT_NAME = UPPER('YOUR_OBJECT_NAME')
  AND OWNER = UPPER('YOUR_SCHEMA_NAME');

-- 무효화된 객체 전체 조회 (INVALID 상태)
SELECT OBJECT_NAME, OBJECT_TYPE, STATUS
FROM USER_OBJECTS
WHERE STATUS = 'INVALID'
ORDER BY OBJECT_TYPE, OBJECT_NAME;

객체가 존재하지 않는다면, 해당 객체를 재생성하거나 DDL 스크립트를 다시 실행합니다.

-- 예시: 누락된 테이블 재생성
CREATE TABLE emp_backup AS
SELECT * FROM employees WHERE 1=0;

-- 예시: 프로시저를 참조하는 패키지 재컴파일
ALTER PACKAGE my_package COMPILE;
ALTER PACKAGE my_package COMPILE BODY;

-- 모든 무효 객체 일괄 재컴파일 (DBA 권한 필요)
EXEC DBMS_UTILITY.COMPILE_SCHEMA(SCHEMA => 'YOUR_SCHEMA', COMPILE_ALL => FALSE);

원인 2: 스키마 권한 및 동의어 설정

다른 스키마의 객체를 참조할 경우, 권한 부여와 동의어를 올바르게 설정합니다.

-- 다른 스키마 테이블에 권한 부여
GRANT SELECT, INSERT, UPDATE, DELETE ON schema_b.target_table TO schema_a;
GRANT EXECUTE ON schema_b.target_procedure TO schema_a;

-- 공용 동의어(Public Synonym) 생성
CREATE PUBLIC SYNONYM target_table FOR schema_b.target_table;

-- 특정 사용자에 대한 Private Synonym 생성
CREATE SYNONYM schema_a.target_table FOR schema_b.target_table;

-- 권한 확인 쿼리
SELECT GRANTEE, PRIVILEGE, TABLE_NAME, OWNER
FROM ALL_TAB_PRIVS
WHERE TABLE_NAME = UPPER('TARGET_TABLE')
  AND OWNER = UPPER('SCHEMA_B');

원인 3: 동적 SQL 객체명 검증

동적 SQL에서 객체명을 사용하기 전에 존재 여부를 검증하는 방어 코드를 작성합니다.

-- 동적 SQL 실행 전 객체 존재 확인 예시
DECLARE
  v_count     NUMBER := 0;
  v_table     VARCHAR2(100) := 'employees';
  v_sql       VARCHAR2(500);
  v_result    NUMBER;
BEGIN
  -- 객체 존재 여부 사전 검증
  SELECT COUNT(*)
  INTO v_count
  FROM ALL_OBJECTS
  WHERE OBJECT_NAME = UPPER(v_table)
    AND OBJECT_TYPE = 'TABLE'
    AND OWNER = UPPER(SYS_CONTEXT('USERENV', 'CURRENT_SCHEMA'));

  IF v_count = 0 THEN
    RAISE_APPLICATION_ERROR(-20001,
      '객체가 존재하지 않습니다: ' || v_table);
  END IF;

  -- 안전하게 동적 SQL 실행
  v_sql := 'SELECT COUNT(*) FROM ' || UPPER(v_table);
  EXECUTE IMMEDIATE v_sql INTO v_result;

  DBMS_OUTPUT.PUT_LINE('Row count: ' || v_result);

EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE('에러 발생: ' || SQLERRM);
    RAISE;
END;
/

예방 방법

배포 전 의존성 점검 자동화

운영 배포(Release) 전에 반드시 ALL_DEPENDENCIES 뷰를 활용하여 변경 대상 객체에 의존하는 모든 PL/SQL 객체를 사전에 파악하고, 변경 영향도를 분석하는 스크립트를 CI/CD 파이프라인에 포함시켜야 합니다. 또한 배포 후에는 DBMS_UTILITY.COMPILE_SCHEMA를 이용해 무효화된 객체를 일괄 재컴파일하는 절차를 표준화하면 ORA-06564와 같은 에러를 사전에 차단할 수 있습니다.

“`sql

— 특정 객체에 의존하는 다른 객체 조회

SELECT NAME, TYPE, DEPENDENCY_TYPE

FROM ALL_DEPENDENCIES

WHERE REFERENCED_NAME = UPPER(‘YOUR_OBJECT_NAME’)

AND REFERENCED_OWNER = UPPER(‘YOUR_SCHEMA’)

ORDER BY TYPE, NAME;

“`

객체 네이밍 컨벤션 및 동의어 관리 정책 수립

모든 객체는 일관된 명명 규칙(예: 대문자, 언더스코어 구분)을 적용하고, 스키마 간 참조가 필요한 경우 반드시 공식 동의어 등록 절차를 거치도록 정책을 수립해야 합니다. 객체명 변경이 발생할 경우 영향받는 동의어와 권한을 함께 갱신하는 변경 관리(Change Management) 프로세스를 운영하면 장기적으로 이 에러의 발생을 크게 줄일 수 있습니다.