데이터베이스 수준 마이그레이션의 기반은 Oracle 아카이브 로그이며, 여기에는 데이터베이스의 변경 사항 로그가 포함됩니다. 대부분의 경우 아카이브 로그는 백업 및 복구 전략의 일부입니다. 복구 프로세스는 데이터베이스 복원으로 시작한 다음 하나 이상의 아카이브 로그를 재생하여 데이터베이스를 원하는 상태로 만듭니다. 이와 동일한 기본 기술을 사용하여 운영 중단이 거의 또는 전혀 없는 마이그레이션을 수행할 수 있습니다. 더욱 중요한 점은 이 기술을 통해 원래 데이터베이스를 그대로 유지하면서 마이그레이션을 수행할 수 있으므로 백업 경로가 유지됩니다.

마이그레이션 프로세스는 데이터베이스 백업을 보조 서버로 복원하는 것부터 시작됩니다. 다양한 방법으로 그렇게 할 수 있지만 대부분의 고객은 일반 백업 애플리케이션을 사용하여 데이터 파일을 복원합니다. 데이터 파일이 복원되면 사용자가 로그 전달 방법을 설정합니다. 기본 데이터베이스에서 생성된 아카이브 로그의 지속적인 피드를 만들고 복원된 데이터베이스에서 다시 재생하여 두 로그 모두 동일한 상태에 가깝게 유지하는 것이 목표입니다. 전환 시간이 되면 소스 데이터베이스가 완전히 종료되고 최종 아카이브 로그가 복사되고 경우에 따라 재실행 로그가 재생됩니다. 리두 로그에는 커밋된 최종 트랜잭션이 포함될 수 있으므로 리두 로그도 고려해야 합니다.

이러한 로그를 전송하고 재생한 후에는 두 데이터베이스가 서로 일관됩니다. 이 시점에서 대부분의 고객은 몇 가지 기본 테스트를 수행합니다. 마이그레이션 프로세스 중에 오류가 발생하면 로그 재생에서 오류를 보고하고 실패합니다. 알려진 쿼리 또는 응용 프로그램 기반 작업을 기반으로 몇 가지 빠른 테스트를 수행하여 구성이 최적화되었는지 확인하는 것이 좋습니다. 또한 원래 데이터베이스를 종료하기 전에 최종 테스트 테이블을 하나 만들어 마이그레이션된 데이터베이스에 있는지 확인하는 것이 일반적입니다. 이 단계를 수행하면 최종 로그 동기화 중에 오류가 발생하지 않습니다.

단순한 로그 전달 마이그레이션은 원본 데이터베이스와 관련하여 대역 외 방식으로 구성할 수 있으므로 업무상 중요한 데이터베이스에 특히 유용합니다. 소스 데이터베이스에 대한 구성 변경이 필요하지 않으며 마이그레이션 환경의 복원 및 초기 구성은 운영 작업에 영향을 미치지 않습니다. 로그 전달이 구성된 후 운영 서버에 일부 입출력 요구 사항이 배치됩니다. 그러나 로그 전달은 아카이브 로그의 단순 순차 읽기로 구성되므로 운영 데이터베이스 성능에 영향을 미칠 가능성은 낮습니다.

로그 전달은 장거리, 높은 변경률 마이그레이션 프로젝트에 특히 유용한 것으로 입증되었습니다. 한 예로, 하나의 220TB 데이터베이스가 약 500마일 떨어진 새로운 위치로 마이그레이션되었습니다. 변경률이 매우 높았고 보안 제한으로 인해 네트워크 연결이 사용되지 않았습니다. 로그 배송은 테이프 및 택배사를 사용하여 수행되었습니다. 소스 데이터베이스의 복제본은 아래에 설명된 절차를 사용하여 초기에 복원되었습니다. 그런 다음 최종 테이프 세트가 제공되고 로그가 복제 데이터베이스에 적용된 전환 시간까지 택배사에 의해 로그가 매주 배송되었습니다.

경우에 따라 전체 DataGuard 환경이 보장됩니다. DataGuard라는 용어를 사용하여 로그 전달 또는 대기 데이터베이스 구성을 참조하는 것은 올바르지 않습니다. Oracle DataGuard는 데이터베이스 복제 관리를 위한 포괄적인 프레임워크이지만 복제 기술은 아닙니다. 마이그레이션 과정에서 완전한 DataGuard 환경의 주된 이점은 한 데이터베이스에서 다른 데이터베이스로 투명하게 전환하는 것입니다. 또한 새로운 환경의 성능 또는 네트워크 연결 문제와 같은 문제가 발견될 경우 Dataguard는 원래 데이터베이스로 투명하게 전환할 수 있습니다. 완전히 구성된 DataGuard 환경에서는 애플리케이션이 기본 데이터베이스 위치의 변경을 감지할 수 있도록 데이터베이스 계층뿐만 아니라 응용 프로그램도 구성해야 합니다. 일반적으로 DataGuard를 사용하여 마이그레이션을 완료할 필요는 없지만 일부 고객은 내부에서 광범위한 DataGuard 전문 지식을 보유하고 있으며 마이그레이션 작업에 이미 의존하고 있습니다.

앞서 설명한 것처럼 스토리지 어레이의 고급 기능을 활용하려면 데이터베이스 레이아웃을 변경해야 하는 경우가 있습니다. 또한 ASM에서 NFS 파일 시스템으로 이동하는 것과 같은 스토리지 프로토콜이 변경될 경우 파일 시스템 레이아웃이 변경될 수도 있습니다.

DataGuard를 비롯한 로그 전달 방법의 주요 이점 중 하나는 복제 대상이 소스와 일치하지 않아도 된다는 것입니다. 로그 전달 방식을 사용하여 ASM에서 일반 파일 시스템으로 마이그레이션하거나 그 반대로 마이그레이션하는 데 문제가 없습니다. 대상 위치에서 데이터 파일의 정확한 레이아웃을 변경하여 플러그형 데이터베이스(PDB) 기술의 사용을 최적화하거나 특정 파일에 대해 선택적으로 QoS 제어를 설정할 수 있습니다. 즉, 로그 전달을 기반으로 하는 마이그레이션 프로세스를 통해 데이터베이스 스토리지 레이아웃을 쉽고 안전하게 최적화할 수 있습니다.

데이터베이스 수준 마이그레이션의 한 가지 제한 사항은 보조 서버의 필요성입니다. 이 두 번째 서버를 사용하는 방법에는 두 가지가 있습니다.

첫 번째 옵션은 가장 쉽지만 매우 강력한 서버가 필요한 대규모 환경에서는 이 옵션을 사용하는 것이 불가능할 수 있습니다. 두 번째 옵션은 파일 시스템을 원래 위치로 다시 재배치하기 위해 추가 작업이 필요합니다. 이는 파일 시스템을 스테이징 서버에서 마운트 해제하고 원래 서버에 다시 마운트할 수 있기 때문에 NFS를 스토리지 프로토콜로 사용하는 간단한 작업입니다.

블록 기반 파일 시스템은 FC 조닝 또는 iSCSI 이니시에이터를 업데이트하기 위해 추가 작업이 필요합니다. 대부분의 논리적 볼륨 관리자(ASM 포함)에서는 원래 서버에서 LUN을 사용할 수 있게 되면 LUN이 자동으로 감지되어 온라인 상태로 전환됩니다. 그러나 일부 파일 시스템 및 LVM 구현에서는 데이터를 내보내고 가져오는 데 더 많은 작업이 필요할 수 있습니다. 정확한 절차는 다양할 수 있지만 일반적으로 마이그레이션을 완료하고 원래 서버에서 데이터를 다시 저장하는 간단하고 반복 가능한 절차를 설정하는 것이 쉽습니다.

단일 서버 환경 내에서 로그 전달을 설정하고 데이터베이스를 복제할 수 있지만 새 인스턴스에는 로그를 재생하기 위한 다른 프로세스 SID가 있어야 합니다. SID가 다른 프로세스 ID의 다른 집합에서 데이터베이스를 임시로 가져온 후 나중에 변경할 수 있습니다. 하지만 이렇게 하면 복잡한 관리 작업이 많이 발생할 수 있으며 데이터베이스 환경에 사용자 오류가 발생할 위험이 있습니다.

단순 복사 작업의 값은 과소 평가되지 않아야 합니다. 오늘날의 네트워크 인프라는 초당 기가바이트 단위의 속도로 데이터를 이동할 수 있으며 파일 복사 작업은 효율적인 순차적 읽기 및 쓰기 I/O를 기반으로 합니다 로그 전달과 비교할 때 호스트 복제 작업에서 더 많은 중단이 불가피하지만 마이그레이션은 단순한 데이터 이동 그 이상입니다. 여기에는 일반적으로 네트워킹, 데이터베이스 재시작 시간 및 마이그레이션 후 테스트 변경 사항이 포함됩니다.

데이터를 복사하는 데 필요한 실제 시간은 중요하지 않을 수 있습니다. 또한 원본 데이터를 그대로 유지하므로 복제 작업은 보장된 백아웃 경로를 유지합니다. 마이그레이션 프로세스 중에 문제가 발생하면 원본 데이터가 있는 원본 파일 시스템을 다시 활성화할 수 있습니다.

플랫폼 변경이란 CPU 유형의 변경을 의미합니다. 데이터베이스를 기존 Solaris, AIX 또는 HP-UX 플랫폼에서 x86 Linux로 마이그레이션할 경우 CPU 아키텍처의 변경으로 인해 데이터를 다시 포맷해야 합니다. SPARC, IA64 및 전원 CPU는 빅 엔디안 프로세서라고 하는 반면 x86 및 x86_64 아키텍처는 리틀 엔디안라고 합니다. 따라서 Oracle 데이터 파일 내의 일부 데이터는 사용 중인 프로세서에 따라 순서가 다르게 지정됩니다.

기존에는 DataPump를 사용하여 플랫폼 간에 데이터를 복제해 왔습니다. 데이터 덤프는 대상 데이터베이스에서 보다 빠르게 가져올 수 있는 특수한 유형의 논리적 데이터 내보내기를 만드는 유틸리티입니다. DataPump 는 데이터의 논리적 복사본을 만들기 때문에 프로세서 엔디언의 종속성을 남깁니다. 데이터덤프는 여전히 일부 고객이 플랫폼 재구축을 위해 사용하고 있지만 Oracle 11g에서는 더욱 빠른 옵션인 교차 플랫폼 전송 테이블스페이스를 사용할 수 있게 되었습니다. 이렇게 하면 테이블스페이스를 다른 엔디안 형식으로 변환할 수 있습니다. 이것은 물리적 바이트를 논리적 데이터로 변환한 다음 다시 물리적 바이트로 변환해야 하는 DataPump 내보내기보다 더 나은 성능을 제공하는 물리적 변환입니다.

DataPump 및 이식 가능한 테이블스페이스에 대한 자세한 내용은 NetApp 설명서를 참조하십시오. 하지만 NetApp는 새로운 CPU 아키텍처를 사용하여 새 스토리지 시스템 로그로 마이그레이션할 때 고객을 지원하는 경험을 바탕으로 몇 가지 권장 사항을 제시합니다.

LVM은 하나 이상의 LUN 그룹을 만들어 일반적으로 익스텐트라고 하는 작은 단위로 분할하는 방식으로 작동합니다. 그런 다음 익스텐트 풀이 기본적으로 가상화된 논리적 볼륨을 생성하기 위한 소스로 사용됩니다. 이 가상화 계층은 다음과 같은 다양한 방식으로 가치를 제공합니다.

LVM을 사용한 마이그레이션은 익스텐트 이동 또는 익스텐트 미러링/디머러링의 두 가지 방법 중 하나로 작동합니다. LVM 마이그레이션은 효율적인 대규모 블록 순차적 I/O를 사용하며 성능 문제는 거의 발생하지 않습니다. 이 문제가 발생할 경우 일반적으로 I/O 속도를 제한하는 옵션이 있습니다. 이렇게 하면 마이그레이션을 완료하는 데 필요한 시간이 길어지고 호스트 및 스토리지 시스템의 I/O 부담이 줄어듭니다.

Oracle ASM은 논리 볼륨 관리자와 파일 시스템이 결합된 시스템입니다. 상위 수준에서 Oracle ASM은 LUN 모음을 가져와 작은 할당 단위로 분할하고 ASM 디스크 그룹이라고 하는 단일 볼륨으로 제공합니다. ASM에는 이중화 수준을 설정하여 디스크 그룹을 미러링하는 기능도 포함되어 있습니다. 볼륨은 미러링되지 않은(외부 중복), 미러링(일반 중복) 또는 3웨이 미러링(높은 중복)일 수 있습니다. 이중화 수준은 생성 후 변경할 수 없기 때문에 설정 시 주의해야 한다.

ASM은 파일 시스템 기능도 제공합니다. 파일 시스템이 호스트에서 직접 표시되지 않지만 Oracle 데이터베이스는 ASM 디스크 그룹에서 파일과 디렉토리를 생성, 이동 및 삭제할 수 있습니다. 또한 asmcmd 유틸리티를 사용하여 구조를 탐색할 수도 있습니다.

다른 LVM 구현과 마찬가지로 Oracle ASM은 사용 가능한 모든 LUN에서 각 파일의 I/O를 스트라이핑 및 로드 밸런싱을 통해 I/O 성능을 최적화합니다. 둘째, 기본 익스텐트를 재배치하여 ASM 디스크 그룹의 크기 조정과 마이그레이션을 모두 수행할 수 있습니다. Oracle ASM은 재조정 작업을 통해 프로세스를 자동화합니다. 새로운 LUN이 ASM 디스크 그룹에 추가되고 기존 LUN이 삭제되어 익스텐트 재배치와 디스크 그룹에서 제거된 LUN의 후속 드롭이 트리거됩니다. 이 프로세스는 가장 검증된 마이그레이션 방법 중 하나이며, 투명한 마이그레이션을 제공하는 ASM의 신뢰성이 가장 중요한 기능일 수 있습니다.

NetApp 시스템 간 데이터베이스 마이그레이션은 NetApp SnapMirror 데이터 복제 소프트웨어를 통해 거의 보편적으로 수행됩니다. 이 프로세스에는 마이그레이션할 볼륨의 미러 관계를 설정하고 볼륨이 동기화될 수 있도록 한 다음 컷오버 기간을 기다리는 작업이 포함됩니다. 소스 데이터베이스가 도착하면 소스 데이터베이스가 종료되고 최종 미러 업데이트가 한 번 수행되며 미러가 중단됩니다. 그러면 포함된 NFS 파일 시스템 디렉토리를 마운트하거나 포함된 LUN을 검색하고 데이터베이스를 시작하여 복제본 볼륨을 사용할 수 있습니다.

단일 ONTAP 클러스터 내에서 볼륨을 재배치하는 것은 마이그레이션으로 간주되는 것이 아니라 일상적인 마이그레이션으로 간주됩니다 volume move 작동. SnapMirror는 클러스터 내의 데이터 복제 엔진으로 사용됩니다. 이 프로세스는 완전히 자동화되어 있습니다. LUN 매핑이나 NFS 엑스포트 권한과 같은 볼륨 특성을 볼륨 자체와 함께 이동할 때 수행해야 할 추가 마이그레이션 단계는 없습니다. 재할당은 호스트 작업의 중단 없이 수행됩니다. 경우에 따라 새로 재배치된 데이터에 가장 효율적인 방식으로 액세스할 수 있도록 네트워크 액세스를 업데이트해야 하지만, 이러한 작업은 중단되지 않습니다.

FLI는 8.3 이상을 실행하는 Data ONTAP 시스템에서 다른 스토리지 어레이의 기존 LUN을 마이그레이션할 수 있는 기능입니다. 절차는 간단합니다. ONTAP 시스템은 다른 SAN 호스트처럼 기존 스토리지 시스템에 조닝됩니다. 그런 다음 Data ONTAP는 원하는 레거시 LUN을 제어하고 기본 데이터를 마이그레이션합니다. 또한 가져오기 프로세스에서는 데이터가 마이그레이션될 때 새 볼륨의 효율성 설정을 사용합니다. 즉, 마이그레이션 프로세스 중에 데이터를 인라인으로 압축 및 중복제거할 수 있습니다.

Data ONTAP 8.3에서 FLI를 처음 구현하면 오프라인 마이그레이션만 허용되었습니다. 이는 매우 빠른 전송이었지만 마이그레이션이 완료될 때까지 LUN 데이터를 사용할 수 없다는 것을 의미합니다. 온라인 마이그레이션은 Data ONTAP 8.3.1에서 도입되었습니다. 이러한 종류의 마이그레이션은 전송 프로세스 중에 ONTAP에서 LUN 데이터를 제공할 수 있으므로 작업 중단이 최소화됩니다. ONTAP를 통해 LUN을 사용하도록 호스트를 다시 조닝하는 동안 중단이 짧게 발생합니다. 그러나 이러한 변경이 이루어지면 데이터에 다시 액세스할 수 있고 마이그레이션 프로세스 내내 계속 액세스할 수 있습니다.

읽기 입출력은 복제 작업이 완료될 때까지 ONTAP를 통해 프록시되고 쓰기 입출력은 외부 및 ONTAP LUN 모두에 동기식으로 기록됩니다. 관리자가 전체 컷오버를 실행하여 외부 LUN을 해제하고 더 이상 쓰기를 복제하지 않는 한 두 LUN 복사본이 이 방식으로 동기화된 상태로 유지됩니다.

FLI는 FC와 함께 사용하도록 설계되었지만 iSCSI로 변경하려는 경우 마이그레이션이 완료된 후 마이그레이션된 LUN을 iSCSI LUN으로 쉽게 다시 매핑할 수 있습니다.

FLI의 기능 중 하나는 자동 정렬 감지 및 조정입니다. 여기서 정렬이란 LUN 장치의 파티션을 의미합니다. 최적의 성능을 얻으려면 I/O를 4K 블록에 맞춰 정렬해야 합니다. 파티션이 4K의 배수가 아닌 오프셋에 배치되면 성능이 저하됩니다.

정렬의 두 번째 측면은 파티션 오프셋을 조정하여 수정할 수 없는 파일 시스템 블록 크기입니다. 예를 들어, ZFS 파일 시스템의 기본 내부 블록 크기는 512바이트입니다. AIX를 사용하는 다른 고객은 512 또는 1, 024바이트 블록 크기의 JFS2 파일 시스템을 생성하는 경우가 있습니다. 파일 시스템이 4K 경계에 맞춰 정렬될 수 있지만 해당 파일 시스템 내에서 생성된 파일은 그렇지 않고 성능이 저하됩니다.

FLI는 이러한 상황에서 사용해서는 안 됩니다. 마이그레이션 후에 데이터에 액세스할 수 있지만 이로 인해 파일 시스템의 성능이 심각하게 제한됩니다. 일반적으로 ONTAP에서 랜덤 덮어쓰기 워크로드를 지원하는 모든 파일 시스템은 4K 블록 크기를 사용해야 합니다. 이 워크로드는 데이터베이스 데이터 파일 및 VDI 구축과 같은 워크로드에 주로 적용됩니다. 블록 크기는 관련 호스트 운영 체제 명령을 사용하여 확인할 수 있습니다.

예를 들어, AIX에서는 블록 크기를 로 볼 수 있습니다 lsfs -q. Linux를 사용하면 xfs_info 및 tune2fs 에 사용할 수 있습니다 xfs 및 ext3/ext4`있습니다. 와 함께 `zfs`명령은 입니다 `zdb -C.

블록 크기를 제어하는 매개 변수는 입니다 ashift 일반적으로 기본값은 9이며, 이는 2의 9 또는 512바이트를 의미합니다. 최적의 성능을 위해 ashift 값은 12(2-12=4K)여야 합니다. 이 값은 zpool이 생성될 때 설정되며 변경할 수 없습니다. 즉, 가 포함된 데이터 zpool이 됩니다 ashift 12가 아닌 경우 데이터를 새로 생성된 zpool으로 마이그레이션해야 합니다.

Oracle ASM은 기본 블록 크기를 가지고 있지 않습니다. 유일한 요구 사항은 ASM 디스크가 구축된 파티션이 올바르게 정렬되어야 한다는 것입니다.

7MTT(7-Mode 전환 툴)는 대규모 7-Mode 구성을 ONTAP로 마이그레이션하는 데 사용되는 자동화 유틸리티입니다. 대부분의 데이터베이스 고객은 전체 스토리지 공간을 재배치하지 않고 데이터베이스를 기준으로 환경을 마이그레이션하므로 다른 방법을 더욱 쉽게 찾을 수 있습니다. 또한 데이터베이스는 대규모 스토리지 환경에 포함되는 경우가 많습니다. 따라서 데이터베이스는 종종 개별적으로 마이그레이션되며, 7MTT를 사용하여 나머지 환경을 이동할 수 있습니다.

복잡한 데이터베이스 환경을 위한 스토리지 시스템을 보유한 고객 수는 소규모지만 상당수가 있습니다. 이러한 환경에는 많은 볼륨, 스냅샷 및 내보내기 권한, LUN 이니시에이터 그룹, 사용자 권한 및 Lightweight Directory Access Protocol 구성과 같은 수많은 구성 세부 정보가 포함될 수 있습니다. 이런 경우에는 7MTT의 자동화 기능을 사용하여 마이그레이션을 단순화할 수 있습니다.

7MTT는 다음 2가지 모드 중 하나로 작동할 수 있습니다.

이 두 옵션 간의 주된 차이점은 복사가 필요 없는 전환은 원래의 7-Mode HA 쌍에 연결된 모든 디스크 쉘프를 새로운 환경으로 재배치해야 하는 큰 방식이라는 것입니다. 쉘프의 하위 집합을 이동할 수 있는 옵션은 없습니다. 복사 기반 접근 방식에서는 선택한 볼륨을 이동할 수 있습니다. 또한 디스크 쉘프를 재구성하고 메타데이터를 변환하는 데 연결된 연결이 필요하므로 무복사 전환으로 컷오버 기간도 길어질 수 있습니다. 현장 경험에 비추어 볼 때, NetApp는 디스크 셸프를 재배치하고 재설정하는 데 1시간, 메타데이터 변환에 15분에서 2시간 동안 사용할 것을 권장합니다.