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

ORA-02239
2026년 08월 12일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-02239 there are objects which reference this sequence 는?

ORA-02239 에러는 Oracle 데이터베이스에서 특정 시퀀스(Sequence)를 삭제하려고 할 때, 해당 시퀀스를 참조하는 객체(뷰, 트리거, 저장 프로시저, 함수 등)가 존재하는 경우 발생합니다. 즉, 다른 데이터베이스 객체들이 해당 시퀀스에 의존하고 있기 때문에 Oracle이 무결성을 보호하기 위해 삭제를 차단하는 것입니다. 실무에서는 배포 스크립트 작성 중이나 스키마 재구성 작업 도중 이 에러를 자주 마주치게 됩니다.

주요 발생 원인

1. 트리거(Trigger)가 시퀀스를 참조하고 있는 경우

가장 빈번하게 발생하는 원인으로, 자동 증가 컬럼 구현을 위해 INSERT 트리거 내에서 시퀀스의 NEXTVAL을 호출하는 패턴이 널리 사용됩니다. 예를 들어 BEFORE INSERT 트리거가 SEQ_EMP_ID.NEXTVAL을 통해 기본 키를 생성하는 구조라면, 해당 시퀀스를 삭제하려는 순간 ORA-02239가 발생합니다. 트리거는 컴파일 시점에 시퀀스와 의존 관계가 등록되므로, DBA가 인지하지 못한 트리거가 존재하는 경우도 많습니다.

2. 뷰(View) 또는 Materialized View에서 시퀀스를 사용하는 경우

일부 설계에서는 뷰 정의 내에서 SEQUENCE.CURRVAL을 활용하거나, 뷰 생성 스크립트에 시퀀스 참조가 포함된 경우가 있습니다. Materialized View의 경우 리프레시 로직 내에 시퀀스 참조가 포함될 수 있어 더욱 발견하기 어렵습니다. 이러한 경우에도 Oracle의 의존성 추적 메커니즘이 시퀀스 삭제를 막게 됩니다.

3. 저장 프로시저, 함수, 패키지(Package)에서 시퀀스를 직접 호출하는 경우

비즈니스 로직을 담당하는 PL/SQL 객체(프로시저, 함수, 패키지)가 내부적으로 시퀀스를 직접 호출하는 경우도 흔합니다. 특히 패키지는 바디(Body)와 스펙(Spec)이 분리되어 있어 의존성 파악이 까다롭고, 대규모 시스템에서는 수십 개의 패키지가 동일한 시퀀스를 참조하는 경우도 있습니다. 이로 인해 개발자가 인지하지 못한 참조 관계가 숨어 있을 수 있습니다.

해결 방법

Step 1: 참조 객체 확인하기

먼저 어떤 객체가 해당 시퀀스를 참조하는지 DBA_DEPENDENCIES 또는 USER_DEPENDENCIES 뷰를 조회하여 확인합니다.

-- 시퀀스를 참조하는 모든 객체 조회 (DBA 권한)
SELECT
    d.owner,
    d.name        AS object_name,
    d.type        AS object_type,
    d.referenced_owner,
    d.referenced_name AS sequence_name
FROM
    dba_dependencies d
WHERE
    d.referenced_name = 'SEQ_EMP_ID'   -- 삭제할 시퀀스 이름으로 변경
    AND d.referenced_type = 'SEQUENCE'
ORDER BY
    d.type, d.name;

-- 일반 사용자 권한으로 확인
SELECT
    name        AS object_name,
    type        AS object_type,
    referenced_name AS sequence_name
FROM
    user_dependencies
WHERE
    referenced_name = 'SEQ_EMP_ID'
    AND referenced_type = 'SEQUENCE';

Step 2: 트리거가 원인인 경우 – 트리거 비활성화 후 삭제

-- 해당 시퀀스를 참조하는 트리거 확인
SELECT trigger_name, table_name, status
FROM   user_triggers
WHERE  trigger_name IN (
           SELECT name
           FROM   user_dependencies
           WHERE  referenced_name = 'SEQ_EMP_ID'
           AND    referenced_type = 'SEQUENCE'
       );

-- 트리거 비활성화
ALTER TRIGGER TRG_EMP_INSERT DISABLE;

-- 또는 트리거 삭제 (신중하게 결정)
DROP TRIGGER TRG_EMP_INSERT;

-- 이후 시퀀스 삭제
DROP SEQUENCE SEQ_EMP_ID;

Step 3: 저장 프로시저/함수/패키지가 원인인 경우

-- 패키지 바디에서 시퀀스 참조 확인
SELECT name, type, line, text
FROM   user_source
WHERE  UPPER(text) LIKE '%SEQ_EMP_ID%'
ORDER  BY name, line;

-- 프로시저 또는 패키지 삭제 후 시퀀스 삭제
DROP PROCEDURE PROC_INSERT_EMP;
-- 또는
DROP PACKAGE PKG_EMP_MANAGEMENT;

-- 이후 시퀀스 삭제
DROP SEQUENCE SEQ_EMP_ID;

Step 4: 시퀀스를 새 시퀀스로 교체해야 하는 경우 (권장 접근법)

시퀀스를 완전히 재생성해야 한다면, 참조 객체를 수정한 뒤 진행하는 것이 안전합니다.

-- 1. 현재 시퀀스의 마지막 값 확인
SELECT last_number, increment_by, min_value, max_value, cycle_flag
FROM   user_sequences
WHERE  sequence_name = 'SEQ_EMP_ID';

-- 2. 새 시퀀스 생성 (기존 값에서 이어서 시작)
CREATE SEQUENCE SEQ_EMP_ID_NEW
    START WITH  10001    -- 기존 시퀀스의 last_number 기준으로 설정
    INCREMENT BY 1
    NOCACHE
    NOCYCLE;

-- 3. 트리거 수정 (새 시퀀스 참조로 변경)
CREATE OR REPLACE TRIGGER TRG_EMP_INSERT
BEFORE INSERT ON EMPLOYEES
FOR EACH ROW
BEGIN
    IF :NEW.emp_id IS NULL THEN
        SELECT SEQ_EMP_ID_NEW.NEXTVAL
        INTO   :NEW.emp_id
        FROM   DUAL;
    END IF;
END;
/

-- 4. 기존 시퀀스 삭제
DROP SEQUENCE SEQ_EMP_ID;

-- 5. 새 시퀀스 이름 변경은 불가하므로 필요 시 모든 참조 객체 일괄 수정 후 재생성

예방 방법

1. 삭제 전 의존성 점검 스크립트를 CI/CD 파이프라인에 통합

배포 스크립트에서 DROP SEQUENCE 구문 실행 전, 자동으로 DBA_DEPENDENCIES를 조회하여 참조 객체가 있는지 검사하는 사전 검증 단계를 추가해야 합니다. 이를 Jenkins, GitLab CI, 또는 Flyway 마이그레이션 스크립트에 포함시키면 실수로 인한 에러를 사전에 차단할 수 있으며, 팀 전체의 배포 안전성이 크게 향상됩니다.

2. 시퀀스 명명 규칙과 소유권 문서화 정책 수립

시퀀스 생성 시 SEQ_[테이블명]_[컬럼명] 형식의 명명 규칙을 적용하고, 어떤 객체가 해당 시퀀스를 사용하는지를 데이터 딕셔너리 코멘트나 별도의 메타데이터 테이블에 기록해 두는 것이 좋습니다. 이렇게 하면 DBA가 교체되더라도 시퀀스의 의존 관계를 쉽게 파악할 수 있고, 스키마 변경 시 영향도 분석이 훨씬 수월해집니다.