마이그레이션을 위한 최상의 옵션은 마이그레이션할 환경의 규모, 다운타임을 방지해야 하는 필요성, 마이그레이션을 수행하는 데 필요한 전반적인 노력 등 여러 요소의 조합에 따라 달라집니다. 대규모 데이터베이스에는 마이그레이션을 위해 더 많은 시간과 노력이 필요하지만, 이와 같은 마이그레이션의 복잡성은 최소화됩니다. 작은 데이터베이스는 신속하게 마이그레이션할 수 있지만, 수천 개의 마이그레이션을 해야 하는 경우 그 규모가 커지면 복잡한 문제가 발생할 수 있습니다. 마지막으로, 데이터베이스가 클수록 비즈니스 크리티컬에 해당할 가능성이 커지므로 백엔드 경로를 유지하면서 다운타임을 최소화해야 합니다.

여기에서는 마이그레이션 전략 계획을 위한 몇 가지 고려 사항에 대해 설명합니다.

크기가 컷오버 시간에 영향을 미칠 필요는 없지만 마이그레이션할 데이터베이스의 크기는 마이그레이션 계획에 분명히 영향을 미칩니다. 대량의 데이터를 마이그레이션해야 하는 경우 주요 고려 사항은 대역폭입니다. 복제 작업은 일반적으로 효율적인 순차적 I/O를 사용하여 수행됩니다 보수적인 추정치로, 복제 작업에 사용 가능한 네트워크 대역폭의 50%를 사용한다고 가정합니다. 예를 들어, 8GB FC 포트는 이론적으로 약 800MBps를 전송할 수 있습니다. 50%의 활용률을 가정하면 약 400Mbps의 속도로 데이터베이스를 복사할 수 있습니다. 따라서 10TB 데이터베이스를 이 속도로 약 7시간 내에 복사할 수 있습니다.

장거리 마이그레이션을 위해서는 일반적으로 에 설명된 로그 전달 프로세스와 같이 보다 창의적인 접근 방식이 필요합니다 "온라인 데이터 파일 이동". 장거리 IP 네트워크는 LAN 또는 SAN 속도와 가까운 곳에서는 거의 대역폭을 가지지 않습니다. 한 예로, NetApp는 아카이브 로그 생성 속도가 매우 높은 220TB 데이터베이스의 장거리 마이그레이션을 지원했습니다. 이 방법은 가능한 최대 대역폭을 제공하기 때문에 데이터 전송을 위해 선택한 방식은 테이프를 매일 배송하는 방식이었습니다.

많은 경우 대량의 데이터를 이동할 때 발생하는 문제는 데이터 크기가 아니라 데이터베이스를 지원하는 구성의 복잡성입니다. 단순히 50TB의 데이터베이스를 마이그레이션해야 한다는 사실을 아는 것만으로는 충분하지 않습니다. 단일 50TB 미션 크리티컬 데이터베이스, 4천 개의 기존 데이터베이스 컬렉션 또는 운영 데이터와 비운영 데이터의 조합이 될 수 있습니다. 경우에 따라 대부분의 데이터는 소스 데이터베이스의 클론으로 구성됩니다. 특히, 새 아키텍처에서 NetApp FlexClone 볼륨을 활용하도록 설계된 경우 이러한 클론을 쉽게 다시 생성할 수 있으므로 이러한 클론을 마이그레이션할 필요가 없습니다.

마이그레이션 계획을 수립하려면 범위에 포함되는 데이터베이스의 수와 우선 순위를 어떻게 지정해야 하는지 파악해야 합니다. 데이터베이스 수가 증가함에 따라 기본 마이그레이션 옵션은 스택에서 더 낮거나 낮은 경향이 있습니다. 예를 들어, RMAN과 짧은 운영 중단으로 단일 데이터베이스를 쉽게 복사할 수 있습니다. 이것이 호스트 수준 복제입니다.

데이터베이스가 50개인 경우 RMAN 복제본을 수신하도록 새 파일 시스템 구조를 설정하는 대신 데이터를 제자리로 이동하는 것이 더 쉬울 수 있습니다. 이 프로세스는 호스트 기반 LVM 마이그레이션을 통해 데이터를 이전 LUN에서 새 LUN으로 재배치하는 방법으로 수행할 수 있습니다. 이렇게 하면 DBA(데이터베이스 관리자) 팀에서 OS 팀으로 역할이 이전되고, 결과적으로 데이터가 데이터베이스와 관련하여 투명하게 마이그레이션됩니다. 파일 시스템 구성이 변경되지 않았습니다.

끝으로, 서버 200대에서 500개의 데이터베이스를 마이그레이션해야 하는 경우 ONTAP FLI(Foreign LUN Import) 기능과 같은 스토리지 기반 옵션을 사용하여 LUN을 직접 마이그레이션할 수 있습니다.

일반적으로 새 스토리지 어레이의 기능을 활용하기 위해 데이터베이스 파일 레이아웃을 변경해야 하지만 항상 그렇지는 않습니다. 예를 들어, EF-Series All-Flash 어레이의 기능은 주로 SAN 성능과 SAN 안정성을 최우선으로 합니다. 대부분의 경우 데이터 레이아웃과 관련하여 특별한 고려 사항 없이 데이터베이스를 EF-Series 어레이로 마이그레이션할 수 있습니다. 높은 IOPS, 짧은 지연 시간 및 강력한 안정성만 필요합니다. RAID 구성 또는 Dynamic Disk Pool과 같은 요소와 관련된 모범 사례가 있지만 EF-Series 프로젝트에서 이러한 기능을 활용하기 위해 전체 스토리지 아키텍처를 크게 변경할 필요는 없습니다.

반면, ONTAP로 마이그레이션하려면 일반적으로 최종 구성이 최대한의 가치를 제공할 수 있도록 데이터베이스 레이아웃을 좀 더 고려해야 합니다. ONTAP는 그 자체로 특별한 아키텍처 노력 없이 데이터베이스 환경에 많은 기능을 제공합니다. 가장 중요한 것은 현재 하드웨어의 수명이 다할 때 새 하드웨어로 중단 없이 마이그레이션할 수 있는 기능을 제공한다는 것입니다. 일반적으로 ONTAP로의 마이그레이션은 수행해야 하는 마지막 마이그레이션입니다. 후속 하드웨어가 업그레이드되고 데이터가 중단 없이 새로운 미디어로 마이그레이션됩니다.

어떤 계획을 세우면 훨씬 더 많은 혜택을 누릴 수 있습니다. 가장 중요한 고려 사항은 스냅샷 사용과 관련됩니다. 스냅샷은 거의 즉각적인 백업, 복원 및 클론 복제 작업을 수행하기 위한 기반입니다. 스냅샷 성능의 예로, 알려진 가장 큰 용도는 6개의 컨트롤러에서 약 250개의 LUN에서 실행되는 996TB의 단일 데이터베이스를 사용하는 것입니다. 이 데이터베이스는 2분 내에 백업되고 2분 내에 복원되며 15분 내에 복제될 수 있습니다. 추가 이점으로는 워크로드의 변화에 대응하여 클러스터 주변으로 데이터를 이동하는 기능과 QoS(서비스 품질) 제어 애플리케이션을 통해 다중 데이터베이스 환경에서 양호하고 일관된 성능을 제공하는 기능이 있습니다.

QoS 제어, 데이터 재배치, 스냅샷, 클론 복제 등의 기술은 거의 모든 구성에서 작동합니다. 그러나 일반적으로 이점을 극대화하기 위해서는 몇 가지 생각이 필요합니다. 새로운 스토리지 어레이에 대한 투자를 최대화하기 위해 데이터베이스 스토리지 레이아웃을 변경해야 하는 경우도 있습니다. 호스트 기반 또는 스토리지 기반 마이그레이션은 원본 데이터 레이아웃을 복제하므로 이러한 설계 변경은 마이그레이션 전략에 영향을 미칠 수 있습니다. 마이그레이션을 완료하고 ONTAP에 최적화된 데이터 레이아웃을 제공하기 위해 추가 단계가 필요할 수 있습니다. 에 나와 있는 절차 "Oracle 마이그레이션 절차 개요" 그리고 나중에 데이터베이스를 마이그레이션하는 것뿐만 아니라 최소한의 노력으로 최적의 최종 레이아웃으로 마이그레이션하는 몇 가지 방법을 보여 줍니다.

컷오버 중에 허용되는 최대 서비스 중단 시간을 결정해야 합니다. 전체 마이그레이션 프로세스로 인해 운영이 중단된다고 생각하는 일반적인 실수입니다. 서비스 중단이 시작되기 전에 다양한 작업을 완료할 수 있으며, 다양한 옵션을 통해 운영 중단 또는 운영 중단 없이 마이그레이션을 완료할 수 있습니다. 불가피한 운영 중단이 불가피한 경우에도 컷오버 시간의 기간이 절차마다 다르므로 허용되는 최대 서비스 중단 시간을 정의해야 합니다.

예를 들어 10TB 데이터베이스를 복사하려면 일반적으로 약 7시간이 소요됩니다. 비즈니스 요구 사항이 7시간 동안 중단되는 경우 파일 복사는 쉽고 안전한 마이그레이션 옵션입니다. 5시간이 허용되지 않는 경우 간단한 로그 전달 프로세스를 수행합니다(참조 "Oracle 로그 전달")를 최소한의 노력으로 설정하여 컷오버 시간을 약 15분으로 단축할 수 있습니다. 이 시간 동안 데이터베이스 관리자가 이 프로세스를 완료할 수 있습니다. 15분이 허용되는 경우 스크립팅을 통해 최종 컷오버 프로세스를 자동화하여 컷오버 시간을 단 몇 분으로 단축할 수 있습니다. 언제든지 마이그레이션의 속도를 높일 수 있지만 시간과 노력을 들여야 합니다. 컷오버 시간 목표는 비즈니스에 허용되는 성과를 기준으로 해야 합니다.

마이그레이션 시 위험을 완전히 없앨 수는 없습니다. 기술이 완벽하게 작동하더라도 사용자 오류가 발생할 가능성이 항상 있습니다. 선택한 마이그레이션 경로와 관련된 위험은 실패한 마이그레이션의 결과와 함께 고려해야 합니다. 예를 들어, Oracle ASM의 투명한 온라인 스토리지 마이그레이션 기능은 주요 기능 중 하나이며 이 방법은 가장 신뢰할 수 있는 기능 중 하나입니다. 그러나 이 메서드를 사용하여 데이터를 복구할 수 없는 방식으로 복사하고 있습니다. 드문 경우지만 ASM에서 문제가 발생하는 경우에는 쉬운 백아웃 경로가 없습니다. 유일한 옵션은 원래 환경을 복원하거나 ASM을 사용하여 마이그레이션을 원래 LUN으로 되돌리는 것입니다. 시스템에서 이러한 작업을 수행할 수 있다고 가정하면 원래 스토리지 시스템에서 스냅샷 유형 백업을 수행하면 위험이 최소화될 수 있지만 제거되지는 않습니다.

일부 마이그레이션 절차는 실행 전에 완전히 검증되어야 합니다. 마이그레이션 및 전환 프로세스의 예행 연습은 마이그레이션을 성공적으로 수행하고 다운타임을 최소화해야 하는 미션 크리티컬 데이터베이스에 대한 일반적인 요청입니다. 또한 사용자 수용 테스트는 마이그레이션 후 작업의 일부로 포함되는 경우가 많으며 이러한 테스트가 완료된 후에만 전체 시스템을 운영 환경으로 되돌릴 수 있습니다.

예행 연습이 필요한 경우 몇 가지 ONTAP 기능을 통해 프로세스를 훨씬 쉽게 수행할 수 있습니다. 특히 스냅샷은 테스트 환경을 재설정하고 데이터베이스 환경의 공간 효율적인 여러 복제본을 신속하게 생성할 수 있습니다.