Azure Database Migration Service 사용에 대한 FAQ

Azure Database Migration Service는 가동 중지 시간을 최소화하면서 여러 데이터베이스 소스에서 Azure 데이터 플랫폼으로 원활하게 마이그레이션할 수 있도록 설계된 완전 관리형 서비스입니다. 서비스는 현재 진행 중인 개발 활동과 함께 일반 공급되고 있고 다음에 집중합니다.

• 안정성 및 성능.
• 원본 -대상 쌍의 반복적 추가
• 충돌 없는 마이그레이션에 대한 지속적인 투자

이 서비스는 현재 다양한 원본/대상 쌍 또는 마이그레이션 시나리오를 지원합니다. 사용 가능한 각 마이그레이션 시나리오의 상태에 대한 전체 목록은 Azure Database Migration Service에서 지원하는 마이그레이션 시나리오의 상태 문서를 참조하세요.

SQL Server에서 마이그레이션하는 경우 Azure Database Migration Service에 지원되는 원본은 SQL Server 2008 이상 버전입니다. SQL 마이그레이션 확장과 함께 Azure Data Studio를 사용하는 경우 지원되는 원본은 SQL Server 2008부터 SQL Server 2022까지입니다.

Azure Database Migration Service는 오프라인 및 온라인 데이터 마이그레이션을 수행하는 데 사용됩니다. ‘오프라인’ 마이그레이션의 경우 마이그레이션을 시작할 때부터 애플리케이션 가동 중지 시간이 시작됩니다. ‘온라인’ 마이그레이션의 경우 가동 중지 시간이 마이그레이션 후 이동 시간으로 한정됩니다. 오프라인 마이그레이션을 테스트하여 가동 중지 시간이 용납 가능한 수준인지 판단하고, 용납되지 않는다면 온라인 마이그레이션을 수행하는 것이 좋습니다.

Azure Database Migration Service는 데이터베이스를 Microsoft Azure로 대규모로 마이그레이션하기에 좋은 방법입니다. Azure Database Migration Service를 다른 Microsoft 데이터베이스 마이그레이션 도구와 비교하는 방법에 대한 자세한 내용과 다양한 시나리오에 대한 서비스 사용에 대한 권장 사항은 Microsoft의 데이터베이스 마이그레이션 도구 및 서비스 차별화를 참조하세요.

Azure Migrate는 온-프레미스 가상 머신을 Azure IaaS로 마이그레이션하는 것을 도와줍니다. 이 서비스는 마이그레이션 적합성 및 성능 기반 크기 조정을 평가하며, Azure에서 온-프레미스 가성 머신을 실행할 때 드는 비용을 예측합니다. Azure Migrate는 온-프레미스 VM 기반 워크로드를 Azure IaaS VM으로 리프트 앤 시프트 마이그레이션하는 데 유용합니다. Azure Database Migration Service와 달리 Azure Migrate는 Azure SQL Database 또는 Azure SQL Database Managed Instance 등의 Azure PaaS 관계형 데이터베이스 플랫폼에 특화된 Database Migration Service 제공 사항이 아닙니다.

아니요. Database Migration Service는 고객 데이터를 저장하지 않습니다.

Azure SQL VM 및 Azure SQL MI 대상의 경우 DMS는 실제 마이그레이션, 즉 백업 및 복원을 사용합니다. 아래 설명된 대로 선택한 마이그레이션 모드에 따라 원본과 대상 간에 데이터 일관성이 유지되는 방식이 결정됩니다.

• 오프라인 마이그레이션: Azure SQL VM 및 Azure SQL MI 대상으로 오프라인 마이그레이션하는 동안 마이그레이션이 시작되면 애플리케이션 가동 중지 시간이 시작됩니다. DMS는 원본의 최신 백업 파일이 SMB 네트워크 스토리지 또는 Azure Blob 컨테이너(마이그레이션 구성에 따라)로 전송된 한 모든 백업 파일을 대상으로 복원합니다. CHECKSUM 옵션을 사용하여 백업을 수행하면 DMS 복원 작업이 자동으로 유효성 검사를 수행합니다. 체크섬이 없으면 복원하기 전에 백업의 무결성을 명시적으로 검사합니다. 이렇게 하면 복원 파일이 백업 파일과 동일하므로 동일한 데이터를 갖게 됩니다. DMS 마이그레이션 모니터링 페이지에 표시된 대상에 백업 파일 적용/복원을 통해 원본의 마지막 백업 파일 이름을 포함한 모든 백업 파일의 유효성을 검사하고 해당 체크섬의 유효성을 검사할 수 있습니다.

• 온라인 마이그레이션: Azure SQL VM 및 Azure SQL MI 대상으로 온라인 마이그레이션하는 동안 애플리케이션 중지와 함께 마이그레이션 컷오버를 시작하면 가동 중지 시간이 시작됩니다. DMS는 원본의 최신 백업 파일이 SMB 네트워크 스토리지 또는 Azure Blob 컨테이너(마이그레이션 구성에 따라)로 전송된 한 모든 백업 파일을 대상으로 복원합니다. 컷오버 단추를 누르면 DMS는 SMB 네트워크 스토리지 또는 Azure Blob 컨테이너에 있지만 아직 대상에 적용/복원되지 않은 보류 중인 백업 파일(있는 경우)의 개수를 표시합니다. CHECKSUM 옵션을 사용하여 백업을 수행하면 DMS 복원 작업이 자동으로 유효성 검사를 수행합니다. 체크섬이 없으면 복원하기 전에 백업의 무결성을 명시적으로 검사합니다. 이렇게 하면 복원 파일이 백업 파일과 동일하므로 동일한 데이터를 갖게 됩니다. DMS 마이그레이션 모니터링 페이지에 표시된 대상에 백업 파일 적용/복원을 통해 원본의 마지막 백업 파일 이름을 포함한 모든 백업 파일의 유효성을 검사하고 해당 체크섬의 유효성을 검사할 수 있습니다.

Azure SQL DB 대상의 경우 DMS는 Azure SQL DB의 경우 논리적 마이그레이션을 수행합니다. 즉, 원본 SQL 데이터베이스의 테이블에서 데이터를 복사하여 대상 Azure SQL DB의 테이블에 씁니다. DMS는 Azure SQL DB로의 오프라인 마이그레이션만 지원하므로 마이그레이션이 시작되면 애플리케이션 가동 중지 시간이 시작됩니다. 마이그레이션 모니터링 페이지에서 읽기(원본 데이터베이스 테이블에서) 및 복사(대상 Azure SQL DB 테이블에 기록) 행 수를 모니터링하고 유효성을 검사할 수 있습니다. 추가 유효성 검사로 아래 TSQL을 실행하여 원본 및 대상 데이터베이스 모두에서 체크섬을 가져오고 원본 및 복원 데이터가 동일한지 유효성을 검사할 수 있습니다.

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

참고: 원본 또는 대상 DB에 쓰고 있는 애플리케이션이 없는 경우. 데이터 비교를 위해 데이터베이스 비교 도구와 같은 도구를 활용할 수도 있습니다.

다음 목록에는 데이터 마이그레이션을 수행하기 위해 백그라운드에서 만들어질 수 있는 Azure 리소스가 포함되어 있습니다. 사용되는 서비스는 마이그레이션 시나리오에 따라 달라질 수 있습니다.

• Azure Monitor
• Azure VM
• Azure Storage
• Azure Service Bus
• Azure Data Factory

내부적으로 DMS는 네트워크 위치, 자격 증명, 백업 파일 및 완료된 작업에 대한 정보가 포함된 메타데이터 저장소를 유지 관리합니다. 계정 키와 같은 자격 증명 및 선택한 필드는 암호화됩니다. 원격 분석에 포함될 수 있는 테이블 이름과 같은 데이터는 해시됩니다. 사용자 이름은 서비스 로그에 일반 텍스트로 표시될 수 있지만 암호는 표시되지 않습니다. 원격 분석은 지역별로 격리되어 있으며 보존 정책에 따라 관리되며 유효한 문제 해결 목적으로 Microsoft 내에서 권한이 있는 직원만 사용할 수 있습니다. 서버 및 데이터베이스 이름과 같은 Azure 리소스 이름은 Azure 리소스에 대한 규칙을 따릅니다.

DMS(클래식)는 Azure Service Bus 항목을 활용하여 컴퓨팅 계층 간의 통신을 지원합니다. Azure Service Bus 항목은 각 DMS 인스턴스마다 고유하며 모든 개인 데이터는 암호화됩니다.

Azure Virtual Machines의 Azure SQL Managed Instance 및 SQL Server

스키마와 데이터는 백업 및 복원을 사용하여 마이그레이션됩니다. 고객은 네트워크 공유에서 복원하거나 스토리지 컨테이너에서 직접 복원할 수 있습니다. Windows 성능 데이터가 포함된 파일은 선택적(권장됨) 워크로드 크기 권장 사항을 제공하는 데 사용될 수 있습니다.

Azure SQL Database

Azure SQL Database로의 마이그레이션은 두 단계로 수행됩니다. 첫 번째 단계는 스키마 마이그레이션입니다. DMS(클래식)는 스키마 마이그레이션을 위해 SMO(SQL 관리 개체)를 사용합니다. 두 번째 단계는 실제 데이터 마이그레이션입니다. SqlBulkCopy는 데이터 마이그레이션을 수행하는 데 사용됩니다. DMS는 스키마 마이그레이션을 지원하지 않습니다. 데이터는 Azure Data Factory를 사용하여 마이그레이션됩니다. 선택적으로 권장되는 워크로드 크기 권장 사항을 제공하기 위해 Windows 성능 데이터가 포함된 파일을 사용할 수 있습니다.

Azure Database for PostgreSQL

이 시나리오에서 최종 사용자는 pg_dump 및 pg_restore 명령줄 유틸리티를 사용하여 메타데이터(이 경우 스키마)를 추출합니다. PostgreSQL에 대한 변경 데이터 캡처를 구성할 때 DMS는 내부적으로 pg_dump 및 pg_restore를 사용하여 CDC에 대한 초기 시드를 수행합니다. 데이터는 DMS 인스턴스에만 액세스할 수 있는 암호화된 임시 스토리지에 저장됩니다. Windows 성능 데이터가 포함된 파일은 선택적(권장됨) 워크로드 크기 권장 사항을 제공하는 데 사용될 수 있습니다.

Azure Database for MySQL

이 시나리오에서는 mysql-net/MySqlConnector를 사용하여 DMS(클래식)에서 스키마 추출 및 마이그레이션을 수행합니다. 가능한 경우 MySQL binlog 복제는 데이터와 스키마 변경 내용을 모두 복제하는 데 사용됩니다. 사용자 지정 코드는 binlog 복제를 사용할 수 없는 변경 내용을 동기화하는 데 사용됩니다.

MongoDB에서 Azure Cosmos DB로

DMS는 MongoDB의 데이터를 추출하여 Cosmos DB에 삽입합니다. 또한 BSON 또는 JSON 덤프에서 데이터를 추출하는 옵션도 제공합니다.

BSON 덤프의 경우 DMS는 Blob 컨테이너 내의 동일한 폴더 내에서 bsondump 형식의 데이터를 사용합니다. DMS는 collection.metadata.json 형식을 사용하여 메타데이터 파일만 찾습니다.

JSON 덤프의 경우 DMS는 포함된 데이터베이스의 이름을 딴 Blob 컨테이너 폴더의 파일을 읽습니다. 각 데이터베이스 폴더 내에서 DMS는 data 하위 폴더에 있는 데이터 파일만 사용합니다. DMS는 metadata 하위 폴더에 있고 메타데이터에 대해 collection.json 형식을 사용하여 이름이 지정된 파일만 확인합니다.

Oracle에서 Azure SQL Database로

이 시나리오에서는 선택적(권장됨) 워크로드 크기 조정 권장 사항을 제공하기 위해 AWR 보고서 또는 Windows perfmon 파일이 사용됩니다. 마이그레이션을 수행하는 사용자는 Database Schema Conversion Toolkit을 사용하여 대상 데이터베이스를 준비하기 위한 스키마 마이그레이션을 수행합니다.

Oracle에서 Azure Database for PostgreSQL로

Oracle에서 Azure SQL Database로의 전환과 마찬가지로 이 시나리오에서는 선택적(권장됨) 워크로드 크기 조정 권장 사항을 제공하기 위해 AWR 보고서 또는 Windows perfmon 파일이 사용됩니다. ora2pg 라이브러리는 마이그레이션을 수행하는 사용자가 스키마를 추출하고 데이터를 수동으로 마이그레이션하는 데 사용됩니다.

DMS(클래식)는 고객 네트워크 구성에 의존합니다. 마이그레이션 원본이 프라이빗 엔드포인트를 사용하는 경우 기본 구성인 프라이빗 엔드포인트를 사용합니다. 유일한 옵션인 경우 공용 엔드포인트를 사용합니다.

DMS는 데이터 이동의 일정을 계획하고 조정하기 위해 뒤에서 ADF를 많이 사용합니다. 또한 자체 호스팅 통합 런타임은 자체 ADF 파이프라인에 이미 사용하고 있는 것과 다르지 않습니다. 방화벽 및 프록시 서버 문제에 대한 자세한 내용은 자체 호스팅 통합 런타임 만들기 및 구성을 참조하세요.

모든 고객 데이터는 미사용 시 암호화됩니다. 논리 서버 이름 및 데이터베이스 이름을 포함하되 이에 국한되지 않는 일부 메타데이터는 물론 마이그레이션 상태 및 마이그레이션 진행률도 암호화되지 않은 서비스 로그에 표시됩니다.

전송 중인 모든 데이터는 기본적으로 TLS 1.2 암호화로 보호됩니다. 이전 버전의 TLS가 필요한 레거시 클라이언트는 DMS(클래식) 포털 페이지에서 필수 버전을 사용하도록 설정해야 합니다. DMS의 경우 자체 호스팅 통합 런타임이 설치된 컴퓨터는 레거시 클라이언트를 수용하는 데 필요한 TLS 설정을 허용하도록 구성할 수 있습니다. SQL Server의 TLS 구성에 대한 자세한 내용은 KB3135244 - Microsoft SQL Server에 대한 TLS 1.2 지원을 참조하세요.

가능한 경우 프라이빗 엔드포인트가 사용됩니다. 프라이빗 엔드포인트가 옵션이 아닌 경우 서비스 계층 간 통신에 공용 엔드포인트가 사용됩니다. 엔드포인트 형식에 관계없이 모든 리소스는 DMS의 특정 인스턴스 전용/범위로 지정되며 고유한 자격 증명으로 보호됩니다.

데이터 평면 또는 컨트롤 플레인 내 데이터 암호화를 위한 고객 관리형 키는 지원되지 않습니다. 그러나 모든 고객 데이터는 서비스에서 관리하는 키를 사용하여 미사용 시 암호화됩니다. 논리 서버 이름, 데이터베이스 이름, 마이그레이션 상태 및 진행률을 포함하되 이에 국한되지 않는 일부 메타데이터는 암호화되지 않은 형식으로 서비스 로그에 표시됩니다.

전송 중인 모든 데이터는 기본적으로 TLS 1.2 암호화로 암호화됩니다. DMS(클래식) 포털 페이지에서는 이전 버전의 TLS를 레거시 클라이언트에 사용할 수 있습니다. DMS의 경우 자체 호스팅 통합 런타임이 설치된 컴퓨터는 레거시 클라이언트를 수용하기 위해 TLS 설정 관리를 허용하도록 구성할 수 있습니다. SQL Server의 TLS 구성에 대한 자세한 내용은 KB3135244 - Microsoft SQL Server에 대한 TLS 1.2 지원을 참조하세요.

고객 관리형 키를 사용하여 제어 또는 데이터 평면의 데이터를 암호화하는 기능을 노출하지 않습니다. 서비스 로그를 제외한 모든 고객 데이터는 DMS 인스턴스가 삭제되는 순간 삭제됩니다. DMS 서비스 로그는 30일 동안만 보관됩니다.

TDE

DMS는 DE(투명한 데이터베이스 암호화)를 위해 CMK(고객 관리형 키)를 Azure SQL로 마이그레이션하는 것을 지원합니다. TDE 키를 마이그레이션하는 단계별 지침은 자습서: Azure Data Studio에서 TDE 지원 데이터베이스(미리 보기)를 Azure SQL로 마이그레이션을 참조하세요.

셀 암호화

셀 수준 암호화는 스키마 수준에서 처리됩니다. 스키마 마이그레이션 도구는 셀 수준 암호화를 구현하는 데 필요한 함수 및 저장 프로시저를 포함한 모든 스키마 개체를 마이그레이션합니다.

Always Encrypted

DMS는 현재 원본과 대상 간에 개별 데이터 행이 마이그레이션되는 시나리오를 통한 Always Encrypted 마이그레이션을 지원하지 않습니다. Always Encrypted를 통해 암호화된 열은 기존 SQL Server 인스턴스에서 Azure SQL VM 또는 Azure SQL Managed 인스턴스로 이동하는 것과 같이 백업/복원을 사용하는 시나리오에서 예상대로 마이그레이션됩니다.

Azure에서 이미 사용할 수 있는 것 이상의 위치 인식 액세스 제어를 구현하지 않습니다. DMS 인스턴스와 연결된 모든 데이터는 DMS 리소스와 동일한 지역에 있습니다.

서비스는 서로 다른 내부 제어 및 비즈니스 프로세스의 다양한 환경에서 사용됩니다. DMS는 사용 중인 계정이 액세스할 수 있는 모든 곳에서 데이터를 이동합니다. 작업 중인 환경의 권한과 내부 제어를 이해하는 것은 사용자의 책임입니다. DMS가 원본에 연결하는 데 사용하는 계정에 원본에서 마이그레이션하려는 모든 데이터를 볼 수 있는 액세스 권한이 있는지 확인하는 것이 특히 중요합니다.

VNet 주입은 Microsoft 테넌트 내에 있는 Azure 리소스를 고객 테넌트 아래 VNet의 서브넷에 추가하는 작업입니다. 이 방식은 고객 리소스에 대한 액세스를 유지하면서 고객을 대신하여 컴퓨팅을 관리할 수 있도록 DMS에서 수행되었습니다. 네트워크가 고객 구독에 있으므로 Microsoft는 시작, 중지, 삭제 또는 배포 명령을 실행하는 것 외에는 VM을 관리할 수 없습니다. VM에 액세스해야 하는 다른 모든 관리 작업에는 고객이 시작하는 지원 요청 및 승인이 필요합니다.

데이터베이스 마이그레이션을 수행할 때 Azure Database Migration Service가 원활히 실행되도록 하기 위해 필요한 필수 구성 요소가 몇 가지 있습니다. 일부 필수 구성 요소는 서비스가 지원하는 모든 시나리오(원본-대상 쌍)에 적용되는 반면에 특정 시나리오에만 적용되는 필수 구성 요소도 있습니다.

지원되는 모든 마이그레이션 시나리오에 공통적인 Azure Database Migration Service 필구 구성 요소는 다음을 수행해야 합니다.

• Azure Resource Manager 배포 모델을 사용하여 Azure Database Migration Service용 Microsoft Azure Virtual Network를 만듭니다. 그러면 ExpressRoute 또는 VPN을 사용하여 온-프레미스 원본 서버에 사이트 간 연결이 제공됩니다.
• 가상 네트워크 보안 그룹 규칙이 ServiceBus, Storage 및 AzureMonitor의 ServiceTags용 443 포트를 차단하지 않는지 확인합니다. 가상 네트워크 NSG 트래픽 필터링에 대한 자세한 내용은 네트워크 보안 그룹을 사용하여 네트워크 트래픽 필터링 문서를 참조하세요.
• 원본 데이터베이스 앞에 방화벽 어플라이언스를 사용하는 경우 Azure Database Migration Service에서 원본 데이터베이스에 액세스하여 마이그레이션할 수 있도록 허용하는 방화벽 규칙을 추가해야 합니다.

Azure Database Migration Service를 사용하여 특정 마이그레이션 시나리오를 경합하는 데 필요한 모든 필수 구성 요소 목록은 Azure Database Migration Service 설명서에서 관련 자습서를 참조하세요.

Azure Database Migration Service가 마이그레이션을 위해 원본 데이터베이스에 액세스하게 하려면 방화벽 규칙을 추가해야 할 수 있습니다. 서비스에 대한 IP 주소는 동적이지만 ExpressRoute를 사용하는 경우에는 이 주소가 회사 네트워크에서 프라이빗으로 할당됩니다. 적절한 IP 주소를 식별하는 가장 쉬운 방법은 프로비저닝된 Azure Database Migration Service 리소스와 동일한 리소스 그룹을 살펴보고 관련 네트워크 인터페이스를 찾는 것입니다. 일반적으로 네트워크 인터페이스 리소스의 이름은 NIC 접두사로 시작되고 그 뒤에 고유한 문자와 숫자 시퀀스가 붙습니다(예: NIC-jj6tnztnmarpsskr82rbndyp). 이 네트워크 인터페이스 리소스를 선택하면 Azure Portal 리소스 개요 페이지에서 허용 목록에 포함되어야 하는 IP 주소를 볼 수 있습니다.

SQL Server가 수신 대기하는 포트 원본을 허용 목록에 포함해야 할 수도 있습니다. 기본적으로 이 포트는 1433이지만 원본 SQL Server는 다른 포트도 수신 대기하도록 구성될 수 있습니다. 이 경우 해당 포트도 허용 목록에 포함시켜야 합니다. 동적 관리 뷰 쿼리를 사용하여 SQL Server가 수신 대기하는 포트를 확인할 수 있습니다.

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

SQL Server 오류 로그를 쿼리하여 SQL Server가 수신 대기하는 포트를 확인할 수도 있습니다.

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

가상 네트워크 설정 프로세스를 안내하는 Microsoft 자습서는 많이 있으며, 공식적으로는 Azure Virtual Network 문서에 나와있습니다.

일반적이고 간단한 데이터베이스 마이그레이션 단계:

1. 대상 데이터베이스를 만듭니다.
2. 원본 데이터베이스 평가
   • 동일한 마이그레이션의 경우 DMA를 사용하여 기존 데이터베이스를 평가합니다.
   • 다른 유형의 마이그레이션(경쟁 원본에서)의 경우 SSMA를 사용하여 기존 데이터베이스를 평가합니다. 또한 SSMA를 사용하여 데이터베이스 개체를 변환하고 대상 플랫폼으로 스키마를 마이그레이션합니다.
3. Azure Database Migration Service 인스턴스를 만듭니다.
4. 마이그레이션할 원본 데이터베이스, 대상 데이터베이스 및 테이블을 지정하는 마이그레이션 프로젝트를 만듭니다.
5. 전체 로드를 시작합니다.
6. 후속 유효성 검사를 선택합니다.
7. 새 클라우드 기반 데이터베이스로 프로덕션 환경의 수동 전환을 수행합니다.

마이그레이션 작업을 수행할 때 원본 데이터베이스 시스템에 연결하는 데 문제가 있는 경우 DMS 인스턴스를 설정하는 가상 네트워크의 동일한 서브넷에 가상 머신을 만듭니다. 가상 머신에서 UDL 파일을 사용하여 SQL Server에 대한 연결을 테스트하거나 MongoDB 연결을 테스트하기 위해 Robo 3T를 다운로드하는 등의 연결 테스트를 실행할 수 있어야 합니다. 연결 테스트가 성공하면 원본 데이터베이스에 연결하는 데 문제가 없어야 합니다. 연결 테스트에 성공하지 못한 경우 네트워크 관리자에게 문의하세요.

사용자가 Azure DMS(Database Migration Service)를 명시적으로 중지하거나 서비스가 24시간 동안 비활성 상태인 경우 서비스는 중지되거나 자동으로 일시 중지된 상태입니다. 각각의 경우 서비스를 사용할 수 없으며 중지된 상태입니다. 활성 마이그레이션을 다시 시작하려면 서비스를 다시 시작합니다.

몇 가지 작업을 수행하면 서비스를 사용한 데이터베이스 마이그레이션 속도를 높일 수 있습니다.

DMS(클래식)의 경우-

• 서비스 인스턴스를 만들 때 다중 CPU 범용 가격 책정 계층을 사용하면 서비스에서 다중 vCPU를 활용하여 병렬 처리 및 빠른 데이터 전송이 가능합니다.
• 하위 수준의 SKU를 사용할 때 데이터 전송 작업에 영향을 줄 수 있는 Azure SQL Database 제한을 최소화하기 위해 데이터 마이그레이션 작업 중에 Azure SQL Database 대상 인스턴스를 프리미엄 계층 SKU로 일시 강화합니다.

DMS의 경우-

• 로컬 파일 공유에서 Azure Blob Storage로 백업을 복사하는 경우 또는 대상 Azure SQL DB로 마이그레이션을 수행하는 동안 DMS는 SHIR 노드를 컴퓨팅으로 사용합니다. 따라서 해당 SHIR 노드의 리소스 사용량을 모니터링해야 합니다.
• 하위 수준의 SKU를 사용할 때 데이터 전송 작업에 영향을 줄 수 있는 Azure SQL Database 디스크 제한을 최소화하기 위해 데이터 마이그레이션 작업 중에 Azure SQL Database 대상 인스턴스를 프리미엄 계층 SKU로 일시 강화합니다.
• 자세한 내용은 블로그를 참조하세요.

다음 단계

• Azure Database Migration Service란?