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

ORA-14427
2026년 09월 25일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-14427 table does not have ROW MOVEMENT enabled 는?

ORA-14427 에러는 Oracle 데이터베이스에서 ROW MOVEMENT 기능이 활성화되지 않은 테이블에 대해 특정 작업을 수행하려 할 때 발생합니다. 주로 파티션 테이블에서 행(Row)이 다른 파티션으로 이동해야 하는 UPDATE 작업이나, Flashback Table 기능을 사용할 때 이 에러를 자주 접하게 됩니다. Oracle은 기본적으로 ROW MOVEMENT를 비활성화 상태로 설정하므로, 해당 기능이 필요한 작업을 수행하기 전에 명시적으로 활성화해야 합니다.

주요 발생 원인

파티션 테이블에서 파티션 키 값을 변경하는 UPDATE 수행

파티션 테이블에서 파티션 키(Partition Key) 컬럼의 값을 변경하면, 해당 행은 기존 파티션에서 다른 파티션으로 물리적으로 이동해야 합니다. Oracle은 이러한 행 이동(Row Movement)을 기본적으로 허용하지 않으며, ROW MOVEMENT가 활성화되어 있지 않은 상태에서 이 작업을 시도하면 ORA-14427 에러가 발생합니다. 예를 들어, 날짜 기준으로 파티셔닝된 주문 테이블에서 주문 날짜를 다른 연도로 변경하는 경우가 대표적인 사례입니다.

Flashback Table 기능 사용 시

Oracle의 Flashback Table 기능은 테이블을 과거의 특정 시점으로 복원하는 강력한 기능입니다. 이 작업은 내부적으로 현재 행의 ROWID가 변경될 수 있기 때문에, Oracle은 ROW MOVEMENT가 활성화된 테이블에서만 Flashback Table 작업을 허용합니다. DBA나 개발자가 사전에 이 설정을 확인하지 않고 Flashback을 시도할 경우 ORA-14427 에러를 마주치게 됩니다.

Partition Pruning 또는 파티션 관리 작업 중 발생

파티션을 SPLIT, MERGE, MOVE 하는 작업이나 파티션 관련 유지보수 작업에서도 ROW MOVEMENT가 필요한 경우가 있습니다. 특히 Range 파티션이나 List 파티션 환경에서 데이터 마이그레이션 또는 파티션 재구성 작업을 진행할 때, 특정 데이터 행이 다른 파티션으로 이동해야 하는 상황이 발생하며 이때 해당 에러가 트리거됩니다.

해결 방법

1. ROW MOVEMENT 활성화 (가장 일반적인 해결책)

가장 직접적인 해결 방법은 해당 테이블에 ROW MOVEMENT를 활성화하는 것입니다. 아래 SQL을 실행하면 즉시 적용됩니다.

-- ROW MOVEMENT 활성화
ALTER TABLE orders ENABLE ROW MOVEMENT;

-- 활성화 확인
SELECT table_name, row_movement
FROM dba_tables
WHERE table_name = 'ORDERS';

활성화 후 파티션 키를 변경하는 UPDATE를 정상적으로 수행할 수 있습니다.

-- 파티션 키(ORDER_DATE) 변경 예시
UPDATE orders
SET order_date = DATE '2024-01-15'
WHERE order_id = 10001;

COMMIT;

2. Flashback Table 수행 전 ROW MOVEMENT 활성화

Flashback Table을 사용하기 전에 반드시 ROW MOVEMENT를 활성화해야 합니다.

-- Step 1: ROW MOVEMENT 활성화
ALTER TABLE employees ENABLE ROW MOVEMENT;

-- Step 2: Flashback Table 수행 (특정 시점으로 복원)
FLASHBACK TABLE employees TO TIMESTAMP
    TO_TIMESTAMP('2024-06-01 10:00:00', 'YYYY-MM-DD HH24:MI:SS');

-- Step 3: 작업 완료 후 필요 시 ROW MOVEMENT 비활성화
ALTER TABLE employees DISABLE ROW MOVEMENT;

3. 현재 ROW MOVEMENT 상태 점검 쿼리

여러 테이블의 ROW MOVEMENT 상태를 한 번에 확인하는 쿼리입니다.

-- 특정 스키마의 모든 테이블 ROW MOVEMENT 상태 확인
SELECT owner,
       table_name,
       partitioned,
       row_movement
FROM dba_tables
WHERE owner = 'SCOTT'
ORDER BY table_name;

-- ROW MOVEMENT가 비활성화된 파티션 테이블만 조회
SELECT owner,
       table_name,
       partitioned,
       row_movement
FROM dba_tables
WHERE owner = 'SCOTT'
  AND partitioned = 'YES'
  AND row_movement = 'DISABLED'
ORDER BY table_name;

4. 다중 테이블 일괄 활성화 스크립트

운영 환경에서 여러 파티션 테이블에 일괄적으로 ROW MOVEMENT를 활성화해야 할 때 유용한 스크립트입니다.

-- 특정 스키마의 파티션 테이블에 대해 ROW MOVEMENT 일괄 활성화
BEGIN
    FOR rec IN (
        SELECT table_name
        FROM dba_tables
        WHERE owner = 'SCOTT'
          AND partitioned = 'YES'
          AND row_movement = 'DISABLED'
    ) LOOP
        EXECUTE IMMEDIATE 'ALTER TABLE SCOTT.' || rec.table_name
                          || ' ENABLE ROW MOVEMENT';
        DBMS_OUTPUT.PUT_LINE('ROW MOVEMENT 활성화 완료: ' || rec.table_name);
    END LOOP;
END;
/

예방 방법

테이블 생성 시 ROW MOVEMENT 옵션 사전 설정

파티션 테이블을 생성할 때부터 ROW MOVEMENT를 명시적으로 활성화하는 것이 가장 좋은 예방책입니다. 파티션 키를 기준으로 데이터를 변경할 가능성이 조금이라도 있는 테이블이라면 생성 시에 미리 설정해 두십시오. 또한, 팀 내 DDL 표준 가이드에 파티션 테이블 생성 시 ROW MOVEMENT 활성화 여부를 검토하는 절차를 포함시키는 것을 강력히 권장합니다.

“`sql

— 테이블 생성 시 ROW MOVEMENT 활성화 포함

CREATE TABLE sales (

sale_id NUMBER,

sale_date DATE,

amount NUMBER(15, 2),

region VARCHAR2(50)

)

ENABLE ROW MOVEMENT

PARTITION BY RANGE (sale_date) (

PARTITION p_2023 VALUES LESS THAN (DATE ‘2024-01-01’),

PARTITION p_2024 VALUES LESS THAN (DATE ‘2025-01-01’),

PARTITION p_future VALUES LESS THAN (MAXVALUE)

);

“`

정기적인 DB 설정 감사(Audit) 스크립트 운영

DBA는 주기적으로 파티션 테이블의 ROW MOVEMENT 설정 상태를 점검하는 감사 스크립트를 스케줄러에 등록해 운영하는 것이 좋습니다. 특히 신규 테이블이 자주 생성되는 개발/운영 환경에서는 주간 단위로 설정 리포트를 생성하여 DBA가 이를 검토하는 프로세스를 만들면 사전에 문제를 예방할 수 있습니다.

“`sql

— 감사용: 파티션 테이블 중 ROW MOVEMENT 미설정 테이블 리포트

SELECT owner,

table_name,

num_rows,

last_analyzed,

row_movement

FROM dba_tables

WHERE partitioned = ‘YES’

AND row_movement = ‘DISABLED’

AND owner NOT IN (‘SYS’, ‘SYSTEM’, ‘DBSNMP’, ‘SYSMAN’)

ORDER BY owner, table_name;

“`