[ORACLE] 11g to 19c Non-CDB 마이그레이션 (expdp/impdp)

Oracle 11g to 19c Non-CDB 마이그레이션 (expdp/impdp) 상세 가이드

이 문서는 Oracle Database 11g에서 19c Non-CDB 환경으로 마이그레이션한 실제 작업 로그를 기반으로, 누락되기 쉬운 사전 점검 사항과 expdp/impdp 기반 마이그레이션 절차, 그리고 SQL*Plus/SQLcl 오류(liquibase 관련) 처리 방법까지 정리한 가이드입니다.

1️⃣ 마이그레이션 시나리오 개요

• 소스 DB: Oracle Database 11g (Non-CDB)
• 타깃 DB: Oracle Database 19c (Non-CDB, 새 인스턴스 MIGRATION)
• 마이그레이션 방식: Data Pump expdp/impdp Full Export/Import
• 특이사항:
  • 11g와 동일한 테이블스페이스 구조를 19c에 미리 생성
  • 19c import 시 여러 개의 error 발생(567개) → 로그 기반 후처리 필요
  • SQLcl 실행 시 liquibase 관련 Java 오류 → 패치 파일에서 JAR 복사로 해결

2️⃣ 사전 점검 – 용량 및 테이블스페이스 구조

✔ 2-1. 11g에서 데이터 사용량 및 파일 크기 확인

SQL> SELECT SUM(bytes)/1024/1024/1024 GB FROM dba_segments;

        GB
----------
1.42681885

SQL> SELECT SUM(bytes)/1024/1024/1024 GB FROM dba_data_files;

        GB
----------
1.49902344

dba_segments 기준은 실제 데이터/세그먼트 사용량, dba_data_files는 데이터파일 전체 사이즈 기준입니다. 타깃 DB(19c)의 데이터 디스크는 최소한 dba_data_files 기준 이상 확보해야 합니다.

✔ 2-2. 11g 테이블스페이스 목록 확인

SQL> SELECT tablespace_name FROM dba_data_files;

TABLESPACE_NAME
------------------------------
USERS
UNDOTBS1
SYSAUX
SYSTEM
JHG_MIGRATION
TEST

6 rows selected.

3️⃣ 19c 타깃 DB 테이블스페이스 정렬

초기 19c는 기본 테이블스페이스만 존재:

SQL> SELECT tablespace_name FROM dba_data_files;

TABLESPACE_NAME
------------------------------
USERS
UNDOTBS1
SYSTEM
SYSAUX

11g와 동일한 구조를 맞추기 위해 19c에 아래 테이블스페이스를 추가 생성합니다.

SQL> CREATE TABLESPACE JHG_MIGRATION
  2    DATAFILE '/oracle/app/oracle/oradata/MIGRATION/jhg_migration.dbf' SIZE 10M;

Tablespace created.

SQL> CREATE TABLESPACE TEST
  2    DATAFILE '/oracle/app/oracle/oradata/MIGRATION/test.dbf' SIZE 10M;

Tablespace created.

SQL> SELECT tablespace_name FROM dba_data_files;

TABLESPACE_NAME
------------------------------
USERS
UNDOTBS1
SYSTEM
SYSAUX
JHG_MIGRATION
TEST

6 rows selected.

주의: Data Pump는 기본적으로 동일한 테이블스페이스명으로 객체를 import하려고 하므로, 소스와 타깃의 테이블스페이스 구성이 최대한 동일해야 에러가 줄어듭니다.

4️⃣ 11g에서 Full Export (expdp)

11g 환경에서 SYSTEM 사용자로 전체(full=y) 백업을 수행합니다.

[orcl11]$ expdp system/manager0 \
  dumpfile=migration.dmp \
  directory=DATAPUMP \
  full=y \
  job_name=a01 \
  logfile=migration.log

Export: Release 11.2.0.4.0 - Production

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
...
Master table "SYSTEM"."A01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.A01 is:
  /home/oracle/backup/11g/migration.dmp
Job "SYSTEM"."A01" successfully completed ...

💡 권장 옵션 (추가 고려)

• consistent=y: 특정 시점 기준으로 정합성 유지
• exclude=statistics: 19c에서 새로 통계 수집 예정이라면 제외 가능
• compression=all: 저장 공간 절감 필요 시

expdp system/manager0 full=y directory=DATAPUMP \
 dumpfile=migration.dmp logfile=migration.log \
 consistent=y

5️⃣ 19c에서 Import 준비 및 Full Import (impdp)

✔ 5-1. 19c에서 DATAPUMP 디렉터리 생성

SQL> CREATE OR REPLACE DIRECTORY DATAPUMP AS '/home/oracle/backup/migration/';

Directory created.

expdp에서 생성된 덤프 파일을 복사:

[migration]$ cp /home/oracle/backup/11g/migration.dmp \
  /home/oracle/backup/migration/

✔ 5-2. 19c에서 impdp 실행

[migration]$ impdp system/manager0 \
  full=y \
  directory=DATAPUMP \
  file=migration.dmp \
  job_name=a01 \
  logfile=migration.log

Import: Release 19.0.0.0.0 - Production
Version 19.14.0.0.0

Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Legacy Mode Active due to the following parameters:
Legacy Mode Parameter: "file=migration.dmp"
Location: Command Line, Replaced with: "dumpfile=migration.dmp"
...
Job "SYSTEM"."A01" completed with 567 error(s) ...

Legacy Mode 메시지는 10g/11g 스타일의 파라미터(file=)를 사용했기 때문에 출력되는 것으로, dumpfile=로 변경하면 표시되지 않습니다.

✔ 5-3. impdp 에러(567건)에 대한 해석

Full import 시 아래 유형의 에러가 다수 발생할 수 있습니다.

• 이미 존재하는 사용자/롤/프로파일에 대한 ORA-01920/01921/01922
• 버전/옵션 차이로 인한 DBMS_JOB, DBMS_SCHEDULER 관련 오류
• 네트워크 ACL, 디렉터리 객체, 외부 테이블 등 환경 의존 객체
• 내장 계정(EXP_FULL_DATABASE, IMP_FULL_DATABASE 등) 재생성 오류

migration.log 파일에서 ORA- 에러만 grep하여, 실제로 치명적인 객체(업무 스키마, 주요 뷰/프로시저) 관련 에러가 있는지 반드시 별도 분석해야 합니다.

grep "ORA-" migration.log | sort | uniq -c

6️⃣ 19c SQL*Plus/SQLcl liquibase 오류 해결

19c 환경에서 sql 실행 시 아래와 같은 Java 오류가 발생했습니다. 이는 19c 클라이언트(SQLcl/SQL Developer 통합 구성)와 관련된 의존성(JAR) 부족 문제입니다.

Exception in thread "main" java.util.ServiceConfigurationError:
 oracle.dbtools.extension.SQLCLService: Provider
 oracle.dbtools.raptor.scriptrunner.commands.liquibase.liquibaseCommand
 could not be instantiated
...
Caused by: java.lang.NoClassDefFoundError: liquibase/exception/DatabaseException
...
Caused by: java.lang.ClassNotFoundException: liquibase.exception.DatabaseException

✔ 6-1. 패치 디렉터리에서 liquibase-core.jar 복사

패치 적용 시 생성된 .patch_storage 내의 파일을 활용:

cd /oracle/app/oracle/product/19c/.patch_storage/33515361_Jan_13_2022_06_14_07/files/sqldeveloper/sqldeveloper/lib/ext

cp liquibase-core.jar $ORACLE_HOME/sqldeveloper/sqldeveloper/lib/ext

ls $ORACLE_HOME/sqldeveloper/sqldeveloper/lib/ext/liquibase-core.jar
/oracle/app/oracle/product/19c/sqldeveloper/sqldeveloper/lib/ext/liquibase-core.jar

✔ 6-2. jackson-databind.jar 복사

cd /oracle/app/oracle/product/19c/.patch_storage/33515361_Jan_13_2022_06_14_07/files/sqldeveloper/sqldeveloper/lib

cp jackson-databind.jar $ORACLE_HOME/sqldeveloper/sqldeveloper/lib/

ls -l $ORACLE_HOME/sqldeveloper/sqldeveloper/lib/jackson-databind.jar
-rw-r--r-- 1 oracle dba 1346966 ... jackson-databind.jar

이후 sql 실행:

[migration]$ sql

SQL*Plus: Release 19.0.0.0.0 - Production
Version 19.14.0.0.0

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.14.0.0.0

이 문제는 DB 자체의 마이그레이션 오류가 아니라, 19c 클라이언트 도구(SQLcl/SQL Developer 통합)에서 liquibase 관련 JAR을 찾지 못해 발생한 것으로, 패치 디렉터리에서 JAR 파일을 복사하여 해결했습니다.

7️⃣ 마이그레이션 후 검증 체크리스트

✔ 7-1. 객체 수 검증

-- 11g / 19c 양쪽에서 비교
SELECT owner, COUNT(*) obj_cnt
  FROM dba_objects
 WHERE owner IN ('업무스키마명1','업무스키마명2')
 GROUP BY owner
 ORDER BY owner;

✔ 7-2. INVALID 객체 확인

SELECT owner, object_name, object_type, status
  FROM dba_objects
 WHERE status = 'INVALID'
 ORDER BY owner, object_type, object_name;

필요 시 utlrp.sql 실행으로 재컴파일:

SQL> @?/rdbms/admin/utlrp.sql

✔ 7-3. 주요 컴포넌트 상태 확인

SELECT comp_name, version, status
  FROM dba_registry
 ORDER BY comp_name;

✔ 7-4. 통계 재수집(옵션)

EXEC DBMS_STATS.GATHER_DATABASE_STATS(
  estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
  cascade          => TRUE
);

7️⃣ 기본 오류 대응 4단계 (마이그레이션 관점)

① 외부 노출 확인
expdp/impdp 로그에서 ORA- 에러 유형을 분류하고, 실제 업무 스키마/객체에 영향이 있는지 먼저 확인합니다.

② 관련 기능 비활성화
마이그레이션 중에는 소스(11g)에서 대량 DML/스케줄러 잡이 동작하지 않도록 통제하여 데이터 불일치를 방지합니다.

③ 포트·프로세스 차단
마이그레이션 기간에는 애플리케이션이 19c로 접속하지 못하도록 리스너/방화벽을 임시 차단하고, 검증 완료 후에만 신규 DB를 서비스에 연결합니다.

④ 로그 모니터링 강화
expdp/impdp 로그, alert.log, listener.log를 집중적으로 모니터링하며, ORA-00600/ORA-07445와 같은 심각 오류가 없는지 확인합니다.

8️⃣ 정리 및 권장 사항

이 11g → 19c Non-CDB 마이그레이션 사례는 expdp/impdp Full 방식을 사용했지만, 실제 운영 환경에서는 다음과 같은 추가 사항도 함께 고려하는 것이 좋습니다.

• 다운타임 최소화를 위한 증분 전략(사전 full export + 최종 cutover export)
• 캐릭터셋/타임존 버전 차이 점검
• 데이터베이스 링크(DB Link), 외부 테이블, UTL_FILE 디렉터리 등 환경 의존 요소 재구성
• 애플리케이션 호환성(드라이버 버전, JDBC URL, NLS 설정) 검증

특히 impdp 과정에서 발생한 567건의 에러는 모두 치명적일 필요는 없지만, 반드시 로그를 기준으로 유형을 분류하고, 업무 영향이 있는 에러는 별도 조치를 해야 마이그레이션 이후에도 안정적인 운영을 보장할 수 있습니다.