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

ORA-14036
2026년 09월 20일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-14036 partition bound value too large for column 는?

ORA-14036 에러는 파티션 테이블을 생성하거나 파티션을 추가(ALTER TABLE ADD PARTITION)할 때, 파티션 경계값(Partition Bound Value)이 해당 파티션 키 컬럼의 데이터 타입이 허용하는 최대 크기를 초과할 때 발생합니다. 예를 들어, VARCHAR2(10)으로 정의된 컬럼에 10자를 초과하는 문자열을 파티션 경계값으로 지정하거나, NUMBER 타입 컬럼에 해당 정밀도(Precision)를 벗어난 숫자를 지정하면 이 에러가 트리거됩니다. 이 에러는 Range 파티션, List 파티션 등 다양한 파티션 유형에서 발생할 수 있으며, DBA 또는 개발자가 파티션 설계 시 컬럼 정의와 경계값의 정합성을 반드시 확인해야 한다는 것을 의미합니다.

주요 발생 원인

1. 파티션 경계값이 컬럼의 최대 길이(VARCHAR2/CHAR)를 초과하는 경우

파티션 키로 사용되는 컬럼이 VARCHAR2(10)처럼 길이 제한이 있는 문자형 타입인데, PARTITION VALUES LESS THAN 또는 VALUES IN 절에 그 길이를 초과하는 문자열을 기입하면 ORA-14036이 발생합니다. 예를 들어 VARCHAR2(10)인 컬럼에 ‘ABCDEFGHIJK'(11자)와 같은 값을 경계값으로 지정하는 경우가 대표적입니다. 이는 테이블 설계 시 컬럼 길이를 충분히 고려하지 않거나, 나중에 파티션을 추가하면서 기존 컬럼 정의를 확인하지 않아 발생하는 경우가 많습니다.

2. NUMBER 타입 컬럼의 정밀도(Precision) 또는 스케일(Scale)을 벗어난 경계값 지정

파티션 키 컬럼이 NUMBER(5) 또는 NUMBER(5,2)처럼 정밀도가 제한된 숫자형일 때, 해당 범위를 초과하는 숫자를 파티션 경계값으로 사용하면 에러가 발생합니다. NUMBER(5)는 최대 99999까지 저장 가능한데 100000 이상의 값을 경계값으로 지정하면 ORA-14036이 발생합니다. 운영 중 데이터 범위가 확장되면서 파티션 추가 시 기존 컬럼 정의를 검토하지 않으면 이런 상황이 빈번하게 발생합니다.

3. DATE/TIMESTAMP 컬럼이 아닌 다른 타입 컬럼에 날짜 형식 문자열을 경계값으로 사용하는 경우

파티션 키가 DATE 타입이 아닌 VARCHAR2 타입으로 날짜 정보를 저장하는 경우(예: VARCHAR2(8), ‘YYYYMMDD’ 형식), 경계값으로 TO_DATE 함수를 잘못 사용하거나 8자리를 초과하는 날짜 문자열을 지정하면 에러가 발생합니다. 이런 구조는 레거시 시스템에서 자주 발견되며, 컬럼 타입과 파티션 경계값의 타입이 불일치하거나 길이가 맞지 않아 ORA-14036이 발생합니다. 파티션 키 컬럼을 VARCHAR2로 설계할 경우 특히 길이 관리에 주의가 필요합니다.

해결 방법

원인 1 해결: VARCHAR2/CHAR 컬럼 길이 초과 시

먼저 현재 파티션 키 컬럼의 정의를 확인합니다.

-- 파티션 키 컬럼 정의 확인
SELECT COLUMN_NAME, DATA_TYPE, DATA_LENGTH, DATA_PRECISION, DATA_SCALE
FROM   DBA_TAB_COLUMNS
WHERE  TABLE_NAME = 'SALES_RANGE'
AND    COLUMN_NAME = 'REGION_CODE';

경계값이 컬럼 길이를 초과하는 경우, 컬럼 길이를 늘리거나 경계값을 컬럼 길이 내로 수정합니다.

-- 잘못된 예: REGION_CODE VARCHAR2(10) 인데 11자 경계값 사용 -> ORA-14036 발생
CREATE TABLE SALES_RANGE (
    REGION_CODE VARCHAR2(10),
    SALE_AMOUNT NUMBER
)
PARTITION BY LIST (REGION_CODE) (
    PARTITION P_SEOUL   VALUES ('SEOUL_NORTH'),   -- 11자 -> 에러!
    PARTITION P_BUSAN   VALUES ('BUSAN'),
    PARTITION P_DEFAULT VALUES (DEFAULT)
);

-- 해결책 1: 경계값을 10자 이내로 수정
CREATE TABLE SALES_RANGE (
    REGION_CODE VARCHAR2(10),
    SALE_AMOUNT NUMBER
)
PARTITION BY LIST (REGION_CODE) (
    PARTITION P_SEOUL   VALUES ('SEOUL_N'),       -- 7자로 수정
    PARTITION P_BUSAN   VALUES ('BUSAN'),
    PARTITION P_DEFAULT VALUES (DEFAULT)
);

-- 해결책 2: 컬럼 길이를 충분히 늘린 후 파티션 생성
-- (파티션 테이블의 경우 MODIFY COLUMN은 제약이 있으므로 재생성이 필요할 수 있음)
ALTER TABLE SALES_RANGE MODIFY (REGION_CODE VARCHAR2(20));

-- 이후 파티션 추가
ALTER TABLE SALES_RANGE ADD PARTITION P_INCHEON 
VALUES ('INCHEON_NORTH');

원인 2 해결: NUMBER 타입 정밀도 초과 시

-- 잘못된 예: DEPT_ID NUMBER(5) 컬럼에 6자리 숫자를 경계값으로 사용
CREATE TABLE EMP_PART (
    DEPT_ID    NUMBER(5),
    EMP_NAME   VARCHAR2(100),
    HIRE_DATE  DATE
)
PARTITION BY RANGE (DEPT_ID) (
    PARTITION P1 VALUES LESS THAN (100000),
    PARTITION P2 VALUES LESS THAN (200000),   -- 200000은 6자리 -> NUMBER(5) 초과 -> ORA-14036!
    PARTITION P3 VALUES LESS THAN (MAXVALUE)
);

-- 해결책: 컬럼 타입을 NUMBER(6) 이상으로 변경하거나 경계값을 조정
-- 방법 A: 컬럼 정밀도 변경 (파티션 컬럼 MODIFY 가능 여부 확인 필요)
ALTER TABLE EMP_PART MODIFY (DEPT_ID NUMBER(7));

-- 방법 B: 경계값을 NUMBER(5) 범위 내로 조정 (99999 이하)
CREATE TABLE EMP_PART (
    DEPT_ID    NUMBER(5),
    EMP_NAME   VARCHAR2(100),
    HIRE_DATE  DATE
)
PARTITION BY RANGE (DEPT_ID) (
    PARTITION P1 VALUES LESS THAN (10000),
    PARTITION P2 VALUES LESS THAN (50000),
    PARTITION P3 VALUES LESS THAN (MAXVALUE)
);

-- 파티션 키 컬럼의 현재 제약 확인
SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, DATA_PRECISION, DATA_SCALE
FROM   USER_TAB_COLUMNS
WHERE  TABLE_NAME = 'EMP_PART'
AND    COLUMN_NAME = 'DEPT_ID';

원인 3 해결: VARCHAR2 날짜형 컬럼의 파티션 경계값 불일치

-- 잘못된 예: VARCHAR2(8) 컬럼(YYYYMMDD)에 8자 초과 문자열 경계값 사용
CREATE TABLE ORDER_HIST (
    ORDER_DATE VARCHAR2(8),   -- YYYYMMDD 형식
    ORDER_AMT  NUMBER
)
PARTITION BY RANGE (ORDER_DATE) (
    PARTITION P_2023 VALUES LESS THAN ('2023-01-01'),  -- 10자 -> ORA-14036!
    PARTITION P_2024 VALUES LESS THAN ('2024-01-01'),
    PARTITION P_MAX  VALUES LESS THAN (MAXVALUE)
);

-- 해결책: 경계값을 YYYYMMDD(8자) 형식으로 통일
CREATE TABLE ORDER_HIST (
    ORDER_DATE VARCHAR2(8),   -- YYYYMMDD 형식
    ORDER_AMT  NUMBER
)
PARTITION BY RANGE (ORDER_DATE) (
    PARTITION P_2023 VALUES LESS THAN ('20230101'),   -- 8자로 수정
    PARTITION P_2024 VALUES LESS THAN ('20240101'),
    PARTITION P_MAX  VALUES LESS THAN (MAXVALUE)
);

-- 기존 파티션 테이블에 파티션을 추가할 경우에도 동일 규칙 적용
ALTER TABLE ORDER_HIST ADD PARTITION P_2025 
VALUES LESS THAN ('20250101');

-- 참고: DATE 타입을 파티션 키로 사용하는 것이 더 권장되는 방법
CREATE TABLE ORDER_HIST_BEST (
    ORDER_DATE DATE,
    ORDER_AMT  NUMBER
)
PARTITION BY RANGE (ORDER_DATE) (
    PARTITION P_2023 VALUES LESS THAN (TO_DATE('20230101', 'YYYYMMDD')),
    PARTITION P_2024 VALUES LESS THAN (TO_DATE('20240101', 'YYYYMMDD')),
    PARTITION P_MAX  VALUES LESS THAN (MAXVALUE)
);

예방 방법

1. 파티션 설계 전 컬럼 정의와 경계값 범위를 사전 검토하는 표준 절차 수립

파티션 테이블을 설계하거나 파티션을 추가하기 전에, 반드시 파티션 키 컬럼의 DATA_TYPE, DATA_LENGTH, DATA_PRECISION, DATA_SCALE을 DBA_TAB_COLUMNS(또는 USER_TAB_COLUMNS) 뷰를 통해 먼저 조회하는 것을 팀 표준으로 정합니다. 파티션 경계값은 항상 해당 컬럼의 허용 범위보다 여유 있게 설정하고, 특히 VARCHAR2 파티션 키 컬럼의 경우 실제 데이터 최대 길이보다 컬럼 길이를 충분히 크게 정의해야 합니다. 또한 파티션 DDL 스크립트를 작성할 때 동료 DBA 또는 개발자의 리뷰(Cross-check) 과정을 의무화하면 실수를 사전에 방지할 수 있습니다.

2. 파티션 키 컬럼 타입 선택 시 DATE/NUMBER를 우선 사용하고 VARCHAR2 파티션 키는 최소화

VARCHAR2 타입의 파티션 키는 길이 관리와 정렬 순서(사전순 정렬) 문제로 인해 운영 중 ORA-14036을 포함한 다양한 에러를 유발할 수 있으므로, 가능하면 DATE, TIMESTAMP, NUMBER 타입을 파티션 키로 사용하는 것이 Best Practice입니다. 날짜 기반 파티션이라면 VARCHAR2 대신 DATE 타입을 사용하고, 숫자 기반 파티션이라면 향후 데이터 증가를 고려하여 NUMBER의 정밀도를 넉넉하게 설정(예: NUMBER 또는 NUMBER(10))합니다. 이를 통해 장기적으로 파티션 경계값 관련 에러를 원천적으로 줄일 수 있습니다.