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

ORA-12050
2026년 09월 06일 | DBMS Error 가이드

이 글에서 다루는 내용

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

ORA-12050 cannot refresh materialized view fast 는?

ORA-12050 에러는 Oracle Materialized View(구체화 뷰)를 Fast Refresh(빠른 새로 고침) 방식으로 갱신하려 할 때, 해당 작업을 수행할 수 없는 조건이 충족되지 않았을 때 발생하는 에러입니다. Fast Refresh는 변경된 데이터만 증분(incremental) 방식으로 반영하는 효율적인 새로 고침 방식인데, 이를 위해서는 Materialized View Log(MLOG$)를 비롯한 여러 전제 조건이 반드시 갖춰져 있어야 합니다. 이 에러는 주로 Materialized View Log가 없거나, 뷰 정의가 Fast Refresh 제약 조건을 위반하거나, 기존 로그가 불완전할 때 발생하며 실무에서 매우 자주 마주치는 에러 중 하나입니다.

주요 발생 원인

1. Materialized View Log(MLOG$)가 없거나 불완전한 경우

Fast Refresh를 사용하려면 베이스 테이블에 Materialized View Log가 반드시 생성되어 있어야 합니다. Log가 존재하지 않거나, Materialized View 생성 이후에 Log가 삭제 및 재생성된 경우, 또는 Log가 WITH ROWID, PRIMARY KEY, SEQUENCE 등 필요한 옵션을 포함하지 않고 생성된 경우에는 Fast Refresh가 불가능합니다. 특히 Log를 삭제 후 재생성하면 기존 변경 이력이 모두 사라지므로 Complete Refresh를 먼저 수행해야 합니다.

2. Materialized View 정의(쿼리)가 Fast Refresh 제약을 위반하는 경우

Fast Refresh는 지원하는 SQL 구문에 엄격한 제약이 있습니다. DISTINCT, GROUP BY, 분석 함수(Analytic Function), CONNECT BY, ROWNUM, UNION/MINUS/INTERSECT, 서브쿼리 내 집계 함수 등이 포함된 복잡한 쿼리는 Fast Refresh를 지원하지 않을 수 있습니다. 또한 조인(JOIN)을 포함하는 Materialized View의 경우, 조인에 참여하는 모든 테이블에 Materialized View Log가 있어야 하며 SELECT 절에 모든 테이블의 ROWID가 포함되어 있어야 합니다.

3. 마지막 Refresh 이후 베이스 테이블의 DDL 변경이 있었던 경우

베이스 테이블에 컬럼 추가, 제약 조건 변경, 인덱스 재구성 등의 DDL 작업이 수행되면 Materialized View Log의 연속성이 깨져 Fast Refresh가 불가능해집니다. DDL 변경 후에는 MLOG$가 자동으로 무효화되거나 스탈(stale) 상태로 표시되며, 이 경우 반드시 Complete Refresh를 통해 전체 데이터를 다시 동기화한 뒤 Fast Refresh를 재사용해야 합니다.

해결 방법

원인 1 해결: Materialized View Log 생성 및 확인

먼저 베이스 테이블에 Materialized View Log가 있는지 확인합니다.

-- Materialized View Log 존재 여부 확인
SELECT log_owner, master, log_table, rowids, primary_key, sequence
FROM dba_mview_logs
WHERE master = 'YOUR_TABLE_NAME';

-- Log가 없다면 새로 생성 (PRIMARY KEY + ROWID + SEQUENCE 포함)
CREATE MATERIALIZED VIEW LOG ON your_table
WITH PRIMARY KEY, ROWID, SEQUENCE
INCLUDING NEW VALUES;

-- Log 재생성 후 Materialized View를 Complete Refresh로 초기화
EXEC DBMS_MVIEW.REFRESH('YOUR_MVIEW_NAME', method => 'C');

원인 2 해결: Materialized View 정의 검토 및 재생성

Fast Refresh 가능 여부를 DBMS_MVIEW 패키지로 사전 확인합니다.

-- Fast Refresh 가능 여부 사전 검토
DECLARE
  v_msg VARCHAR2(2000);
BEGIN
  DBMS_MVIEW.EXPLAIN_MVIEW(
    mv => 'SELECT t1.id, t1.name, t2.amount
           FROM table1 t1, table2 t2
           WHERE t1.id = t2.id',
    msg => v_msg
  );
  DBMS_OUTPUT.PUT_LINE(v_msg);
END;
/

-- MV_CAPABILITIES_TABLE 조회로 상세 분석
SELECT capability_name, possible, related_text, msgtxt
FROM mv_capabilities_table
WHERE possible = 'N';

Fast Refresh를 지원하도록 Materialized View를 재생성하는 예제입니다.

-- 기존 Materialized View 삭제
DROP MATERIALIZED VIEW mv_sales_summary;

-- Fast Refresh 가능한 구조로 재생성 (집계 MV 예시)
CREATE MATERIALIZED VIEW mv_sales_summary
BUILD IMMEDIATE
REFRESH FAST ON COMMIT
ENABLE QUERY REWRITE
AS
SELECT
    t.dept_id,
    COUNT(*) AS cnt,
    SUM(t.amount) AS total_amount
FROM sales_table t
GROUP BY t.dept_id;

원인 3 해결: DDL 변경 후 Complete Refresh 수행

-- 현재 Materialized View 상태 및 staleness 확인
SELECT mview_name, refresh_method, last_refresh_type,
       staleness, compile_state
FROM dba_mviews
WHERE mview_name = 'YOUR_MVIEW_NAME';

-- DDL 변경 후 Complete Refresh로 전체 동기화
EXEC DBMS_MVIEW.REFRESH(
    list         => 'YOUR_MVIEW_NAME',
    method       => 'C',
    atomic_refresh => FALSE
);

-- 이후 Fast Refresh 가능 여부 재확인
SELECT mview_name, refresh_method, staleness
FROM dba_mviews
WHERE mview_name = 'YOUR_MVIEW_NAME';

여러 Materialized View 일괄 갱신

-- 의존성 순서를 고려한 그룹 Refresh
EXEC DBMS_MVIEW.REFRESH_ALL_MVIEWS(
    number_of_failures => :n,
    method             => 'F',
    rollback_seg       => '',
    refresh_after_errors => TRUE
);

-- 특정 그룹 Fast Refresh 시도 후 실패 시 Complete Refresh 폴백
BEGIN
  DBMS_MVIEW.REFRESH(
    list           => 'MV_ORDER_SUMMARY',
    method         => 'F',
    atomic_refresh => FALSE
  );
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE('Fast Refresh 실패, Complete Refresh 수행: ' || SQLERRM);
    DBMS_MVIEW.REFRESH(
      list           => 'MV_ORDER_SUMMARY',
      method         => 'C',
      atomic_refresh => FALSE
    );
END;
/

예방 방법

1. Materialized View 설계 단계에서 Fast Refresh 가능성 사전 검증

Materialized View를 실제 생성하기 전에 반드시 DBMS_MVIEW.EXPLAIN_MVIEW 프로시저와 MV_CAPABILITIES_TABLE을 활용하여 Fast Refresh 지원 가능 여부를 확인하는 습관을 가져야 합니다. 또한 Fast Refresh를 지원하는 쿼리 패턴(단순 조인, 집계 함수 사용 시 COUNT(*) 및 SUM 포함 등)을 팀 내 설계 가이드라인으로 문서화하고, DDL 변경 프로세스에 Materialized View 영향도 분석 단계를 반드시 포함시켜야 합니다.

-- MV_CAPABILITIES_TABLE 사전 생성 (한 번만 수행)
@@?/rdbms/admin/utlxmv.sql

-- 설계 검증 프로세스 예시
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('SELECT id, SUM(amount) FROM orders GROUP BY id');
SELECT capability_name, possible, msgtxt
FROM mv_capabilities_table
ORDER BY seq;

2. Materialized View Log 관리 정책 수립 및 모니터링 자동화

Materialized View Log의 크기가 과도하게 증가하면 성능 저하의 원인이 되고, 반대로 Log가 삭제되면 Fast Refresh가 불가능해집니다. 정기적인 Log 크기 모니터링 Job을 구성하고, 베이스 테이블에 DDL이 수행될 경우 사전에 알림을 받을 수 있도록 DDL 트리거 또는 변경 관리 프로세스를 운영하는 것이 중요합니다.

-- Materialized View Log 크기 모니터링 쿼리 (정기 실행 권장)
SELECT l.log_owner, l.master, l.log_table,
       s.blocks * 8 / 1024 AS size_mb,
       l.last_purge_date
FROM dba_mview_logs l
JOIN dba_segments s ON s.segment_name = l.log_table
                   AND s.owner = l.log_owner
ORDER BY s.blocks DESC;