이기종 DB 전환
상용 DB 에서 오픈소스 DB 로 스키마·코드·데이터를 전환합니다.
- Oracle → PostgreSQL
- Tibero → PostgreSQL
- SQL Server → PostgreSQL / MySQL
- Oracle → MySQL / MariaDB
Scenarios
이행 시나리오
온프레미스 → 클라우드
자체 구축 DB 를 클라우드 VM 또는 관리형 DB 로 옮깁니다.
- RDS · Aurora
- Azure flexible server
- Cloud SQL · AlloyDB
- NCP Cloud DB
동종 이전·업그레이드
같은 엔진의 메이저 버전 업그레이드와 서버 이전을 수행합니다.
- PostgreSQL 메이저 업그레이드
- MySQL 5.7 → 8.x
- MariaDB LTS 전환
- InfluxDB 버전 전환 검토
통합·분리
여러 DB 를 통합하거나 업무 단위로 분리합니다.
- 스키마 통합
- 업무 도메인 분리
- 읽기 전용 분석 복제
- 아카이브 분리
Methodology
7단계 이행 방법론
각 단계는 산출물과 다음 단계로 넘어가는 기준(게이트)을 가집니다.
1. 진단 (Assessment)
객체·데이터량·트랜잭션 패턴·의존 애플리케이션을 조사하고 자동 변환률과 수작업 범위를 추정합니다.
2. 설계 (Design)
타깃 아키텍처, 데이터 타입 매핑, 문자셋, 이행 방식(일괄/CDC), 다운타임 목표를 정합니다.
3. 변환 (Conversion)
스키마·PL/SQL·뷰·트리거·시퀀스를 변환하고 애플리케이션 SQL 수정 범위를 확정합니다.
4. 이행 (Migration)
초기 적재 후 CDC 로 변경분을 따라잡으며, 리허설로 소요 시간을 실측합니다.
5. 검증 (Verification)
건수·체크섬·집계·업무 쿼리 결과를 비교하고 성능 테스트를 수행합니다.
6. 컷오버 (Cutover)
쓰기 중지 → 최종 동기화 → 검증 → 연결 전환 순서로 진행하고 Go/No-Go 를 판정합니다.
7. 안정화 (Stabilization)
전환 직후 성능·오류를 집중 모니터링하고 튜닝 후 운영 조직에 인계합니다.
Migration flow
이행 흐름
Oracle · Tibero원천
SQL Server원천
MySQL · PostgreSQL온프레미스
변환 · 적재
스키마 변환ora2pg · DMS SC · SCT · DMS 변환 작업공간
초기 적재pgloader · mydumper · DMS full load
변경분 동기화
CDC 동기화Debezium · DMS CDC · 네이티브 복제
GoldenGate기존 보유 시 원천 측 CDC
컷오버
PostgreSQL · MySQL · MariaDBVM / 온프레미스
관리형 DBRDS · Aurora · flexible server · Cloud SQL · AlloyDB · Cloud DB
정합성 검증성능 테스트롤백 경로 유지
Tools
이행 도구
도구는 목적에 맞게 조합하며, 특정 도구를 전제로 하지 않습니다.
| 도구 | 용도 | 참고 |
|---|---|---|
| ora2pg | Oracle → PostgreSQL 스키마·코드·데이터 변환 | 오픈소스 · 변환 리포트로 난이도 산정 |
| AWS DMS · DMS Schema Conversion · AWS SCT | AWS 로의 이기종/동종 이행, 전체 적재 + CDC | SCT 는 데스크톱 도구, DMS SC 는 관리형 |
| Azure Database Migration Service | MySQL → Azure Database for MySQL 등 | Oracle → PostgreSQL 은 미지원 — ora2pg 등 사용 |
| Migration service in Azure Database for PostgreSQL | PostgreSQL → Azure flexible server | 온라인/오프라인 이행 |
| Google Database Migration Service | MySQL·PostgreSQL 동종, Oracle·SQL Server → Cloud SQL for PostgreSQL / AlloyDB | 변환 작업공간 · CDC |
| NCP Database Migration Service | 네이버클라우드 Cloud DB 로의 이행 | 지원 경로는 공식 문서 확인 |
| pgloader | MySQL·SQL Server 등 → PostgreSQL 적재 | 타입 변환 규칙 지정 |
| mysqldump · mydumper/myloader | MySQL·MariaDB 논리 백업·병렬 적재 | 대용량은 mydumper 병렬화 |
| Debezium (CDC) | 변경 데이터 캡처 → Kafka 기반 동기화 | 최소 다운타임·병행 운영 |
| Oracle GoldenGate | 원천 측 CDC (고객이 이미 보유한 경우) | 라이선스는 고객 보유분 기준 |
Tibero 는 Oracle 호환 DBMS 이지만 ora2pg 의 공식 지원 대상이 아닙니다. 접속 방식·변환 범위는 고객 환경에서 PoC 로 먼저 확인하며, 자동 변환되지 않는 객체는 수작업 변환 목록으로 관리합니다.
Validation
정합성 검증
“옮겼다”가 아니라 “같다”를 증명합니다.
- 테이블별 건수 비교
- 청크 단위 체크섬·해시 비교
- 합계·최소·최대 등 집계 비교
- 업무 핵심 쿼리 결과 비교
- 제약조건·인덱스·시퀀스 현재값 확인
- 문자셋 전환(예: KO16MSWIN949·EUC-KR → UTF-8) 손실 점검
- 날짜·시간대·숫자 정밀도 차이 점검
- Oracle 의 빈 문자열(NULL 취급) 차이 처리
- LOB·바이너리 데이터 검증
- 성능 기준선 대비 응답 시간 비교
Downtime & rollback
최소 다운타임과 롤백 계획
다운타임 최소화
- 초기 적재 + CDC 로 컷오버 시점에는 변경분만 반영
- 업무 도메인별 단계 이행
- 컷오버 리허설로 소요 시간 실측
- 읽기 전용 전환 구간을 사전 공지
롤백 계획
- 원천 DB 는 컷오버 후에도 일정 기간 보존
- 필요 시 역방향 복제로 원천 동기화 유지
- Go/No-Go 판정 기준과 의사결정자 사전 지정
- 되돌릴 수 없는 시점(Point of no return)을 문서화
Deliverables
산출물
- 현황 진단 보고서(변환 난이도·위험)
- 데이터 타입·객체 매핑 정의서
- 변환 결과·수작업 목록
- 이행 런북(단계별 명령·소요 시간)
- 정합성 검증 보고서
- 컷오버·롤백 계획서
- 성능 테스트 결과
- 운영 인계 문서
FAQ
자주 묻는 질문
다운타임 없이 이행할 수 있나요?
대부분 CDC 로 다운타임을 크게 줄일 수 있지만, 최종 동기화와 연결 전환을 위한 짧은 쓰기 중지 구간은 일반적으로 필요합니다. 목표 시간은 리허설 결과로 확정합니다.
PL/SQL 이 많은데 전환이 가능한가요?
진단 단계에서 ora2pg 등의 리포트로 자동 변환 가능 범위와 수작업 범위를 먼저 산정하고, 그 결과로 일정과 비용을 정합니다.
Tibero 도 지원하나요?
Tibero 는 Oracle 호환 DBMS 이지만 ora2pg 의 공식 지원 대상이 아닙니다. 접속 방식·변환 범위는 고객 환경에서 PoC 로 먼저 확인하며, 자동 변환되지 않는 객체는 수작업 변환 목록으로 관리합니다.
클라우드 이행 후 운영도 맡길 수 있나요?
네. 클라우드 MSP 와 오픈소스 DB 유지보수로 이어서 운영할 수 있습니다.
클라우드와 데이터베이스, 지금 상태부터 함께 점검해 보시겠어요?
사용 중인 클라우드·DB 버전·구성과 고민을 알려주시면 진단 범위와 진행 방식을 제안드립니다.