1. 마이그레이션 간 발생한 핵심 문제
CSV 사용의 리스크
MySQL에서 Oracle로 마이그레이션을 진행할 때, 가장 먼저 대규모 데이터 이동을 위해 CSV(Comma Separated Values)를 중간 포맷으로 사용하는 것을 고려했습니다.
하지만 TEXT (VARCHAR 이상의 대용량 텍스트)나 BLOB (Binary Large Object) 컬럼을 확인하는 순간, CSV 방식의 위험을 직감했습니다.
| 컬럼 유형 | CSV 사용 시 발생 가능한 문제점 |
|---|---|
| TEXT (CLOB) | 텍스트 내부에 포함된 쉼표나 줄 바꿈 문자가 CSV의 필드/레코드 구분자와 충돌하여 데이터 로드 시 행/컬럼 구조가 완전히 깨집니다. |
| 인코딩 문제도 복합적으로 발생합니다. | |
| BLOB (Binary) | 이진 데이터를 텍스트 기반인 CSV에 직접 저장하려면 Base64 등으로 인코딩해야 합니다. |
| 이 과정은 파일 크기를 33% 이상 증가시키고, 인코딩/디코딩 단계가 추가되어 마이그레이션 시간이 크게 늘어나며 데이터 손상 위험도 커집니다. |
2. 데이터 안정을 위해 고민한것
CSV를 대체할 방안을 찾으면서 다음 세 가지 방법을 놓고 고민했습니다.
MySQL Dump 파일 사용
-
장점: SQL 구문으로 데이터를 추출하므로 텍스트 인코딩이나 구분자 충돌 문제에서 자유로울 수 있었습니다.
mysqldump의--hex-blob옵션을 사용하면 BLOB 데이터도 16진수 문자열로 안전하게 변환됩니다. -
단점: 파일 크기가 매우 커지고, Oracle에서 이 덤프 파일을 실행하는 데 시간이 매우 오래 걸릴 수 있습니다.
또한, MySQL의 데이터 타입을 Oracle의 타입에 맞게 수동으로 치환하는 추가 작업이 필요했습니다.
프로그래밍 Java을 통한 직접 연결
-
장점: MySQL에서 데이터를 읽어와 Oracle에 실시간으로 삽입하는 방식입니다.
데이터 변환 로직을 가장 세밀하게 제어할 수 있습니다. -
단점: 구현에 많은 시간과 노력이 들고, 네트워크 지연에 취약하며, 대용량 데이터 처리 시 메모리 누수나 성능 최적화 문제가 발생할 수 있습니다.
전용 마이그레이션 툴사용
-
장점: 두 DB 간의 접속과 타입 매핑을 자동화해 줍니다.
특히 TEXT/BLOB 데이터를 JDBC를 통해 이진 스트림 형태로 직접 전송하므로 중간 포맷으로 인한 손실 위험이 거의 없습니다. -
단점: 도구 설치 및 설정 과정, 그리고 마이그레이션 리포지토리라는 별도의 Oracle 스키마 설정이 필요했습니다.
SQL Developer Migration Workbench 선택
안전성, 효율성, 그리고 자동화 수준을 종합적으로 고려하여 Oracle SQL Developer Migration Workbench를 최종 해결책으로 선택했습니다.
특히 TEXT/BLOB 컬럼을 다루는 데 있어 가장 안정적인 방법이라고 판단했습니다.
TEXT/BLOB 처리 핵심 원리
SQL Developer는 CSV처럼 데이터를 텍스트 파일로 추출하는 대신, 다음과 같은 방식으로 처리합니다.
- JDBC 연결: MySQL과 Oracle에 대한 JDBC 연결을 모두 설정합니다.
- 자동 타입 매핑: MySQL의
TEXT,MEDIUMTEXT등은 Oracle의 CLOB으로, MySQL의BLOB,MEDIUMBLOB등은 Oracle의 BLOB으로 자동으로 매핑합니다. - 스트리밍 전송: 데이터 이동 단계에서 JDBC를 통해 이진 데이터 스트림 형태로 데이터를 읽어와 변환 없이 대상 Oracle LOB 컬럼에 직접 삽입합니다.
이로써 인코딩 문제나 구분자 충돌 문제 자체가 원천적으로 제거됩니다.
실제 구현 단계 요약
- 환경 설정: Oracle SQL Developer 설치 후, MySQL Connector/J 드라이버 추가.
- 마이그레이션 리포지토리: 대상 Oracle DB에 마이그레이션 진행 상황을 저장할 리포지토리 스키마 생성.
- 캡처 및 변환: MySQL 스키마를 캡처한 후, Oracle 모델로 변환.
- 데이터 이동:
Move Data기능을 사용하여 LOB 데이터를 포함한 모든 데이터를 스트림 방식으로 안전하게 전송.
4. 마이그레이션을 마치고 느낀 점
4-1. 전용 도구의 가치
대규모 이기종 DB 마이그레이션에서는 CSV나 단순 SQL 덤프와 같은 범용적인 방법보다 전용 도구를 사용하는 것이 압도적으로 효율적이고 안전했습니다.
특히 LOB 데이터와 같은 복잡한 타입은 도구의 자동화된 스트리밍 기능 없이는 오류 발생 확률이 매우 높습니다.
4-2. LOB 컬럼의 재정의
MySQL의 TEXT나 BLOB는 내부적으로 Oracle의 LOB 타입으로 간주되어야 합니다.
마이그레이션은 단순히 데이터 값을 옮기는 것이 아니라, 원본의 TEXT가 Oracle의 CLOB가 되어 새로운 환경의 규칙을 따르게 된다는 것을 명확히 이해해야 합니다.
4-3. 마이그레이션은 '자동화 + 수동 검증'의 조화
SQL Developer가 대부분의 작업을 자동화했지만, 마이그레이션 후 가장 큰 LOB 데이터를 가진 레코드 몇 개를 수동으로 비교하고 쿼리하여 데이터 무결성을 최종적으로 검증하는 과정은 생략할 수 없었습니다.
자동화된 도구를 신뢰하되, 핵심 데이터는 반드시 수동으로 확인하는 하이브리드 검증이 성공의 열쇠였습니다.
