지금 이순간에도 데이터 마이그레이션은 잘못 수행되고 있다.

데이터 마이그레이션을 수행하는 과정에서 가장 중요한 것은 데이터의 정합성일 것이다. 마이그레이션이 수행된 데이터와 이전 데이터를 비교하여 데이터의 정합성에 문제가 존재한다면 앞서 언급한 대로 데이터 마이그레이션 작업은 실패한 것이다. 여기서 언급하고 싶은 것은 이러한 데이터 정합성에 의해 데이터 마이그레이션이 실패하는 것을 언급하고 싶지는 않다. 데이터 마이그레이션은 데이터의 정합성에 문제가 발생해서 실패하는 경우도 있지만 데이터 마이그레이션의 수행 속도에 의해서도 실패할 수 있다. 예를 들어, 10TB의 데이터 마이그레이션을 수행하는데 3일이 소요되며 3일간 서비스를 정지해야 한다면 어떤 고객이 이를 수용할 수 있겠는가 이제 데이터 마이그레이션은 정합성의 유지는 기본이며 소요 시간을 단축해야 하는 것이 우리의 최대 과제일 것이다. 그렇다면 어떤 이유에서 데이터 마이그레이션의 소요 시간을 단축할 수 없는 것일까

첫 번째로 기존 방식의 고수이다. 많은 DBA는 예전 버전부터 제공해온 익스포트/임포트 등의 유틸리티를 이용하여 데이터 마이그레이션을 수행한다. 하지만, 주로 사용하는 익스포트/임포트 유틸리티가 데이터 마이그레이션을 수행하는 방법 중 가장 느린 방법이라는 것을 아는가 물론, 데이터가 몇 GB 정도의 크기라면 익스포트/임포트 유틸리티로 충분히 데이터 마이그레이션을 수행할 수 있을 것이다. 하지만, TB 이상의 데이터베이스에서는 익스포트/임포트 유틸리티로는 우리가 원하는 속도를 기대하기는 힘들 것이다. 대용량 데이터에 대해 익스포트/임포트 유틸리티는 속도 저하를 발생시킨다. 또한, 해당 유틸리티에 의해 생성되는 인덱스의 생성 속도는 더더욱 엄청난 성능 저하를 발생시킨다. 익스포트/임포트 유틸리티에 의해 생성되는 인덱스는 Conventional 방식으로 인덱스를 생성하기 때문이다. 인덱스를 생성하는 방법 중 Conventional 방식으로 인덱스를 생성하는 방법은 병렬 프로세싱과 Nologging 기법을 이용한 방법에 비해 10배 이상 속도가 느릴 수 있다. 물론, 이러한 속도 차이는 실제 인덱스를 생성해야 하는 데이터의 크기 및 디스크 속도에 의해 좌우된다. 이처럼 가장 느린 아키텍쳐를 가지고 있는 익스포트/임포트 만을 통해 데이터 마이그레이션을 고집하겠는가 물론, 익스포트/임포트는 사용하기에 매우 편한 유틸리티임에는 틀림없다. 이제는 이러한 사용의 편리만을 고려하지 말고 사용이 복잡하더라도 성능을 향상시킬 수 있는 방법을 사용해야 할 것이다.

두 번째로 데이터 마이그레이션의 전략 부재에 의한 소요 시간 증가에 대해 확인해보자. 많은 곳에서 데이터 마이그레이션을 수행하면서 순차적인 방법으로 수행하는 경우가 많다. 시스템 사양이 좋지 않다면 한번에 여러 작업을 수행하지는 못할 것이다. 하지만 TB 이상의 데이터를 마이그레이션하는 시스템들은 보통의 경우 성능이 좋은 시스템을 사용하게 된다. 시스템의 유휴 자원이 존재함에도 불구하고 순차적인 작업만을 고집한다면 이는 데이터 마이그레이션의 수행 시간을 단축시킬 수 없게 된다. 예를 들어, 데이터 마이그레이션을 수행하는 중에 데이터가 모두 저장된 테이블에 대해서는 인덱스 생성을 동시에 수행할 수도 있을 것이다. 또는, 한번에 두개의 데이터 마이그레AN>그러기 위해서는 디스크 I/O 등을 확인하여 몇 개의 마이그레이션 작업을 수행할지를 선택해야 할 것이다. 이러한 내용이 데이터 마이그레이션 전략에 표현되어야 하는 것은 당연한 사실일 것이다.

세 번째는 데이터베이스 아키텍쳐에 대한 이해 부족으로 데이터 마이그레이션의 수행 속도가 저하될 수 있다. 데이터를 마이그레이션 하는 방법은 매우 다양한 방법이 존재한다. 예를 들면, 익스포트/임포트가 가장 고전적이며 많이 사용되는 방법임에는 틀림 없지만 VLDB로 변하고 있는 지금에서는 가장 속도가 느린 방식이므로 앞으로는 사용이 힘들어질 것이다. 그 대안으로 여러 가지 방법이 존재하며 그 중 하나가 직접 로딩(Direct Loading) 방식이다. 직접 로딩 방식은 DBA에 의해 미리 스크립트 등을 생성해야 하는 수 작업이 많이 동반된다. 하지만 분명한 것은 직접 로딩은 익스포트/임포트 유틸리티와 비교하여 대용량 테이블에서 몇 십 배 빠른 성능을 보장할 수 있는 아키텍쳐임에는 틀림 없다. 이와 같은 데이터베이스 아키텍쳐에 Nologging 아키텍쳐를 추가한다면 데이터 마이그레이션의 수행 속도는 가속도가 붙게 된다. 이러한 방법 외에도 Transportable 테이블스페이스 방식을 이용하여 FTP 시간만으로 데이터 마이그레이션을 수행할 수 있다. 이외에도 데이터베이스 아키텍쳐를 이용한 많은 데이터 마이그레이션 방법이 존재한다.

이와 같이 많은 종류의 데이터 마이그레이션 방법이 존재함에도 불구하고 왜 익스포트/임포트 만을 고수하는가 이는 데이터 마이그레이션을 위한 데이터베이스 아키텍쳐를 이해하지 못하기 때문에 발생하는 현상은 아닐까

이제부터 데이터 마이그레이션을 수행하기 위해 많은 아키텍쳐를 고려하고 테스트를 통해 장 단점을 분석해야 할 것이다.