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

ORA-02262
2026년 08월 15일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-02262 ORA-type error in type-checking of check constraint 는?

ORA-02262 에러는 CHECK 제약 조건을 정의하거나 수정하는 과정에서 데이터 타입 불일치가 발생할 때 나타나는 오류입니다. 주로 ALTER TABLE 또는 CREATE TABLE 문에서 CHECK 제약 조건 내부에 사용된 표현식이 해당 컬럼의 데이터 타입과 맞지 않거나, 잘못된 함수 또는 연산자가 사용될 때 발생합니다. 이 에러는 단독으로 나타나기보다는 하위 ORA 에러(예: ORA-00932, ORA-01722 등)와 함께 출력되어 실제 원인을 함께 확인해야 해결할 수 있습니다.

주요 발생 원인

CHECK 제약 조건 내 데이터 타입 불일치

가장 흔한 원인으로, 숫자형 컬럼에 문자열 리터럴을 직접 비교하거나, 날짜형 컬럼에 숫자를 비교하는 경우 발생합니다. Oracle의 타입 체커는 제약 조건 내부의 표현식을 파싱할 때 엄격한 타입 검증을 수행하기 때문에, 암묵적 변환이 허용되지 않는 상황에서 이 에러가 트리거됩니다. 예를 들어, NUMBER 타입 컬럼에 'ABC'와 같은 문자열 리터럴을 비교 조건으로 사용하면 오류가 발생합니다.

잘못된 함수 또는 연산자 사용

CHECK 제약 조건 안에서 사용할 수 없는 함수(예: SYSDATE, NEXTVAL, 서브쿼리 등)를 사용하거나, 특정 데이터 타입에 적용할 수 없는 연산자를 사용할 때 발생합니다. Oracle CHECK 제약 조건은 비결정적(non-deterministic) 함수나 외부 참조를 허용하지 않으며, 이를 위반하면 타입 체킹 단계에서 에러가 발생합니다. 특히 날짜 연산에서 잘못된 포맷 마스크나 변환 함수를 사용할 때 빈번하게 나타납니다.

컬럼 타입 변경 후 기존 CHECK 제약 조건과의 충돌

기존에 정의된 CHECK 제약 조건이 있는 상태에서 해당 컬럼의 데이터 타입을 ALTER TABLE로 변경할 때 충돌이 발생할 수 있습니다. 예를 들어 VARCHAR2 타입이었던 컬럼을 NUMBER로 변경하면, 기존 CHECK 제약 조건이 문자열 비교 논리를 포함하고 있는 경우 타입 체킹 오류가 발생합니다. 이 경우 제약 조건을 먼저 삭제하고 컬럼 타입을 변경한 뒤 새로운 제약 조건을 재정의해야 합니다.

해결 방법

원인 1 해결: 데이터 타입 일치시키기

CHECK 제약 조건에서 비교 값의 타입을 컬럼 타입에 맞게 수정합니다.

잘못된 예시 (에러 발생):

-- salary 컬럼이 NUMBER 타입인데 문자열과 비교
ALTER TABLE employees
ADD CONSTRAINT chk_salary CHECK (salary > 'ZERO');

올바른 예시 (수정 후):

-- NUMBER 타입 컬럼에는 숫자 리터럴 사용
ALTER TABLE employees
ADD CONSTRAINT chk_salary CHECK (salary > 0);

날짜 타입 컬럼의 올바른 비교 예시:

-- DATE 타입 컬럼에는 DATE 리터럴 또는 TO_DATE 사용
ALTER TABLE contracts
ADD CONSTRAINT chk_start_date CHECK (start_date >= DATE '2000-01-01');

원인 2 해결: 허용되지 않는 함수 제거 및 대체

CHECK 제약 조건 내에 SYSDATE, USER, SEQUENCE 등 비결정적 요소를 제거합니다.

잘못된 예시 (에러 발생):

-- SYSDATE는 CHECK 제약 조건에서 사용 불가
ALTER TABLE orders
ADD CONSTRAINT chk_order_date CHECK (order_date <= SYSDATE);

올바른 대안: 트리거 활용:

-- 트리거로 대체하여 동적 날짜 비교 처리
CREATE OR REPLACE TRIGGER trg_chk_order_date
BEFORE INSERT OR UPDATE ON orders
FOR EACH ROW
BEGIN
  IF :NEW.order_date > SYSDATE THEN
    RAISE_APPLICATION_ERROR(-20001, '주문일자는 현재 날짜를 초과할 수 없습니다.');
  END IF;
END;
/

허용되는 함수 사용 예시:

-- 결정적 함수(UPPER, LENGTH, TO_NUMBER 등)는 사용 가능
ALTER TABLE employees
ADD CONSTRAINT chk_emp_name CHECK (LENGTH(TRIM(emp_name)) > 0);

ALTER TABLE products
ADD CONSTRAINT chk_product_code CHECK (REGEXP_LIKE(product_code, '^[A-Z]{3}[0-9]{4}$'));

원인 3 해결: 제약 조건 재정의

컬럼 타입 변경 전 기존 CHECK 제약 조건을 삭제하고, 변경 후 새로 정의합니다.

-- 1단계: 기존 제약 조건 확인
SELECT constraint_name, search_condition
FROM user_constraints
WHERE table_name = 'EMPLOYEES'
  AND constraint_type = 'C';

-- 2단계: 기존 CHECK 제약 조건 삭제
ALTER TABLE employees
DROP CONSTRAINT chk_old_salary;

-- 3단계: 컬럼 타입 변경
ALTER TABLE employees
MODIFY salary NUMBER(12, 2);

-- 4단계: 새로운 CHECK 제약 조건 재정의
ALTER TABLE employees
ADD CONSTRAINT chk_salary CHECK (salary >= 0 AND salary <= 99999999.99);

에러 발생 원인 상세 확인 방법:

-- 에러 스택 전체 확인 (SQL*Plus 또는 SQL Developer에서 사용)
-- 하위 에러 코드를 함께 확인하여 실제 원인 파악
SHOW ERRORS;

-- 또는 DBMS_UTILITY 패키지로 에러 메시지 확인
BEGIN
  EXECUTE IMMEDIATE '
    ALTER TABLE test_table
    ADD CONSTRAINT chk_test CHECK (test_col > 0)
  ';
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE('에러 코드: ' || SQLCODE);
    DBMS_OUTPUT.PUT_LINE('에러 메시지: ' || SQLERRM);
END;
/

예방 방법

CHECK 제약 조건 정의 전 표현식 유효성 테스트

CHECK 제약 조건을 실제 테이블에 추가하기 전에, 해당 표현식을 SELECT 문으로 미리 테스트하여 타입 오류를 사전에 검증하는 습관을 가져야 합니다. 또한, 팀 내 DDL 변경 작업 시 반드시 코드 리뷰 프로세스를 거쳐 타입 불일치를 사전 예방하는 것이 중요합니다.

“`sql

— CHECK 제약 조건 표현식 사전 테스트 방법

— 실제 데이터로 표현식이 정상 동작하는지 확인

SELECT *

FROM employees

WHERE NOT (salary >= 0 AND salary <= 99999999.99);

— 결과가 없으면 제약 조건 추가 가능

“`

데이터 딕셔너리를 활용한 제약 조건 관리 체계화

모든 CHECK 제약 조건은 의미 있는 이름(예: chk_테이블명_컬럼명)을 부여하고, USER_CONSTRAINTS 및 USER_CONS_COLUMNS 뷰를 통해 주기적으로 제약 조건 현황을 점검해야 합니다. 컬럼 타입 변경 전에는 반드시 관련 제약 조건 목록을 조회하여 충돌 가능성을 미리 파악하는 것이 Best Practice입니다.

“`sql

— 특정 테이블의 모든 CHECK 제약 조건 및 관련 컬럼 조회

SELECT c.constraint_name,

c.search_condition,

cc.column_name,

c.status,

c.validated

FROM user_constraints c

JOIN user_cons_columns cc

ON c.constraint_name = cc.constraint_name

WHERE c.table_name = ‘EMPLOYEES’

AND c.constraint_type = ‘C’

ORDER BY cc.column_name;

“`