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

ORA-14060
2026년 09월 21일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-14060 data type or length of a table partitioning column may not be changed 는?

ORA-14060 에러는 Oracle 파티션 테이블에서 파티셔닝 키(Partitioning Key) 컬럼의 데이터 타입이나 길이를 변경하려 할 때 발생하는 에러입니다. Oracle은 파티션 테이블의 무결성과 파티션 경계값(Partition Bound) 일관성을 보장하기 위해 파티셔닝 컬럼의 타입 및 길이 변경을 원천적으로 차단합니다. 예를 들어 ALTER TABLE ... MODIFY 구문으로 파티셔닝 키 컬럼의 데이터 타입을 VARCHAR2(100)에서 VARCHAR2(200)으로 바꾸거나, NUMBER(10)을 NUMBER(15)로 변경하려 할 때 이 에러가 발생합니다.

주요 발생 원인

파티셔닝 키 컬럼의 데이터 타입 직접 변경 시도

가장 흔한 원인으로, 운영 중인 파티션 테이블의 파티셔닝 키 컬럼에 ALTER TABLE ... MODIFY 구문을 직접 실행할 때 발생합니다. 파티셔닝 키는 각 파티션의 데이터 분포 기준이 되므로, Oracle은 이 컬럼의 타입 변경이 기존 파티션 경계값과 충돌할 수 있다고 판단하여 작업 자체를 허용하지 않습니다. 예를 들어 RANGE 파티션의 기준 컬럼을 DATE에서 TIMESTAMP로 바꾸려는 경우가 대표적입니다.

파티셔닝 키 컬럼의 길이(Length) 변경 시도

데이터 타입은 그대로 유지하더라도 컬럼 길이를 변경하려 할 때도 동일한 에러가 발생합니다. 예를 들어 LIST 파티션의 기준 컬럼이 VARCHAR2(50)으로 정의되어 있을 때, 이를 VARCHAR2(100)으로 늘리거나 VARCHAR2(20)으로 줄이려는 시도 모두 ORA-14060을 유발합니다. 이는 파티션 경계값 자체가 원래 컬럼 타입과 길이를 기준으로 저장되어 있기 때문입니다.

DDL 자동화 스크립트 또는 마이그레이션 툴에서의 무분별한 실행

데이터 마이그레이션, 스키마 버전 관리, 또는 ORM(Object-Relational Mapping) 프레임워크에서 자동 생성된 DDL 스크립트가 파티션 테이블 여부를 확인하지 않고 컬럼 변경을 시도할 때 발생합니다. 특히 Flyway, Liquibase 같은 마이그레이션 툴이나 Hibernate DDL Auto 기능이 활성화된 환경에서 빈번하게 나타납니다. 일반 테이블에서는 정상 동작하던 스크립트가 파티션 테이블에서는 ORA-14060을 발생시키는 경우가 많습니다.

해결 방법

해결책 1: 새 테이블 생성 후 데이터 이관 (권장)

파티셔닝 키 컬럼의 타입 변경이 반드시 필요하다면, 원본 테이블을 직접 수정하는 것은 불가능합니다. 원하는 구조로 새 파티션 테이블을 생성하고 데이터를 이관한 후 원본 테이블을 교체하는 방식이 가장 안전하고 권장되는 방법입니다.

-- 1단계: 새로운 파티션 테이블 생성 (변경할 타입 적용)
CREATE TABLE orders_new (
    order_id     NUMBER,
    order_date   DATE,
    region_code  VARCHAR2(100),  -- 기존 VARCHAR2(50)에서 확장
    amount       NUMBER(15, 2)
)
PARTITION BY RANGE (order_date) (
    PARTITION p_2022 VALUES LESS THAN (DATE '2023-01-01'),
    PARTITION p_2023 VALUES LESS THAN (DATE '2024-01-01'),
    PARTITION p_2024 VALUES LESS THAN (DATE '2025-01-01'),
    PARTITION p_max  VALUES LESS THAN (MAXVALUE)
);

-- 2단계: 기존 데이터 이관 (대용량의 경우 INSERT /*+ APPEND */ 활용)
INSERT /*+ APPEND PARALLEL(orders_new, 4) */
INTO orders_new
SELECT order_id, order_date, region_code, amount
FROM orders;
COMMIT;

-- 3단계: 인덱스 재생성
CREATE INDEX idx_orders_new_region
    ON orders_new (region_code) LOCAL;

-- 4단계: 테이블 이름 교체 (서비스 중단 최소화)
RENAME orders TO orders_old;
RENAME orders_new TO orders;

-- 5단계: 기존 테이블 정리 (충분한 검증 후 삭제)
-- DROP TABLE orders_old PURGE;

해결책 2: 파티셔닝 키가 아닌 컬럼인지 확인 후 수정

에러가 발생했을 때 먼저 해당 컬럼이 실제로 파티셔닝 키인지 확인해야 합니다. 파티셔닝 키가 아닌 다른 컬럼이라면 일반적인 ALTER TABLE MODIFY가 가능합니다.

-- 파티셔닝 키 컬럼 확인
SELECT
    kc.name          AS table_name,
    c.name           AS column_name,
    c.column_position,
    tc.data_type,
    tc.data_length,
    tc.data_precision
FROM
    dba_part_key_columns kc
    JOIN dba_tab_columns  tc
        ON  tc.table_name  = kc.name
        AND tc.column_name = kc.column_name
        AND tc.owner       = kc.owner
WHERE
    kc.owner      = 'YOUR_SCHEMA'
    AND kc.name   = 'ORDERS';

-- 만약 변경하려는 컬럼이 파티셔닝 키가 아닌 경우 → 정상적으로 변경 가능
ALTER TABLE orders MODIFY (region_code VARCHAR2(100));

해결책 3: EXCHANGE PARTITION을 활용한 부분 변경

특정 파티션의 데이터만 처리해야 하는 경우, EXCHANGE PARTITION을 이용해 일반 테이블로 전환 후 작업을 수행하는 방법도 있습니다.

-- 1단계: 임시 일반 테이블 생성 (파티셔닝 없이)
CREATE TABLE orders_temp AS
SELECT * FROM orders WHERE 1 = 0;

-- 2단계: 특정 파티션 데이터를 임시 테이블과 교환
ALTER TABLE orders
    EXCHANGE PARTITION p_2023
    WITH TABLE orders_temp
    WITHOUT VALIDATION;

-- 3단계: 임시 테이블에서 컬럼 변경 (일반 테이블이므로 가능)
ALTER TABLE orders_temp MODIFY (region_code VARCHAR2(100));

-- 4단계: 변경된 임시 테이블을 다시 파티션으로 교환
-- (단, 파티셔닝 키 컬럼 타입은 여전히 원본과 동일해야 함)
ALTER TABLE orders
    EXCHANGE PARTITION p_2023
    WITH TABLE orders_temp
    WITHOUT VALIDATION;

-- 5단계: 정리
DROP TABLE orders_temp;

예방 방법

초기 설계 단계에서 파티셔닝 키 컬럼의 타입과 길이를 충분히 고려하기

파티션 테이블을 설계할 때 파티셔닝 키 컬럼은 향후 확장 가능성을 고려하여 넉넉한 타입과 길이로 정의하는 것이 중요합니다. 예를 들어 날짜 기반 파티셔닝에는 DATE 대신 TIMESTAMP를 처음부터 사용하고, 문자열 기반 파티셔닝에는 예상 최대 길이보다 여유 있게 설정합니다. DDL 변경 전 반드시 DBA_PART_KEY_COLUMNS 뷰를 조회하여 해당 컬럼이 파티셔닝 키인지 사전에 확인하는 절차를 팀 내 표준으로 채택하세요.

“`sql

— DDL 변경 전 파티셔닝 키 사전 확인 쿼리 (팀 표준으로 사용 권장)

SELECT owner, name AS table_name, column_name, object_type

FROM dba_part_key_columns

WHERE owner = ‘YOUR_SCHEMA’

ORDER BY name, column_position;

“`

마이그레이션 스크립트에 파티션 테이블 검사 로직 포함하기

자동화된 DDL 스크립트나 마이그레이션 툴을 사용할 경우, 컬럼 변경 전 해당 테이블이 파티션 테이블인지, 변경 대상 컬럼이 파티셔닝 키인지 검사하는 로직을 반드시 포함해야 합니다. 아래와 같은 검증 쿼리를 스크립트 실행 전 단계로 추가하면 사전에 에러를 방지할 수 있습니다.

“`sql

— 파티션 테이블 및 파티셔닝 키 검증 프로시저 예시

DECLARE

v_count NUMBER;

v_table_name VARCHAR2(128) := ‘ORDERS’;

v_column_name VARCHAR2(128) := ‘ORDER_DATE’;

BEGIN

SELECT COUNT(*)

INTO v_count

FROM dba_part_key_columns

WHERE owner = SYS_CONTEXT(‘USERENV’, ‘CURRENT_SCHEMA’)

AND name = v_table_name

AND column_name = v_column_name;

IF v_count > 0 THEN

RAISE_APPLICATION_ERROR(

-20001,

‘경고: ‘ || v_table_name || ‘.’ || v_column_name ||

‘ 은(는) 파티셔닝 키 컬럼입니다. 타입/길이 변경이 불가합니다.’

);

ELSE

DBMS_OUTPUT.PUT_LINE(‘안전: 파티셔닝 키 컬럼이 아닙니다. 변경을 진행합니다.’);

END IF;

END;

“`