[Migration] Migration 개요

■ System Migration 배경
시스템을 가동한 후 약 3~4년 정도 시간이 경과하게 되면 사용자는 아래와 같은 문제점에 직면한다.
  □ 성능저하 현상
    - 데이터의 지속적인 증가
    - 사용자 수의 증가
  □ 시스템 리소스 부족 현상
    - CPU, Memory, Disk의 제한 및 한계 
  □ 현 Architecture의 한계로 유연성이 떨어짐
    - 신기술 접목에 대한 대처능력 떨어짐
    - 비즈니스 변화로 시스템의 통/폐합 요건 발생
  □ 낮은 DBMS 버전에 대한 업그레이드 부담
  □ 효율적인 운영 문제
    - 데이터베이스 관리 어려움(Cost 증가)
  □ 장애 발생시 Database Recovery에 많은 시간 소요(Failover, Fail back)


■ Migration이란?
제품에 대한 Version upgrade, Data 이관 작업만이 아닌 성능 향상을 위한 SQL문 Tuning, 시스템 규모에 맞는 Parameter tuning, 장애 복구 시나리오 마련 등 기존 시스템에서 취약했던 부분을 반영하여 시스템의 안정성, 가용성, 성능 향상을 구축하는 작업.


■ Migration시 논리적 고려사항
  □ Migration시 허용된 Down time은 얼마나 되는가?
  □ 향후 Storage 운영 계획은?
    - 통/폐합에 따른 Storage 변경
    - 성능 및 가용성을 고려한 Disk 재배치
    - Data 증가에 따른 size 확보 혹은 Data purge 정책 혹은 Compression
  □ 기존 업무 시스템과 Interface 이상 유무 점검은 어떻게 할 것인가?
  □ Oracle 11g New Feature 적용은 어느 범위까지 할 것인가?
  □ Migration으로 인한 Down time 발생시 OLTP 운영방안은 무엇인가?
  □ Migration 후 Data 정합성 검증은 어떻게 할 것인가?
  □ Migration 후 Application 이상 유무 검증은 어떻게 할 것인가?
  □ 성능 점검은 어떻게 할 것인가?


■ Migration시 물리적 고려사항
  □ DB 오브젝트 구조는 어떻게 되어있나?
    - User, Segment type, Size, Object type, Privilege, Column type 등
  □ Migration을 위한 가용 Disk size는 얼마인가?
  □ OS 제한 File size가 존재하는가?
  □ Distribute database option의 Operation이 가능한가?
  □ Network speed는 충분한가?
  □ Down time을 줄이면서 작업 효율을 위해 가능한 리소스 여유율은? (CPU, Memory)
  □ 고객사 보안 툴 혹은 시스템에 대한 관련된 문제는 없는가?
  □ 기타 물리적 제약은 없는가?


■ Migration시 방법적 고려사항
  □ DBMS Upgrade
    - 정의 : 현재 사용하고 있는 버전을 상위 버전으로  업그레이드함
    - 추가 작업요소
      가. 버전업에 따른 기능 점검
      나. System resource 적절성 점검
  □ DBMS Migration
    - 정의 : 운영중인 Database를 고도화 하는 작업
    - 추가 작업요소
      가. Upgrade의 가, 나 사항 동일
      나. 운영중인 Application 기능/성능 검증
      다. Interface간 기능/성능 검증
      라. System architectur 변경으로 인한 관리체계 변동


■ Migration 방법
  □ DBUA, Manual Upgrade
  □ Exp/Imp 방법(Expdp/Impdp)
  □ CTAS
  □ SQL*Loader
  □ Mview
  □ 기타 고객 DBMS 환경, Migration 요건에 맞는 Oracle Solution 수행