콘텐츠로 이동
≡

Administrator

Developer

Tools

External Tools

5. Migration Center 내부#

이 장은 Migration Center의 주요 단계인 구축, 조정, 실행 및 검증 단계에 대해 상세히 설명한다. 이 장은 아래의 절을 포함한다:

  • 구축 단계
  • 조정 단계
  • 실행 단계
  • 검증 단계

구축 단계#

목적#

구축 단계는 원본 및 대상 데이터베이스로부터 데이터베이스 객체에 대한 정보를 수집할 뿐만 아니라, 사용자에게 구축 보고서를 제공하여 마이그레이션을 좀 더 적절히 수행할 수 있도록 한다. 보고서는 원본 및 대상 데이터베이스의 마이그레이션 가능한 객체를 바이트 크기 정보와 함께 나열한다. 이 정보는 사용자에게 마이그레이션 분량에 관한 몇 가지 아이디어를 제공하여, 마이그레이션에 소요될 저장 공간 및 시간을 추정하는데 도움을 줄 것이다.

이 단계에서 모은 정보는 전체 마이그레이션에 걸쳐 사용될 것이다. 또한 이는 원본 및 대상 데이터베이스의 현재 상태를 반영하고 있어야 한다. 구축 단계 이후 원본 데이터베이스의 데이터베이스 객체에 변경이 발생했다면, 모든 단계가 재실행 되어야 한다.

출력#

구축 단계에서 생성되는 파일들을 소개한다.

  • 구축 보고서
    프로젝트 폴더에 HTML 형식으로 원본 및 대상 데이터베이스의 현재 상태에 기반한 다수의 저장 공간 분석 보고서가 출력된다.
  • SQL 데이터 정의어(DDL) 스크립트
    Migration Center의 지원 여부와 상관없이 원본 데이터베이스에서 수집한 데이터베이스 객체 생성문(DDL)을 저장한 파일로, 프로젝트 폴더에 생성되며 파일의 이름은 SrcDbObj_Create.sql이다. 이 파일은 필요시 사용자가 참고하도록 제공하는 것일 뿐 Migration Center의 어느 단계에서도 사용되지 않는다.
  • BuildReport4Unsupported.html
    구축(Build) 결과를 요약한 파일 중 하나로, Migration Center에서 지원하지 않는 객체의 생성 문장이 기록된다. Migration Center에서 지원하지 않는 객체는 사용자가 직접 수동으로 변환해야 하는데, 이 파일을 변환 작업에 참고할 수 있다.
    지원하지 않는 객체는 원본 데이터베이스에 따라 다르며 부록 B. 마이그레이션 가능한 데이터베이스 객체에서 확인할 수 있다. Oracle의 모든 객체는 Migration Center로 마이그레이션이 가능하기 때문에 이 파일이 생성되지 않는다. 반면, MySQL의 저장 프로시저, 저장 함수, 뷰, 트리거 객체와 같이 지원하지 않는 객체가 있으면 이 파일이 생성된다.

내부 동작#

구축 단계는 내부적으로 원본 및 대상 데이터베이스의 객체 정보를 수집하는 단계와 그 결과에 대한 보고서를 생성하는 단계로 구분된다.

객체 정보를 수집하는 방법은 "Build User" 또는 "Build Table" 중에서 선택할 수 있다.

  • Build User
    원본 데이터베이스에 접속한 사용자의 이관 가능한 모든 객체 정보를 수집한다.
  • Build Table
    원본 데이터베이스에 접속한 사용자의 테이블들로부터 이관할 테이블 목록을 직접 구성한다. 선택된 테이블과 그에 종속된 제약 조건 및 인덱스의 객체 정보를 수집한다.

이관 가능한 객체 타입에 대한 자세한 정보는 "B.부록: 마이그레이션 가능한 데이터베이스 객체"를 참고한다.

구축 단계를 시작하면, 테이블의 레코드 개수를 수집하는 방법을 결정할 "Table Counting Method" 대화상자가 나타난다. 사용자는 다음 중 한 가지 방법을 선택할 수 있다.

  • Approximate Counting Method
    원본 데이터베이스의 통계값을 참조하여 테이블의 레코드 개수를 가져온다. 통계값의 정확도에 따라 레코드 개수의 정확도가 달라진다.
  • Exact Counting Method
    원본 데이터베이스의 모든 테이블을 대상으로 count 함수를 수행하여 정확한 테이블의 레코드 개수를 가져온다.

두 가지 방법 중에 "Approximate Counting Method"가 "Exact Counting Method"보다 빠르지만, 보다 정확한 테이블 레코드 개수를 수집하려면 후자를 선택하는 것이 좋다. 하지만 사용자가 이 대화상자에서 어떤 방법을 선택하더라도 데이터베이스 스키마와 데이터 마이그레이션에는 전혀 영향을 미치지 않는다. 다만 Migration Center GUI 모드의 실행 단계에서 제공되는 데이터 마이그레이션 진행률의 정확도에만 영향을 미친다. 이는 데이터 마이그레이션 진행률이 경과된 시간과 함께 (이전된 레코드 개수/수집된 전체 레코드 개수) 백분율로 표시되기 때문이다. 사용자는 이 데이터를 기반으로 마이그레이션에 소요될 전체 시간을 추정할 수 있다.

구축 단계를 수행하는 방법은 3장에서 "프로젝트 구축" 절을 참고하도록 한다.


조정 단계#

목적#

조정 단계는 마이그레이션 계획을 구성하는 단계를 의미한다. Migration Center 사용자는 각 데이터베이스의 객체를 어떻게 마이그레이션 할 것인지 계획을 가지고 있어야 한다. Migration Center는 모든 데이터베이스 객체를 Altibase로 마이그레이션할 수 없지만, 마이그레이션에 대한 모든 제어를 허용하여 쉽게 마이그레이션을 할 수 있도록 해준다.

Altibase는 인-메모리 데이터베이스로서의 고성능과 디스크 기반 데이터베이스로서의 대용량의 이점을 가지고 있다. 따라서 Altibase의 일반적인 사용 전략은 빈번히 사용되며 낮은 대기 시간이 요구되는 데이터를 메모리 테이블스페이스에 저장하고, 나머지 데이터를 디스크 테이블스페이스에 저장한다.

Altibase의 테이블스페이스에 대한 자세한 내용은 각각의 Administrator's Manual을 참고한다.

출력#

  • 조정 보고서: 프로젝트 폴더에 마이그레이션 할 데이터베이스 객체 및 마이그레이션 하는 방법을 명시하는 다수의 보고서가 출력된다.
  • SQL 데이터 정의어(DDL) 스크립트: 사용자 편의를 위해, 프로젝트 폴더에 대상 데이터베이스에 데이터베이스 객체를 생성하고 삭제하는 샘플 SQL 스크립트 파일이 출력된다. 그러나 이 파일들은 Migration Center의 어느 단계에서도 사용되지 않는다.
  • DbObj_Create.sql: 마이그레이션 될 데이터베이스 객체를 생성하는 SQL 스크립트 파일
  • DbObj_Drop.sql: 마이그레이션 될 데이터베이스 객체를 삭제하는 SQL 스크립트 파일
  • PL/SQL 변환 보고서: PL/SQL 변환기에서 출력하는 다수의 보고서이다.
  • sqlconv.html: 원본과 변환된 PL/SQL의 차이를 비교하는 HTML 형식의 보고서
  • sqlconv_src.sql: 입력된 PL/SQL문을 텍스트 형식으로 출력하는 보고서
  • sqlconv_dest.sql: 변환된 PL/SQL문과 적용된 규칙이 코멘트로 덧붙여져 있는 텍스트 형식의 보고서

내부 동작#

조정 단계는 매우 중요하고 복잡해질 수 있음에도 불구하고, 그 위저드는 UI처럼 따라가기에 쉽다. 조정 단계를 시작하는 방법은 3장에서 "프로젝트 조정" 절을 참고하기 바란다.

조정 위저드 대화 상자#

사용자는 위저드에서 기본 설정을 확인하고 수정할 수 있다. 이것은 사용자에게 각 메뉴 항목을 순차적으로 안내하지만, 사용자가 왼쪽 창에서 선택하여 특정 메뉴 아이템으로 이동할 수도 있다.

"Data Type Mapping" 단계#

"Data Type Mapping" 단계에서는 이기종 데이터베이스 간의 데이터 타입을 매핑할 수 있다. 데이터 타입의 작은 차이는 데이터를 마이그레이션 하는 동안 예기치 못한 데이터 손실 및 데이터 절단을 일으킬 수 있다. 따라서, 사용자는 이를 주의해야 한다. 더 자세한 내용은 "C. 부록: 데이터 타입 매핑"을 참고한다.

"PSM Data Type Mapping" 단계#

"PSM Data Type Mapping" 단계에서는 서로 다른 데이터베이스 간의 PSM 데이터 타입을 매핑할 수 있다. 이 단계는 "Oracle to Altibase PSM Migration" 또는 "TimesTen to Altibase PSM Migration" 수행시에만 활성화 된다. 이 단계에서 정의된 내용은 나중에 PSM 마이그레이션의 "SQL Editing" 단계에서 대상 DDL에 반영될 것이다.

"Tablespace to Tablespace Mapping" 단계#

"Tablespace to Tablespace Mapping" 단계에서는 원본 및 대상 데이터베이스 간의 테이블스페이스를 매핑할 수 있다. 테이블스페이스 매핑이 설정되면, 테이블스페이스의 내용물 또한 선택된 테이블스페이스로 모두 함께 매핑된다. 이 단계는 기본 테이블스페이스 매핑을 생성하는데, 이 매핑은 "Object to Tablespace Mapping" 메뉴 항목을 사용해서 변경할 수 있다.

"Object to Tablespace Mapping" 단계#

"Object to Tablespace Mapping" 단계에서는 각각의 테이블 및 인덱스를 드래그 앤 드롭하여 대상 데이터베이스 상의 테이블스페이스로 매핑할 수 있다. 매핑이 변경될 때마다 대상 데이터베이스 상의 관련 테이블스페이스에 대해 필요한 전체 저장 공간 크기가 다시 계산된다. 내부적으로, 데이터베이스 객체의 크기는 바이트 단위로 정확하게 유지되지만, 대화 상자에는 그 값을 반올림하여 MB단위로 보여준다. 따라서, 테이블스페이스의 전체 크기는 그 내용물의 합계와 동일하지 않을 수도 있다.

"Select Editing" 단계#

"Select Editing" 단계에서는 원본 데이터베이스의 테이블로부터 데이터 추출시에 사용할 SELECT문을 수정할 수 있다. 사용자는 SELECT문에 힌트나 WHERE 절을 추가하는 등의 편집이 가능하며, 편집한 SELECT문을 바로 확인할 수 있다. 수정한 것을 취소하고 싶다면 Restore 버튼을 누르면 된다.

SELECT문이 수정된 테이블의 이름은 WHERE 절과 한 쌍으로 TableCondition.properties 파일에 기록된다. 이 파일은 Reconcile의 마지막 단계에서 자동 생성되며, 사용자가 편집 가능하다.

TableCondition.properties#

실행 단계에서 원본 데이터베이스 테이블에서 특정한 데이터를 선택적으로 마이그레이션할 수 있도록 "TableCondition.properties" 파일을 제공한다. 사용자는 이 파일에 데이터를 식별하여 마이그레이션하는 데 필요한 조건들을 입력할 수 있다. 파일에 포함되지 않은 테이블은 원본 테이블에서 대상 테이블로 전체 데이터를 마이그레이션한다.

이 파일은 "원본 데이터베이스 테이블 이름"=WHERE 절 형식의 쌍으로 구성되어 있고 Reconcile 단계를 완료하면 자동으로 생성된다. 이 파일에 입력된 WHERE절은 원본 테이블에서 데이터를 검색하는 SELECT문에 추가된다. 또한, 실행 단계 이후 대상 테이블에서 마이그레이션 된 데이터 개수를 확인할 때도 동일한 WHERE 절을 사용한다. 마이그레이션 된 데이터의 개수는 RunReport4Summary.html 파일에서 확인할 수 있다.

조건은 Reconcile 단계 중 "Select Editing"에서 수정하거나, Reconcile 단계 완료 후 사용자가 직접 편집할 수 있다. 이 때 다음과 같은 제약사항이 있다.

  • WHERE절은 반드시 한 줄에 기입해야 한다.
  • 원본과 대상 데이터베이스 간에 SQL 구문 차이가 있는 경우 [DEST] 섹션에 대상 데이터베이스 테이블에 적용될 WHERE 절을 별도로 기입해야 한다.
  • 예시
    DATE_TEST=WHERE C2 > DATE'2023-12-02'
...
[DEST]
DATE_TEST=WHERE C2 > TO_DATE('2023-12-02', 'YYYY-MM-DD');

보다 상세한 파일 편집 방법과 제약점은 파일 상단에서 제공하는 안내를 참조한다.

"Unacceptable Name" 단계#

"Unacceptable Name" 단계는 대상 데이터베이스의 인용 부호 없는 객체 이름 규칙에 어긋나는 객체를 보여준다. 이름에 특수 문자나 공백이 포함된 객체가 이에 해당하며, run 단계에서 생성에 실패한다. "Use Double-quoted Identifier" 체크 박스를 선택하면 문제 이름들만 큰 따옴표로 감싸 객체 생성 실패를 방지할 수 있다.

"SQL Editing" 단계#

"SQL Editing" 단계는 사용자에게 스키마 마이그레이션에 사용될 DDL 문장을 확인하고 수정하는 기능을 제공한다. 사용자는 원본 DDL문장을 참조하여 Migration Center가 대상 데이터베이스에 사용할 DDL 문장을 직접 편집할 수 있다. 프로시저, 함수, 트리거 및 뷰 객체를 생성하는 SQL 문장은 모두 PSM 타입으로 표시된다.

사용자는 PSM 카테고리 내에 있는 체크 박스를 조작하여 편집하고자 하는 객체 타입을 선택할 수 있다. 체크 박스를 조작해서 선택한 객체들은 Done 또는 To-Do 리스트 창에 표시된다. 사용자의 확인이 필요한 객체는 To-Do 리스트에 표시되고, 그렇지 않은 객체는 Done 리스트에 표시된다. 각 리스트에서 객체 이름을 클릭하면 해당 객체의 원본 및 대상 DDL 문장이 출력된다. To-Do 리스트에 속한 객체 DDL 문장을 편집한 후, Save 버튼을 누르면 해당 객체가 Done 리스트로 이동할 것이다.

예상치 못하게 Done 리스트에 속한 객체의 마이그레이션이 실행 단계에서 실패할 수도 있다. 이 경우, 사용자가 Run Report의 Missing Cause를 확인하여 오류의 원인을 파악한 다음, 수동으로 해당 객체를 마이그레이션해야 한다.

텍스트 편집기를 선호하는 사용자를 위해, 선택된 PSM 객체 DDL 문장을 파일로 출력하는 기능이 제공된다. 이 기능은 PSM 객체 타입의 Off-line 창에서 제공되며, 사용법은 Off-line 창에 기술되어 있다. Oracle 또는 TimesTen을 Altibase로 마이그레이션하는 경우, Migration Center에 내장되어 있는 PL/SQL 변환기가 PSM 타입 객체 DDL 문장을 Altibase에 호환되는 형태로 변환한다.

대부분의 문법에 대해서는 변환이 수행되지만, 의미적인 로직(semantic logic)이 포함된 문장에 대해서는 변환이 이루어지지 않으므로 사용자의 확인이 필요하다.

Migration Center는 구축 단계에서 원본 데이터베이스 객체간의 의존성 그래프를 만든다. 사용자가 대상 DDL 문장을 편집하는 중에 이 의존성을 변경한다면, 해당 객체 및 그에 관련된 객체에 대해서 마이그레이션이 보장되지 않는다.


실행 단계#

목적#

실행 단계는 원본 데이터베이스의 데이터베이스 객체를 마이그레이션 옵션에 따라 대상 데이터베이스 또는 외부 파일로 복사한다.

사용자에게는 이 단계의 결과가 가장 중요할 수 있다. 실행 단계 완료 후에 생성되는 실행 보고서에 그 결과가 담겨 있다. RunReport4Summary.html 보고서 파일은 원본 및 대상 데이터베이스 간의 데이터베이스 객체의 개수 및 테이블 레코드의 개수를 비교하여 전반적인 결과를 제공한다. RunReport4Missing.html 보고서 파일에는 실패한 마이그레이션에 대해 상세히 기술된다.

마이그레이션에 실패한 데이터는 프로젝트 폴더의 "db2db" 또는 "db2file" 폴더에 수집된다. 이 두 폴더에는 iLoader(Altibase의 명령 행 데이터 import/export 도구)에서 사용 가능한 데이터 파일 및 폼 파일이 저장된다. 각 폴더에는 생성된 데이터 파일을 iLoader를 사용해서 편리하게 데이터베이스로 가져올 수 있는 스크립트가 추가로 저장된다. "iLoaderln.sh"는 다른 스크립트 파일 및 각 테이블에 대해 iLoader를 실행하는 "iLoaderln.number.sh" 스크립트를 실행하는 주 스크립트이다.

출력#

  • RunReport4Summary.html: 마이그레이션 수행에 대한 전반적인 결과를 제공하는 요약 보고서 파일.
  • RunReport4Missing.html: 실패한 마이그레이션 데이터에 대한 정보 및 실패 원인을 제공하는 보고서 파일.
  • DbObj_Failed.sql: 실패한 SQL문의 목록과 실패 원인을 제공하는 파일.
  • db2db 폴더: 프로젝트 디렉터리의 하위 폴더로서, 실패한 마이그레이션 데이터가 저장된다. 이 폴더는 "Migration Type"으로 "DB to DB" 옵션이 선택되고 "Batch Execution"에 "No"가 선택된 경우에만 유효하다.
  • db2file 폴더: "Migration Type"으로 "DB to File" 옵션이 선택된 경우에 모든 출력이 저장되는 프로젝트 디렉터리의 하위 폴더.

내부 동작#

실행 단계는 GUI 모드에서 한 번의 마우스 클릭 또는 CLI 모드에서 하나의 커맨드만으로도 실행될 수 있다. 실행 단계 수행 방법은 3장 또는 4장의 "프로젝트 실행" 절을 참고한다.

내부적으로, 이 과정은 데이터베이스 객체 종속성을 피하기 위해 초기화 단계, PreSchema 단계, 테이블 및 데이터 단계, PostSchema 단계의 네 단계로 구성된다. 예를 들어, 인덱스 객체는 테이블 및 데이터 단계가 완료된 후 PostSchema 단계에서 마이그레이션 된다. 왜냐하면, 보통 인덱스가 없는 상태에서 데이터를 삽입하는 것이 인덱스가 있는 경우보다 더 빠르기 때문이다.

각 단계별 상세 동작은 다음과 같다:

  1. 초기화: TableCondition.properties 파일에 기록된 WHERE 절의 유효성 검사를 원본 DB를 대상으로 수행한다.
  2. PreSchema: 시퀀스 객체 마이그레이션
  3. Table & Data: 테이블 객체 및 데이터 마이그레이션
  4. PostSchema:
  5. Queue: 큐 객체 마이그레이션
  6. Constraints: 유니크, 프라이머리 키, 외래 키, 및 check 제약 조건 등의 제약 조건 마이그레이션
  7. Index: 인덱스 객체 마이그레이션
  8. Synonym: PRIVATE 시노님 객체 마이그레이션
  9. Procedures, Functions, Materialized Views, Views, Typesets 및 Triggers: DBMS 및 버전에 따라 상이함

검증 단계#


목적#

검증 단계에서는 실행 단계에서 수행한 데이터 이관이 정확하게 수행되었는지 검사한다. 검증이 완료된 후, 사용자에게 검증 보고서를 제공하여 사후 처리를 적절히 수행할 수 있도록 한다. 보고서는 원본 및 대상 데이터베이스의 정보와 함께 검증을 완료한 테이블 리스트 및 데이터 일치, 불일치 건수 정보를 나열한다.

사용자는 이 정보를 확인하여 실행 단계를 다시 수행할 것인지, FILESYNC 기능을 사용할 것인지 여부를 결정할 수 있다. 데이터의 불일치 건수가 적을 때는 FILESYNC 기능을 사용하고, 데이터 불일치 건수가 많을 때에는 실행 단계를 재수행할 것을 권장한다.

제약 조건#

  • Primary Key 제약 조건이 존재하는 테이블에 한해서만 검증 단계를 수행할 수 있다.
  • LOB 칼럼은 데이터 비교 대상에서 제외된다.

출력#

  • 검증 보고서: 검증이 완료된 테이블 리스트 및 데이터 일치, 불일치 건수 정보 같은 summary 정보가 기록된 보고서가 프로젝트 디렉터리에 출력된다.
  • validation 디렉터리: 프로젝트 디렉터리의 하위 디렉터리로써, 불일치 데이터가 저장된다. 이 디렉터리는 "Data Validation Options" 항목에서 "Write to CSV"로 "Yes" 옵션이 선택된 경우에만 사용된다.

내부 동작#

검증 단계는 GUI 모드에서 한 번의 마우스 클릭 또는 CLI 모드에서 하나의 커맨드만으로도 실행될 수 있다. 검증 단계 수행 방법은 "프로젝트 검증" 또는 "CLI 모드로 실행, 검증 단계 수행" 절을 참고한다. 내부적으로 검증 단계는 다음과 같이 수행된다.

원본과 대상 데이터베이스에서 검증할 데이터를 가져와서 비교한다. 불일치하는 데이터가 발견되고, "Data Validation Options" 항목의 "Write to CSV"가 "Yes"로 설정된 경우, 불일치하는 데이터에 해당하는 원본 데이터를 validation 폴더에 CSV 형식으로 저장한다. 이 때 옵션에 상관없이 Summary 정보는 검증 보고서에 항상 기록된다.