데이터 마이그레이션을 수행하는 경우 어떤 방법을 선택하여 마이그레이션을 수행하는가 데이터 마이그레이션은 어떤 방법을 선택하는가에 따라 해당 시스템의 서비스 정지 시간이 확연히 달라지게 된다. 이제부터 마이그레이션을 수행하는 데이터에 따라 최적의 마이그레이션 방법을 선택하여 데이터 마이그레이션을 수행해야 할 것이다.

데이터 마이그레이션은 어떤 방법을 사용하는가에 따라 그 수행 속도는 천차 만별이다. 이러한 사실을 알고 있었는가 동일한 데이터에 대해 어떤 데이터 마이그레이션 방법을 사용한다면 1시간이 소요되고 다른 방법을 사용한다면 20분이 소요될 수 있다. 이 얼마나 놀라운 사실인가 이러한 사실을 모른다면 데이터 마이그레이션을 제안하는 사람이나 그러한 데이터 마이그레이션 계획을 검토하는 고객은 의도적이지는 않지만 서로를 속이는 것은 아닐까 시간이 많이 소요되는 작업에 대해서 서비스 정지 시간 등을 고려하기 위해 작업 시간을 산정하게 된다. 이와 같이 산정된 작업 시간이 때로는 터무니 없게 많이 산정되는 경우도 발생하게 된다. 이는 실제 작업 시간에 대한 상황에 의한 변화가 발생하기 때문에 나타나는 현상이기도 하다. 하지만 많은 부분은 우리가 작업을 수행하기 위해 사용할 수 있는 많은 방법 중 최적의 방법을 선택하지 못했기 때문에 발생하는 경우도 매우 많다. 이와 같은 현상은 데이터 마이그레이션에서 종종 발생하게 된다. 이제 부터라도 작업을 수행하는 사람이나 이를 확인하고 검토하는 사람 모두 이러한 데이터 마이그레이션의 방법을 이해하여 정확한 데이터 마이그레이션의 시간을 산정해야 할 것이다. 이 것이 우리가 고객을 위한 최대의 서비스는 아닐까 아래의 데이터 마이그레이션 방법에 대해서는 오라클의 경우에 대해 언급하도록 하겠다.

데이터 마이그레이션의 방법을 인지해라.

사람들에게 데이터 마이그레이션을 수행하기 위해 사용할 수 있는 방법에 무엇이 있는가를 질문해 보면 많은 사람들이 익스포트(Export)/임포트(Import) 방법을 이야기한다. 다른 데이터 마이그레이션 방법에 대해 질문을 하면 해당 데이터 마이그레이션 방법을 이해하지 못하는 것은 물론이고 이름마저 모르는 경우가 많았다. 이와 같이 데이터 마이그레이션을 수행하기 위한 방법에는 어떠한 것이 존재하는지 조차 모르는데 다른 것은 말할 것도 없을 것이다. 먼저 데이터 마이그레이션의 방법에는 어떠한 종류가 존재하는지 확인해 보자. 여기서 언급하는 데이터 마이그레이션의 방법은 비용이 추가되는 방법은 제외하고 데이터베이스에서 제공하는 순수 기능을 이용한 데이터 마이그레이션 방법을 확인해 보자.

n 익스포트/임포트

n 직접 로딩(Direct Loading)

n 테이블스페이스 이동 방법(Transportable Tablespace)

n 테이블 이동(Table Move)

n 백업 본을 이용한 데이터 마이그레이션

n SQL LOADER

위와 같은 데이터 마이그레이션 방법이 존재할 수 있으며 위의 데이터 마이그레이션 방법에 대해 그 특징을 확인해 보자. 데이터 마이그레이션 방법의 정확한 특성을 이해해야만 필요한 작업에 최적의 데이터 마이그레이션 방법을 사용할 수 있을 것이다.

익스포트/임포트를 이용한 데이터 마이그레이션은 데이터 마이그레이션의 역사이다.

많은 사이트에서 데이터 마이그레이션을 수행하기 위해 사용하는 방법 중 가장 많이 사용하는 방법이 익스포트/임포트이다. 그렇다면 많은 사람들은 왜 익스포트/임포트를 가장 많이 사용하는 것일까 그 이유는 가장 오래된 사용 방법이며 가장 사용하기 편하기 때문은 아닐까 생각한다.

익스포트/임포트는 데이터베이스의 탄생과 비슷한 시기에 탄생했다. 그렇기 때문에 지금 데이터베이스를 사용하는 사람이나 예전에 데이터베이스를 사용하는 사람이나 모두 동일한 익스프토/임포트를 사용하였을 것이다. 또한, 과거에는 데이터를 마이그레이션하는 방법이 익스포트/임포트 외에서 다른 방법이 거의 존재하지 않았다. 그렇기 때문에 과거에는 익스포트/임포트만으로 대부분의 데이터 마이그레이션을 수행하였다. 이러한 경험을 가지고 있는 담당자가 시간이 지나 관리자로 업무를 수행하게 되면 대부분의 데이터 마이그레이션에 대해 익스포트/임포트를 고려하게 된다. 결국, 이와 같다면 계속적으로 익스포트/임포트를 데이터 마이그레이션 방법으로 사용하게 될지도 모른다.

익스포트/임포트는 데이터가 적은 데이터베이스에 대해 서는 손쉽게 데이터 마이그레이션을 수행할 수 있다. 과거에는 데이터베이스의 크기가 크지 않았기 때문에 익스포트/임포트를 효과적으로 사용할 수 있었을 것이다. 하지만, 시대가 흐르면서 익스포트/임포트 방식은 대용량의 데이터베이스에서는 사용하기 힘든 방법이 되었다. 그 이유는 익스포트/임포트 방식이 대용량 데이터베이스에서 데이터 마이그레이션의 소요 시간을 매우 많이 증가시키는 방식이기 때문이다.

결국, 익스포트/임포트는 적은 데이터에 대해서는 효과적으로 간단하게 데이터를 마이그레이션할 수 있지만 대용량 데이터에 대해서는 소요 시간의 증가로 사용하기 힘들게 된다. 그렇기 때문에 데이터를 마이그레이션할 경우 코드 테이블 또는 버퍼 테이블 등의 작은 테이블에 대해서는 익스포트/임포트를 사용할 수 있으나 대용량 테이블에서는 익스포트/임포트를 대신하여 다른 방식으로 데이터 마이그레이션을 수행해야 할 것이다.

대용량 테이블에서 익스포트/임포트를 대신할 수 있는 데이터 마이그레이션 방법을 아래에서 확인해 보자.

직접 로딩(Direct Loading)은 데이터 마이그레이션의 최강자이다.

직접 로딩이 소개된 시기도 최근의 일은 아니다. 직접 로딩 방식이 소개된지도 몇 년의 세월이 흘렀다. 그럼에도 불구하고 많은 경우가 아니 대부분의 경우가 직접 로딩을 사용하지 않거나 직접 로딩의 존재 자체를 모르는 경우가 다반사라는 것이 매우 안타깝다.

직접 로딩은 10시간의 데이터 마이그레이션 작업을 1시간 만에 종료할 수 있게 하는 아키텍쳐를 가지고 있는 데이터 마이그레이션 방식이다. 그럼에도 불구하고 직접 로딩의 사용에 대해 주저하는 것은 우리가 직접 로딩의 정확한 아키텍쳐를 이해하지 못하기 때문은 아닐까 생각한다.

첫 번째로 직접 로딩의 수행 방식에 대해 확인해 보자. 직접 로딩 방식은 데이터를 저장하는 동안 오라클의 고수위(HWM)를 이동시키지 않고 데이터 마이그레이션을 수행하게 된다. 기존의 INSERT 작업은 데이터를 저장하는 동안 반드시 고수위(HWM)를 이동시키게 된다. 하지만, 직접 로딩은 이러한 고수위를 이동시키지 않고 테이블의 모든 데이터를 마이그레이션한 후 마지막에 한번에 고수위를 이동시키는 아키텍쳐를 가지고 있다. 이와 같이 하나의 아키텍쳐의 차이에 의해 얼마나 성능이 향상될지 의문을 가지는 경우도 많다. 하지만, 이와 같은 하나의 아키텍쳐에 의해 대용량의 데이터에 대해 10배 이상의 데이터 마이그레이션 수행 속도의 차이가 발생한다면 이를 믿을 수 있겠는가 하지만, 이는 현실에서 흔하게 발생하는 현상이다. 이처럼 고수위에 대한 아키텍쳐 하나에 의해 데이터 마이그레이션의 수행 속도가 10배 향상된다면 우리는 직접 로딩을 사용할 수 있는 작업에는 반드시 직접 로딩을 사용해야 할 것이다.

두 번째로 직접 로딩 사용의 제한을 확인해 보자. 직접 로딩은 어느 곳에나 사용할 수 있는 아키텍쳐는 아니다. 일반적인 INSERT에서는 직접 로딩을 이용할 수 없으며 INSERT…… SELECT…… 구문에서만 사용이 가능하다. 결국, 어떤 데이터를 조회해서 다른 테이블에 저장하는 경우에 직접 로딩을 사용할 수 있다는 것이다. 개발자들은 INSERT…… SELECT ……를 많은 곳에서 사용하지 못한다고 말할지도 모른다. 하지만, 많은 경우에 대해 프로그램을 INSERT ……. SELECT……로 변경할 수 있다는 사실을 아는가 대용량의 데이터에 대해 마이그레이션을 수행하는 경우 반드시 직접 로딩으로 변경하여 수행한다면 우리는 엄청난 빠른 소요 시간을 기대할 수 있을 것이다. 직접 로딩은 SQL LOADER 방식을 사용하는 경우에도 가능하다.

직접 로딩의 또 다른 제한 사항은 테이블의 데이터를 제외하고는 다른 데이터베이스 오브젝트나 또는 인덱스를 함께 마이그레이션할 수 없다는 것이다. 익스포트/임포트는 데이터 마이그레이션을 수행하는 동안 다른 오브젝트나 인덱스도 함께 마이그레이션이 수행된다. 따라서, 직접 로딩을 수행한다면 다른 오브젝트 및 인덱스는 수동으로 생성해야 할 것이다. 이러한 이유가 직접 로딩을 사용하는데 방해가 될 수 는 있다. 하지만, 대용량 테이블의 데이터 마이그레이션의 소요 시간에 있어서는 직접 로딩을 사용하는 것이 빠른 수행 속도를 보장하므로 수작업이 동반되더라도 대용량 테이블은 직접 로딩을 수행하는 것이 유리하다.

세 번째로 직접 로딩과 병렬 프로세싱(Parallel Processing)을 동시에 사용했을 경우를 확인해 보자. 병렬 프로세싱은 직접 로딩을 사용함에 있어 하나의 프로세스가 아닌 여러 개의 프로세스로 직접 로딩을 수행하게 하는 아키텍쳐이다. 따라서 디스크에서 대기(Wait)만 발생하지 않는 다면 직접 로딩과 병렬 프로세싱의 동시 사용은 대용량 데이터에 대해 우리의 상상을 초월하는 수행 속도를 보장하게 된다.