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

ORA-02264 name already used by an existing constraint 는?

ORA-02264 에러는 Oracle 데이터베이스에서 제약 조건(Constraint)을 생성하거나 변경할 때, 이미 동일한 이름의 제약 조건이 해당 스키마 내에 존재할 경우 발생하는 에러입니다. Oracle에서 제약 조건의 이름은 동일한 스키마(Schema) 내에서 반드시 고유해야 하며, 이 규칙을 위반하면 즉시 이 에러가 발생합니다. 주로 테이블 생성 스크립트를 재실행하거나, 다른 테이블에 동일한 이름의 제약 조건을 추가하려 할 때 자주 맞닥뜨리는 에러입니다.

---

주요 발생 원인

1. 동일한 스키마 내 중복된 제약 조건 이름 사용

Oracle의 제약 조건 이름은 테이블 단위가 아닌 스키마(Schema) 단위로 유일성이 보장되어야 합니다. 즉, 서로 다른 테이블이라 하더라도 같은 스키마 내에서 동일한 제약 조건 이름을 사용하면 ORA-02264가 발생합니다. 예를 들어, HR 스키마에 PK_EMPLOYEES라는 이름의 제약 조건이 이미 존재하는데, 새로운 테이블에 동일한 이름으로 제약 조건을 추가하려 할 때 이 에러가 발생합니다.

2. DDL 스크립트 중복 실행 (재실행 시 제약 조건 이미 생성된 경우)

개발 또는 배포 과정에서 테이블 생성 스크립트나 ALTER TABLE 스크립트를 실수로 두 번 이상 실행하면, 첫 번째 실행에서 이미 제약 조건이 생성되어 있어 두 번째 실행 시 ORA-02264 에러가 발생합니다. 특히 CI/CD 파이프라인이나 배포 자동화 환경에서 멱등성(Idempotency)을 고려하지 않은 스크립트가 반복 실행될 때 빈번하게 발생합니다.

3. 제약 조건 삭제 없이 재생성 시도

기존 제약 조건을 수정하기 위해 DROP 없이 동일한 이름으로 ADD CONSTRAINT를 시도할 경우 이 에러가 발생합니다. Oracle은 제약 조건의 직접적인 수정(MODIFY)을 지원하지 않으며, 반드시 기존 제약 조건을 DROP한 후 새로운 제약 조건을 ADD해야 합니다. 이 과정을 빠뜨리거나 순서를 잘못 이해한 경우 에러가 발생합니다.

---

해결 방법

원인 1 해결: 기존 제약 조건 이름 확인 후 중복 여부 파악

먼저 현재 스키마에 존재하는 제약 조건 이름을 조회하여 중복 여부를 확인합니다.

-- 현재 스키마의 모든 제약 조건 이름 조회
SELECT constraint_name, table_name, constraint_type, status
FROM user_constraints
WHERE constraint_name = 'PK_EMPLOYEES'
ORDER BY table_name;

-- 특정 테이블의 모든 제약 조건 조회
SELECT constraint_name, constraint_type, status, validated
FROM user_constraints
WHERE table_name = 'EMPLOYEES';

-- 전체 스키마에서 제약 조건 이름이 중복된 항목 찾기
SELECT constraint_name, COUNT(*) AS cnt
FROM user_constraints
GROUP BY constraint_name
HAVING COUNT(*) > 1;

중복이 확인된 경우, 새로 추가할 제약 조건의 이름을 변경하여 유일성을 확보합니다.

-- 중복을 피하기 위해 고유한 이름으로 제약 조건 추가
ALTER TABLE departments
ADD CONSTRAINT PK_DEPARTMENTS_001 PRIMARY KEY (department_id);

---

원인 2 해결: 스크립트 멱등성 확보 (존재 여부 확인 후 실행)

배포 스크립트에서 제약 조건이 이미 존재하는지 확인하고, 없을 때만 생성하도록 작성합니다.

-- PL/SQL을 활용한 멱등성 있는 제약 조건 생성
DECLARE
  v_count NUMBER;
BEGIN
  SELECT COUNT(*)
  INTO v_count
  FROM user_constraints
  WHERE constraint_name = 'PK_EMPLOYEES';

  IF v_count = 0 THEN
    EXECUTE IMMEDIATE '
      ALTER TABLE employees
      ADD CONSTRAINT PK_EMPLOYEES PRIMARY KEY (employee_id)
    ';
    DBMS_OUTPUT.PUT_LINE('제약 조건 PK_EMPLOYEES 생성 완료.');
  ELSE
    DBMS_OUTPUT.PUT_LINE('제약 조건 PK_EMPLOYEES 이미 존재합니다. 건너뜁니다.');
  END IF;
END;
/

---

원인 3 해결: 기존 제약 조건 DROP 후 재생성

제약 조건을 수정해야 할 경우, 반드시 기존 것을 먼저 삭제한 뒤 새로 추가합니다.

-- Step 1: 기존 제약 조건 비활성화 및 삭제
ALTER TABLE employees DISABLE CONSTRAINT PK_EMPLOYEES;
ALTER TABLE employees DROP CONSTRAINT PK_EMPLOYEES;

-- Step 2: 새로운 제약 조건 추가
ALTER TABLE employees
ADD CONSTRAINT PK_EMPLOYEES PRIMARY KEY (employee_id)
USING INDEX TABLESPACE INDX;

-- Step 3: 제약 조건 상태 확인
SELECT constraint_name, constraint_type, status, validated
FROM user_constraints
WHERE table_name = 'EMPLOYEES'
AND constraint_name = 'PK_EMPLOYEES';

외래 키(FK) 제약 조건이 걸려 있어 DROP이 불가한 경우 CASCADE 옵션을 사용합니다.

-- 참조 제약 조건이 있는 경우 CASCADE로 삭제
ALTER TABLE employees DROP CONSTRAINT PK_EMPLOYEES CASCADE;

---

제약 조건 이름 변경 (Oracle 12c 이상)

Oracle 12c 이상에서는 기존 제약 조건의 이름을 직접 변경할 수 있습니다.

-- Oracle 12c 이상: 제약 조건 이름 변경
ALTER TABLE employees
RENAME CONSTRAINT PK_EMPLOYEES TO PK_EMPLOYEES_NEW;

-- 변경 결과 확인
SELECT constraint_name, table_name
FROM user_constraints
WHERE table_name = 'EMPLOYEES';

---

예방 방법

1. 제약 조건 명명 규칙(Naming Convention) 수립 및 준수

팀 전체가 일관된 명명 규칙을 사용하면 중복 이름으로 인한 에러를 사전에 방지할 수 있습니다. 예를 들어 {제약유형}_{테이블명}_{컬럼명} 형식을 표준으로 정하면 중복 가능성이 현저히 줄어듭니다. 아래와 같은 규칙을 팀 내 코딩 표준으로 문서화하여 공유하는 것을 권장합니다.

-- 권장 명명 규칙 예시
-- PK: PK_{테이블명}
-- FK: FK_{테이블명}_{참조테이블명}
-- UK: UK_{테이블명}_{컬럼명}
-- CK: CK_{테이블명}_{컬럼명}

ALTER TABLE orders ADD CONSTRAINT PK_ORDERS PRIMARY KEY (order_id);
ALTER TABLE orders ADD CONSTRAINT FK_ORDERS_CUSTOMERS FOREIGN KEY (customer_id) REFERENCES customers(customer_id);
ALTER TABLE orders ADD CONSTRAINT UK_ORDERS_ORDER_NO UNIQUE (order_no);
ALTER TABLE orders ADD CONSTRAINT CK_ORDERS_STATUS CHECK (status IN ('PENDING', 'SHIPPED', 'DELIVERED'));

2. 배포 전 제약 조건 존재 여부를 자동으로 검증하는 스크립트 작성

운영 환경 배포 전, 추가할 모든 제약 조건의 이름이 중복되지 않는지 사전 점검하는 검증 스크립트를 CI/CD 파이프라인에 포함시킵니다. 이를 통해 배포 실패를 사전에 방지하고 롤백 비용을 줄일 수 있습니다.

-- 배포 전 제약 조건 사전 점검 스크립트 예시
SELECT 'CONFLICT: ' || constraint_name || ' already exists on table ' || table_name AS warning_message
FROM user_constraints
WHERE constraint_name IN (
  'PK_NEW_TABLE',
  'FK_NEW_TABLE_REF',
  'UK_NEW_TABLE_COL1'
);
-- 결과가 없으면 배포 진행, 결과가 있으면 배포 중단 및 이름 변경 처리

---

관련 에러

• ORA-02260: table can have only one primary key — 하나의 테이블에 기본 키를 두 개 이상 추가하려 할 때 발생하며, ORA-02264와 함께 제약 조건 관련 DDL 작업 시 자주 등장합니다.
• ORA-02261: such unique or primary key already exists in the table — 이미 동일한 컬럼 조합에 대해 UNIQUE 또는 PRIMARY KEY 제약 조건이 존재할 때 발생합니다.
• ORA-00001: unique constraint violated — 제약 조건 위반의 런타임 버전으로, DML 실행 시 UNIQUE 또는 PRIMARY KEY 제약 조건에 위배되는 데이터를 삽입할 때 발생합니다.
• ORA-02275: such a referential constraint already exists in the table — 이미 동일한 외래 키(FK) 제약 조건이 존재할 때 발생하며, ORA-02264와 유사한 맥락에서 발생합니다.

---

본 포스트는 AI가 생성한 기술 가이드입니다. 운영 환경 적용 전 충분한 검토를 권장합니다.