Oracle 19c Data Pump로 스키마 단위 이관하기, 설계와 현장 포인트

언제 Data Pump를 선택하는가

Oracle DB를 클라우드 VM 등으로 옮기는 방법은 크게 세 가지입니다. RMAN(물리적 복제), Data Pump(논리적 추출·적재), SQL 파일(텍스트 기반)이죠. RMAN은 DB 전체를 블록 단위로 복사하므로 가장 빠르고 완전합니다. 같은 버전 DB를 통째로 옮길 때 최선입니다.

그러나 RMAN이 적합하지 않은 상황이 있습니다.

• 특정 스키마(사용자)만 선택적으로 이관해야 할 때

• 소스와 타깃의 Oracle 버전이 다를 때(예: 11g에서 19c로)

• 기존 백업 파일이 손상되어 물리 복원이 불가능할 때

• 이관 과정에서 스키마 이름이나 테이블스페이스를 변경해야 할 때

이런 상황에서 Data Pump(expdp/impdp)가 대안이 됩니다. DB의 논리적 구조(테이블 정의, 데이터, 인덱스, 제약조건, 프로시저 등)를 덤프 파일(.dmp)로 추출하고 타깃에서 재적재하는 방식입니다.

Data Pump의 핵심 개념 4가지

처음 접할 때 알아야 할 개념이 넷 있습니다.

DIRECTORY는 다음처럼 만들고 권한을 부여합니다. CREATE OR REPLACE DIRECTORY MIGRATION_PUMP_DIR AS '/u01/app/oracle/admin/ORCL/dpdump'; 그리고 GRANT READ, WRITE ON DIRECTORY MIGRATION_PUMP_DIR TO SAMPLE; 이 권한이 없으면 expdp/impdp가 파일을 읽거나 쓸 수 없습니다.

소스에서 export — 경로 불일치부터 막는다

소스 작업은 "DIRECTORY 준비 → expdp 실행 → 결과 점검" 세 단계입니다.

현장에서 자주 나는 사고가 DIRECTORY 이름은 같지만 OS 경로가 다른 상황입니다. 이전 작업에서 같은 이름을 다른 경로로 만들어 두면, 덤프가 "엉뚱한 곳"에 생성됩니다. 그래서 먼저 DBA_DIRECTORIES를 조회해 존재 여부와 경로 일치를 확인하고, 어긋나면 올바른 경로로 재생성합니다.

expdp parfile은 보통 이렇게 구성합니다.

PDB(멀티테넌트) 환경에서는 서비스명으로 대상 PDB를 지정합니다. expdp가 끝나면 로그에서 ORA- 패턴을 자동 스캔해, 로그 전체를 열지 않아도 문제의 성격을 빠르게 파악하도록 설계해 두면 좋습니다.

타깃에서 import — REPLACE와 종료 코드

타깃 작업은 "DIRECTORY 준비 → impdp 실행 → invalid 오브젝트 재컴파일 → 결과 점검" 네 단계입니다. 한 가지 주의점은, 이관 대상 스키마(사용자)가 타깃에 아직 없을 수 있다는 점입니다. DBA_USERS로 존재 여부를 먼저 확인하고, 없으면 사용자·테이블스페이스 복원 스크립트를 먼저 실행한 뒤 다시 돌립니다.

impdp parfile의 핵심은 TABLE_EXISTS_ACTION=REPLACE입니다. 동일 테이블이 있으면 DROP 후 재생성해 완전 교체하므로, 재실행 시에도 동일한 결과를 보장하는 멱등성(idempotency)이 확보됩니다. 스키마 이름이나 테이블스페이스를 바꿔야 하면 REMAP_SCHEMA=원본:대상, REMAP_TABLESPACE=원본:대상을 더합니다.

그리고 운영자가 가장 자주 오해하는 부분이 종료 코드입니다. Oracle 공식 문서(Data Pump Process Exit Codes) 기준으로 세 가지입니다.

흔한 실수는 코드 5를 실패로 판단하고 불필요하게 재작업하는 것입니다. 코드 5의 ORA- 내용은 대부분 이미 존재하는 오브젝트나 통계 관련 경고입니다. 실제 실패로 처리해야 하는 것은 코드 1뿐이고, 코드 5는 로그를 보고 영향도를 판단하면 됩니다.

import 후에는 일부 오브젝트가 INVALID가 될 수 있습니다. 뷰·프로시저·패키지가 참조 대상의 생성 순서 때문에 컴파일되지 않은 것이죠. Oracle이 공식 제공하는 UTL_RECOMP.RECOMP_SERIAL을 실행하면 invalid 오브젝트를 일괄 재컴파일합니다. 스키마 단위 또는 전체 단위로 실행할 수 있습니다.

TABLE_EXISTS_ACTION=REPLACE를 선택한 이유

타깃 import에서 이 옵션 선택이 운영 전환의 안전성을 좌우합니다. Oracle 문서 기준 네 가지가 있고 기본값은 SKIP입니다.

REPLACE를 선택하는 이유는 셋입니다. 첫째, 재실행이 안전합니다. 테스트를 반복하거나 본 이관 중 문제로 다시 돌려야 할 때 동일한 결과가 보장됩니다. 둘째, 트리거 발화를 방지합니다. Oracle 문서에 따르면 REPLACE는 테이블을 새로 생성한 뒤 데이터를 로드하고, 트리거 같은 종속 오브젝트는 그 후에 생성합니다. 따라서 로딩 중에는 INSERT 트리거가 발화하지 않는다고 볼 수 있습니다. 셋째, 깔끔한 상태를 보장합니다. 소스에서 삭제된 컬럼이나 변경된 구조가 타깃에 남는 문제를 원천 차단합니다.

다만 REPLACE는 FK(외래키) 참조 대상 테이블에 쓸 때 주의가 필요합니다. 참조되는 테이블이 DROP되면 참조하는 테이블의 FK도 영향을 받을 수 있습니다.

검증 — "옮겼다"가 아니라 "소스와 같다"

이관은 옮겼다고 끝나지 않습니다. 소스와 같다를 증명해야 운영 전환이 안전합니다. 소스·타깃 각각에서 동일한 수집 스크립트를 돌리고 비교 리포트를 만듭니다.

각 항목에 PASS/FAIL을 표시하고, CRITICAL 실패가 하나라도 있으면 전체를 실패로 판정합니다. 이 기준이 있어야 "감으로 괜찮아 보인다"가 아니라 "수치로 같다"를 말할 수 있습니다.

RMAN · Data Pump · SQL 파일, 무엇을 언제

세 방식 모두 OS 설정 파일(sqlnet.ora·listener.ora 등)은 포함하지 않으므로 별도로 관리해야 합니다.

자주 하는 실수

• DIRECTORY 경로 불일치 — 이름은 같고 OS 경로가 다른 경우. 덤프가 엉뚱한 위치에 생겨 "파일이 없다"로 나타납니다. DBA_DIRECTORIES로 경로를 반드시 확인하세요.

• DIRECTORY 권한 누락 — READ/WRITE를 부여하지 않으면 ORA-39070(로그·덤프 파일 열기 불가) 같은 에러로 나타납니다. ORA-39002가 함께 뜨기도 하지만, 디렉터리 경로·권한 문제의 직접 신호는 ORA-39070·ORA-29283 쪽입니다.

• 종료 코드 5를 실패로 오해 — 코드 5는 "완료됐지만 에러가 있었음"입니다. 대부분 기존 오브젝트·통계 경고이고, 실제 실패는 코드 1뿐입니다.

• invalid 오브젝트 방치 — import 후 INVALID 상태를 재컴파일하지 않으면 호출 애플리케이션에서 런타임 에러가 납니다. UTL_RECOMP.RECOMP_SERIAL로 일괄 해결하세요.

• TABLE_EXISTS_ACTION 미지정 — 기본값 SKIP이라 기존 테이블이 있으면 아무것도 안 합니다. 재이관 시 데이터가 갱신되지 않는 원인이 되니 의도에 맞는 ACTION을 명시하세요.

이것만 기억하세요

자주 묻는 질문 (FAQ)