적용 대상:SQL Server
이 문서는 Azure Portal 내에서 Azure Arc로 활성화된 SQL Server 인스턴스를 Azure SQL Managed Instance로 마이그레이션하기 위한 Managed Instance 링크 마이그레이션에 필요한 환경을 준비하는 데 도움이 됩니다.
링크를 사용하면 분산 가용성 그룹(온라인 마이그레이션)과 실시간 복제를 사용하여 SQL Server 데이터베이스를 Azure SQL Managed Instance로 마이그레이션할 수 있습니다.
비고
마이그레이션 환경에 대한 피드백을 제품 그룹에 직접 제공할 수 있습니다.
필수 조건
Azure Portal을 통해 SQL Server 데이터베이스를 Azure SQL Managed Instance로 마이그레이션하려면 다음 필수 구성 요소가 필요합니다.
- 활성화된 Azure 구독. 아직 없는 경우 무료 계정을 만들 수 있습니다.
- Azure Arc에서 SQL Server용 Azure 확장 버전 이상을 사용하도록 설정된 지원되는 SQL Server의 인스턴스입니다. Azure Portal 또는 Azure CLI를 사용하여 확장을 업그레이드할 수 있습니다.
지원되는 SQL Server 버전
Azure SQL Managed Instance의 범용 및 중요 비즈니스용 서비스 계층은 모두 Managed Instance 링크를 지원합니다. 링크 기능을 사용한 마이그레이션은 Windows Server의 SQL Server Enterprise, Developer 및 Standard 버전에서 작동합니다.
다음 표에서는 링크에 대해 지원되는 최소 SQL Server 버전을 나열합니다.
| SQL Server 버전 | 최소 필수 서비스 업데이트 |
|---|---|
| SQL Server 2025(17.x) | SQL Server 2025 RTM(17.0.1000.7) |
| SQL Server 2022(16.x) | SQL Server 2022 RTM(16.0.1000.6) |
| SQL Server 2019(15.x) | SQL Server 2019 CU20(15.0.4312.2) |
| SQL Server 2017(14.x) | SQL Server 2017 CU31(14.0.3456.2) 이상 및 일치하는 SQL Server 2017 Azure Connect 팩(14.0.3490.10) 빌드 |
| SQL Server 2016(13.x) | SQL Server 2016 SP3(13.0.6300.2) 및 일치하는 SQL Server 2016 Azure Connect 팩(13.0.7000.253) 빌드 |
| SQL Server 2014(12.x) 이하 | SQL Server 2016 이전 버전은 지원되지 않습니다. |
역방향 마이그레이션은 해당 업데이트 정책을 사용하여 SQL 관리형 인스턴스에서 SQL Server 2025 및 SQL Server 2022에만 지원됩니다. 네이티브 백업 및 복원과 같은 다른 도구를 통해 마이그레이션을 수동으로 되돌리거나 SSMS에서 링크를 수동으로 구성할 수 있습니다.
Permissions
이 섹션에서는 Azure Portal을 통해 SQL Server 인스턴스를 SQL Managed Instance로 마이그레이션하는 데 필요한 권한을 설명합니다.
원본 SQL Server 인스턴스에서 다음 권한이 필요합니다.
- 최소 권한을 사용하도록 설정하면 데이터베이스 마이그레이션 프로세스 중에 필요에 따라 sysadmin과 같은 필요한 권한이 부여됩니다.
- 최소 권한을 사용할 수 없는 경우 마이그레이션을 수행하는 사용자에게 원본 SQL Server 인스턴스에 대한 sysadmin 권한이 필요합니다. 또한 마이그레이션을 취소해야 하는 경우 계정에 sysadmin 권한을 수동으로 할당합니다
NT AUTHORITY\SYSTEM.
Managed Instance 링크를 사용하여 마이그레이션하려면 SQL Managed Instance 대상에 대한 다음 권한 중 하나가 필요합니다.
- SQL Managed Instance 기여자 역할
- 구독 수준 기여자 또는 소유자 역할
최소 권한은 사용자 지정 권한을 참조하세요.
비고
Azure에서 SqlServerAvailabilityGroups_CreateManagedInstanceLink, SqlServerAvailabilityGroups_failoverMiLink, SqlServerAvailabilityGroups_deleteMiLink 권한을 가진 사용자는 마이그레이션 프로세스 중에 데이터베이스 마이그레이션 창에서 sysadmin 역할을 포함하여 확장에서 사용하는 계정의 SQL Server 권한을 상승시키는 작업을 수행할 수 있습니다.
SQL Server 인스턴스 준비
SQL Server 인스턴스를 준비하려면 다음 단계를 완료합니다.
- 지원되는 버전에 있는지 확인합니다.
-
데이터베이스에서 데이터베이스 마스터 키를 만듭니다
master. - 가용성 그룹 기능을 사용하도록 설정합니다.
- 시작할 때 적절한 추적 플래그를 추가합니다.
- SQL Server를 다시 시작하고 구성의 유효성을 검사합니다.
- 데이터베이스를 전체 복구 모델로 설정합니다.
- Azure에서 신뢰할 수 있는 루트 인증 기관 키를 SQL Server로 가져옵니다.
이러한 변경 내용을 적용하려면 SQL Server를 다시 시작해야 합니다.
서비스 업데이트 설치
버전 지원 표에 나열된 대로 SQL Server 버전에 적절한 서비스 업데이트가 설치되어 있는지 확인합니다. 업데이트를 설치해야 하는 경우 업데이트 중에 SQL Server 인스턴스를 다시 시작해야 합니다.
SQL Server 버전을 확인하려면 SQL Server에서 다음 T-SQL(Transact-SQL) 스크립트를 실행합니다.
-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
master 데이터베이스에서 데이터베이스 마스터 키 만들기
이 링크는 인증서를 사용하여 SQL Server와 SQL Managed Instance 간의 인증 및 통신을 암호화합니다. 데이터베이스 마스터 키는 링크에서 사용하는 인증서를 보호합니다. 데이터베이스 마스터 키가 이미 있는 경우 이 단계를 건너뛸 수 있습니다.
데이터베이스에 데이터베이스 마스터 키를 만듭니다 master . 다음 스크립트의 <strong_password> 자리에 비밀번호를 삽입하고 안전한 장소에 기밀로 보관합니다. SQL Server에서 다음 T-SQL 스크립트를 실행합니다.
-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';
데이터베이스 마스터 키가 있는지 확인하려면 SQL Server에서 다음 T-SQL 스크립트를 사용합니다.
-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';
SQL Server 2016 인스턴스 준비
SQL Server 2016(13.x)의 경우 링크에 대한 SQL Server 2016 준비 필수 구성 요소에 설명된 추가 단계를 완료해야 합니다. 링크에서 지원하는 SQL Server 2017(14.x) 이상 버전에는 이러한 추가 단계가 필요하지 않습니다.
가용성 그룹 활성화
링크 기능은 Always On 가용성 그룹 기능을 사용하며 이 기능은 기본적으로 사용되도록 설정되어 있지 않습니다. 자세한 내용은 Always On 가용성 그룹 기능을 활성화하기를 참조하세요.
가용성 그룹 기능이 사용되도록 설정되어 있는지 확인하려면 SQL Server에서 다음 T-SQL 스크립트를 실행합니다.
-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
@IsHadrEnabled as 'Is HADR enabled',
CASE @IsHadrEnabled
WHEN 0 THEN 'Availability groups DISABLED.'
WHEN 1 THEN 'Availability groups ENABLED.'
ELSE 'Unknown status.'
END
as 'HADR status'
가용성 그룹 기능이 사용하도록 설정되지 않은 경우 다음 단계에 따라 사용하도록 설정합니다.
SQL Server 구성 관리자를 엽니다.
왼쪽 창에서 SQL Server Services를 선택합니다.
SQL Server 서비스를 마우스 오른쪽 단추로 클릭한 다음 속성을 선택합니다.
Always On 가용성 그룹 탭으로 이동합니다.
Always On 가용성 그룹 사용 확인란을 선택한 다음 확인을 선택합니다.
- SQL Server 2016(13.x)을 사용 중이고 메시지와 함께
This computer is not a node in a failover cluster옵션이 비활성화된 경우 링크에 대한 SQL Server 2016 필수 구성 요소 준비에 설명된 단계를 따르세요. 이러한 단계를 완료한 후 이 단계로 돌아가서 다시 시도합니다.
- SQL Server 2016(13.x)을 사용 중이고 메시지와 함께
대화 상자에서 확인을 선택합니다.
SQL Server 서비스를 다시 시작합니다.
시작 추적 플래그 사용
링크의 성능을 최적화하려면 시작할 때 다음 추적 플래그를 사용하도록 설정합니다.
-
-T1800: 이 추적 플래그는 가용성 그룹의 주 복제본 및 보조 복제본에 대한 로그 파일이 512바이트 및 4KB와 같은 섹터 크기가 다른 디스크에 있을 때 성능을 최적화합니다. 주 복제본과 보조 복제본이 모두 4KB의 디스크 섹터 크기를 사용하는 경우 이 추적 플래그가 필요하지 않습니다. 자세한 내용은 KB3009974를 참조하세요. -
-T9567: 이 추적 플래그는 자동 시드 중에 가용성 그룹에 대한 데이터 스트림 압축을 사용하도록 설정합니다. 압축은 프로세서의 부하를 증가시키지만 시드 중 전송 시간을 크게 줄일 수 있습니다.
시작 시 이러한 추적 플래그를 활성화하려면 다음 단계를 사용합니다.
SQL Server 구성 관리자를 엽니다.
왼쪽 창에서 SQL Server Services를 선택합니다.
SQL Server 서비스를 마우스 오른쪽 단추로 클릭한 다음 속성을 선택합니다.
시작 매개 변수 탭으로 이동합니다. 시작 매개 변수 지정에서
-T1800을 입력하고 추가를 선택하여 시작 매개 변수를 추가합니다. 그런 다음,-T9567을 입력하고 추가를 선택하여 다른 추적 플래그를 추가합니다. 적용을 선택하여 변경 내용을 저장합니다.
확인을 선택하여 속성 창을 닫습니다.
자세한 내용은 추적 플래그를 사용하도록 설정하는 구문을 참조하세요.
SQL Server 다시 시작 및 구성의 유효성 검사
SQL Server 버전을 업그레이드하거나, 가용성 그룹 기능을 사용하도록 설정하거나, 시작 추적 플래그를 추가할 필요가 없는 경우 이 섹션을 건너뛸 수 있습니다.
지원되는 버전의 SQL Server에 있는지 확인하고 Always On 가용성 그룹 기능을 사용하도록 설정하고 시작 추적 플래그를 추가한 후 SQL Server 인스턴스를 다시 시작하여 이러한 모든 변경 내용을 적용합니다.
SQL Server 구성 관리자를 엽니다.
왼쪽 창에서 SQL Server Services를 선택합니다.
SQL Server 서비스를 마우스 오른쪽 단추로 클릭한 다음 다시 시작을 선택합니다.
다시 시작한 후 SQL Server에서 다음 T-SQL 스크립트를 실행하여 SQL Server 인스턴스 구성의 유효성을 검사합니다.
-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;
SQL Server 버전은 적절한 서비스 업데이트가 적용된 지원되는 버전 중 하나여야 합니다. Always On 가용성 그룹 기능을 사용하도록 설정해야 하며, -T1800 및 -T9567 추적 플래그를 사용하도록 설정해야 합니다. 다음 스크린샷은 올바르게 구성된 SQL Server 인스턴스에 대한 예상 결과의 예입니다.
데이터베이스를 전체 복구 모델로 설정
링크를 통해 마이그레이션된 데이터베이스는 전체 복구 모델에 있어야 하며 하나 이상의 백업이 있어야 합니다.
마이그레이션하려는 모든 데이터베이스에 대해 SQL Server에서 다음 코드를 실행합니다.
<DatabaseName>을 실제 데이터베이스 이름으로 바꿉니다.
-- Run on SQL Server
-- Set full recovery model for all databases you want to migrate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO
-- Execute backup for all databases you want to migrate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO
Azure에서 신뢰할 수 있는 루트 인증 기관 키를 SQL Server로 가져오기
Azure에서 발급하는 SQL Managed Instance 공개 키 인증서를 신뢰하려면 Azure에서 신뢰할 수 있는 CA(루트 인증 기관) 키를 SQL Server로 가져와야 합니다.
Azure 인증 기관 세부 정보에서 루트 CA 키를 다운로드할 수 있습니다. 최소한 DigiCert 글로벌 루트 G2 및 Microsoft RSA 루트 인증 기관 2017 인증서를 다운로드하여 SQL Server 인스턴스로 가져옵니다.
비고
SQL Managed Instance 공개 키 인증서의 인증 경로에 있는 루트 인증서는 Azure 신뢰할 수 있는 루트 CA(인증 기관)에서 발급합니다. Azure에서 신뢰할 수 있는 CA 목록을 업데이트할 때 특정 루트 CA는 시간이 지남에 따라 변경될 수 있습니다. 간소화된 설정을 위해 Azure 루트 인증 기관에 나열된 모든 루트 CA 인증서를 설치합니다. 이전에 가져온 SQL Managed Instance 공개 키의 발급자를 식별하여 필요한 CA 키만 설치할 수 있습니다.
샘플 C:\certs\<name of certificate>.crt 경로와 같이 SQL Server 인스턴스에 로컬 인증서를 저장한 다음 다음 Transact-SQL 스크립트를 사용하여 해당 경로에서 인증서를 가져옵니다. 실제 인증서 이름 <name of certificate>, DigiCert Global Root G2, 및 Microsoft RSA Root Certificate Authority 2017로 이 두 인증서에 필요한 이름으로 바꿉니다.
-- Run on SQL Server-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
CREATE CERTIFICATE [DigiCertPKI] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('DigiCertPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
CREATE CERTIFICATE [MicrosoftPKI] FROM FILE = 'C:\certs\Microsoft RSA Root Certificate Authority 2017.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('MicrosoftPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
팁 (조언)
sp_certificate_add_issuer 저장 프로시저가 SQL Server 환경에서 누락된 경우 SQL Server 인스턴스에 적절한 서비스 업데이트가 설치되어 있지 않을 수 있습니다.
마지막으로 다음 DMV(동적 관리 뷰)를 사용하여 만든 모든 인증서를 확인합니다.
-- Run on SQL Server
USE master
SELECT * FROM sys.certificates
네트워크 연결 구성
링크가 작동하려면 SQL Server와 SQL Managed Instance 간에 네트워크 연결이 있어야 합니다. 선택하는 네트워크 옵션은 SQL Server 인스턴스가 Azure 네트워크에 있는지 여부에 따라 달라집니다.
Azure 외부의 SQL Server
Azure 외부에서 SQL Server 인스턴스를 호스트하는 경우 다음 옵션 중 하나를 사용하여 SQL Server와 SQL Managed Instance 간에 VPN 연결을 설정할 수 있습니다.
팁 (조언)
데이터를 복제할 때 최상의 네트워크 성능을 위해 ExpressRoute를 사용합니다. 사용 사례에 대한 충분한 대역폭으로 게이트웨이를 프로비전합니다.
Azure Virtual Machines의 SQL Server
두 인스턴스 간에 네트워크 연결이 자동으로 존재하기 때문에 SQL Managed Instance를 호스트하는 동일한 Azure 가상 네트워크의 Azure Virtual Machines에 SQL Server를 배포하는 것이 가장 간단한 방법입니다. 자세한 내용은 빠른 시작: Azure SQL Managed Instance에 연결하도록 Azure VM 구성을 참조하세요.
Azure Virtual Machines 인스턴스의 SQL Server가 SQL 관리형 인스턴스와 다른 가상 네트워크에 있는 경우 두 가상 네트워크를 연결해야 합니다. 가상 네트워크는 이 시나리오가 작동하기 위해 동일한 구독에 있을 필요가 없습니다.
가상 네트워크를 연결하는 두 가지 옵션이 있습니다.
- Azure 가상 네트워크 피어링
- VNet 간 VPN 게이트웨이(Azure Portal, PowerShell, Azure CLI)
피어링이 Microsoft 백본 네트워크를 사용하기 때문에 사용하는 것이 좋습니다. 따라서 연결 관점에서 피어된 가상 네트워크와 동일한 가상 네트워크의 가상 머신 간에 대기 시간에는 눈에 띄는 차이가 없습니다. 가상 네트워크 피어링이 동일한 지역의 네트워크 간에 지원됩니다. 글로벌 가상 네트워크 피어링은 2020년 9월 22일 이후 생성된 서브넷에서 호스트되는 인스턴스에 지원됩니다. 자세한 내용은 질문과 대답(FAQ)을 참조하세요.
환경 간의 네트워크 포트
연결 메커니즘에 관계없이 네트워크 트래픽이 환경 간에 흐르려면 다음 요구 사항을 충족해야 합니다.
SQL Managed Instance를 호스트하는 서브넷의 NSG(네트워크 보안 그룹) 규칙은 다음을 허용해야 합니다.
- 원본 SQL Server IP 주소에서 트래픽을 수신하는 인바운드 포트 5022 및 포트 범위 11000-11999
- 대상 SQL Server IP 주소로 트래픽을 보내는 아웃바운드 포트 5022
SQL Managed Instance에서는 5022 포트를 변경할 수 없습니다.
SQL Server를 호스트하는 네트워크의 모든 방화벽 및 호스트 OS는 다음을 허용해야 합니다.
- MI 서브넷 /24의 원본 IP 범위(예: 10.0.0.0/24)에서 트래픽을 수신하기 위해 열린 인바운드 포트 5022
- MI 서브넷의 대상 IP 범위(예: 10.0.0.0/24)로 트래픽을 보내기 위해 열린 아웃바운드 포트 5022 및 포트 범위 11000~11999
5022 포트는 SQL Server 쪽에서 사용자 지정할 수 있지만 포트 범위 11000-11999는 있는 그대로 열어야 합니다.
다음 표에서는 각 환경에 대한 포트 작업에 대해 설명합니다.
| 환경 | 수행할 일 |
|---|---|
| SQL Server (Azure 외부) | 네트워크 방화벽의 포트 5022에서 SQL Managed Instance의 전체 서브넷 IP 범위에 대한 인바운드 및 아웃바운드 트래픽을 모두 엽니다. 필요한 경우 SQL Server 호스트 OS Windows 방화벽에서 동일한 작업을 수행합니다. |
| SQL Server(Azure에서) | 네트워크 방화벽의 포트 5022에서 SQL Managed Instance의 전체 서브넷 IP 범위에 대한 인바운드 및 아웃바운드 트래픽을 모두 엽니다. 필요한 경우 SQL Server 호스트 OS Windows 방화벽에서 동일한 작업을 수행합니다. 포트 5022에서 통신을 허용하려면 VM(가상 머신)을 호스트하는 가상 네트워크에 NSG(네트워크 보안 그룹) 규칙을 만듭니다. |
| SQL 관리형 인스턴스 | 포트 5022 및 포트 범위 11000-11999에서 SQL Server를 호스트하는 네트워킹 및 IP 주소의 인바운드 및 아웃바운드 트래픽을 허용하는 NSG 규칙을 Azure Portal에 만듭니다. |
Windows 방화벽에서 포트를 열려면 SQL Server 인스턴스의 Windows 호스트 OS에서 다음 PowerShell 스크립트를 사용합니다.
New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
다음 다이어그램은 SQL Server 인스턴스를 호스트하는 OS 방화벽 및 회사 방화벽 및 게이트웨이를 포함하여 환경의 모든 방화벽에 열려 있는 포트가 있어야 함을 나타내는 온-프레미스 네트워크 환경의 예를 보여 줍니다.
중요합니다
- 호스트 서버 및 네트워크의 모든 회사 방화벽 또는 게이트웨이를 포함하여 네트워킹 환경의 모든 방화벽에서 포트를 열어야 합니다. 회사 환경에서는 회사 네트워킹 계층에서 추가 포트를 열 수 있도록 이 섹션의 정보를 네트워크 관리자에게 표시해야 할 수 있습니다.
- SQL Server 쪽에서 엔드포인트를 사용자 지정하도록 선택할 수 있지만 SQL Managed Instance에 대한 포트 번호를 변경하거나 사용자 지정할 수는 없습니다.
- 관리되는 인스턴스를 호스트하는 서브넷의 IP 주소 범위와 SQL Server가 겹치지 않아야 합니다.
허용 목록에 URL 추가
네트워크 보안 설정에 따라 SQL Managed Instance FQDN 및 Azure에서 사용하는 일부 리소스 관리 엔드포인트에 대한 URL을 허용 목록에 추가해야 할 수 있습니다.
허용 목록에 다음 리소스를 추가합니다.
- SQL Managed Instance의 FQDN(정규화된 도메인 이름) 예:
managedinstance.a1b2c3d4e5f6.database.windows.net. - Microsoft Entra 인증 기관
- Microsoft Entra 엔드포인트 리소스 ID
- 자원 관리자 엔드포인트
- 서비스 엔드포인트
정부 클라우드용 SSMS 구성 섹션의 단계에 따라 SSMS(SQL Server Management Studio)의 도구 인터페이스에 액세스하고 허용 목록에 추가해야 하는 클라우드 내 리소스에 대한 특정 URL을 식별합니다.
TDE 보호 데이터베이스의 인증서 마이그레이션(선택 사항)
TDE(투명한 데이터 암호화)로 보호되는 SQL Server 데이터베이스를 SQL 관리형 인스턴스에 연결하는 경우 링크를 사용하기 전에 해당 암호화 인증서를 온-프레미스 또는 Azure VM SQL Server 인스턴스에서 SQL Managed Instance로 마이그레이션해야 합니다. 자세한 단계는 TDE로 보호되는 데이터베이스의 인증서를 Azure SQL Managed Instance로 마이그레이션을 참조하세요.
서비스 관리 TDE 키로 암호화된 SQL Managed Instance 데이터베이스는 SQL Server로 연결될 수 없습니다. 암호화된 데이터베이스를 고객 관리형 키로 암호화하고 대상 서버가 데이터베이스를 암호화하는 데 사용되는 동일한 키에 액세스할 수 있는 경우에만 SQL Server에 연결할 수 있습니다. 자세한 내용은 Azure Key Vault를 사용하여 SQL Server TDE 설정을 참조하세요.
비고
Azure Key Vault는 SQL Server 2022용 누적 업데이트 14부터 Linux의 SQL Server에서 지원됩니다.
네트워크 연결 테스트
마이그레이션을 시작하기 전에 SQL Server 인스턴스와 SQL Managed Instance 간의 네트워크 연결을 테스트합니다. 마이그레이션 프로세스의 일부로 Azure Portal에서 직접 연결을 테스트할 수 있습니다. 그러나 Transact-SQL 및 SQL Server 에이전트를 사용하여 연결을 수동으로 테스트할 수도 있습니다. 자세한 내용은 네트워크 연결 테스트를 참조하세요.
Azure Portal을 통해 연결을 테스트하려면 다음 단계를 수행합니다.
SQL Server 인스턴스 리소스에 대한 데이터베이스 마이그레이션 창에서 데이터 마이그레이션을 선택합니다.
MI 링크 옵션을 선택합니다.
마이그레이션할 대상 데이터베이스를 선택한 다음 다음: 설정을 사용하여 다음 탭으로 이동합니다.
설정 탭에서 링크의 이름과 원본 가용성 그룹을 제공합니다. 그런 다음 테스트 연결을 사용하여 SQL Server와 SQL Managed Instance 간의 네트워크 연결 유효성을 검사합니다.
다음 사항을 고려합니다.
- 거짓 부정을 방지하려면 네트워크 경로를 따라 모든 방화벽이 ICMP(인터넷 제어 메시지 프로토콜) 트래픽을 허용해야 합니다.
- 네트워크 경로 상의 모든 방화벽은 오탐지를 방지하기 위해 SQL Server UCS 전용 프로토콜의 트래픽을 허용해야 합니다. 프로토콜을 차단하면 연결 테스트가 성공할 수 있지만 링크를 만들지 못합니다.
- 패킷 수준 가드레일이 있는 고급 방화벽 설정은 SQL Server와 SQL Managed Instance 간의 트래픽을 허용하도록 올바르게 구성되어야 합니다.
제한점
다음 제한 사항을 고려하세요.
- Managed Instance 링크의 제한 사항은 Azure Portal을 통한 마이그레이션에 적용됩니다.
- 마이그레이션을 취소하려면 원본 SQL Server 인스턴스에 대한 sysadmin 권한이 필요합니다. SQL Server 인스턴스가 최소 권한을 사용하지 않는 경우 계정에 sysadmin 권한을 수동으로 할당합니다
NT AUTHORITY\SYSTEM. - 마이그레이션을 위해 Azure Portal을 통해 링크를 구성하는 것은 SSMS(SQL Server Management Studio) 또는 T-SQL(Transact-SQL)을 통해 수동으로 만든 링크와 호환되지 않습니다. 알려진 문제를 검토하여 자세히 알아보세요.
- Azure Portal을 통한 마이그레이션 모니터링은 모니터링 라이선스 요구 사항을 충족하는 SQL Server 인스턴스에서만 사용할 수 있습니다.
일반 문제 해결
Azure SQL Managed Instance로 마이그레이션할 때 발생하는 일반적인 문제를 해결하려면 마이그레이션 문제 해결을 참조하세요.