Förbered miljön för en Managed Instance-länkmigrering – SQL Server-migrering i Azure Arc

Applies to:SQL Server

Den här artikeln hjälper dig att förbereda din miljö för en Managed Instance länkmigrering av din SQL Server-instans som aktiveras av Azure Arc till Azure SQL Managed Instance i Azure portalen.

Med länken kan du migrera dina SQL Server databaser till Azure SQL Managed Instance med hjälp av realtidsreplikering med en distribuerad tillgänglighetsgrupp (onlinemigrering):

Diagram som visar migrering av Managed Instance-länkar.

Anmärkning

Du kan ge feedback om migreringsupplevelsen direkt till produktgruppen.
Migrera upp till 10 databaser i taget från och med Azure-tillägget för SQL Server version 1.1.3348.364.

Förutsättningar

Om du vill migrera dina SQL Server databaser för att Azure SQL Managed Instance via Azure-portalen behöver du följande förutsättningar:

En aktiv prenumeration för Azure. Om du inte har ett, skapa ett gratis konto.
En stödjad instans av SQL Server aktiverad av Azure Arc med senaste versionen av Azure-tillägget för SQL Server. Information om hur du uppgraderar tillägget finns i Uppgradera tillägget.

SQL Server versioner som stöds

Både tjänstnivåerna Generell användning och Affärskritisk i Azure SQL Managed Instance stöder länken Managed Instance. Migrering med länkfunktionen fungerar med enterprise-, utvecklar- och standardversionerna av SQL Server på Windows Server.

I följande tabell visas de lägsta SQL Server versioner som stöds för länken:

den SQL Server-version	Minsta nödvändiga underhållsuppdatering
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) eller senare och matchande SQL Server 2017 Azure Connect-paket (14.0.3490.10) bygga
SQL Server 2016 (13.x)	SQL Server 2016 SP3 (13.0.6300.2) och matchande SQL Server 2016 Azure Connect-paketet (13.0.7000.253) build
SQL Server 2014 (12.x) och tidigare	Versioner före SQL Server 2016 stöds inte.

Omvänd migrering stöds endast till SQL Server 2025 och SQL Server 2022 från SQL-hanterade instanser med motsvarande uppdatera princip. Du kan manuellt ångra en migrering via andra verktyg, till exempel intern säkerhetskopiering och återställning, eller manuellt konfigurera en länk i SSMS.

Permissions

I det här avsnittet beskrivs de behörigheter som du behöver för att migrera din SQL Server-instans för att SQL Managed Instance via Azure portalen.

På käll-SQL Server-instansen behöver du följande behörigheter:

Om du aktiverar lägsta behörighetbeviljas nödvändiga behörigheter som sysadmin efter behov under databasmigreringsprocessen.
Om du inte kan använda minsta möjliga behörighet behöver den person som utför migreringen sysadmin behörigheter på käll-SQL Server-instansen. Om du behöver avbryta en migrering tilldelar du dessutom sysadmin-behörigheter manuellt till NT AUTHORITY\SYSTEM kontot.

Om du vill migrera med länken Managed Instance behöver du någon av följande behörigheter för SQL Managed Instance målet:

Rollen SQL Managed Instance medverkare
Rollen Bidragsgivare eller Ägare på prenumerationsnivå

Minsta behörigheter finns i Anpassade behörigheter.

Anmärkning

Användare med behörigheterna SqlServerAvailabilityGroups_CreateManagedInstanceLink, SqlServerAvailabilityGroups_failoverMiLink och SqlServerAvailabilityGroups_deleteMiLink i Azure kan utföra åtgärder på Database-migreringen under migreringsprocessen som höjer SQL Server behörigheter för det konto som används av tillägget, inklusive rollen sysadmin.

Matcha prestandakapacitet mellan repliker

När du använder länkfunktionen är det viktigt att matcha prestandakapaciteten mellan SQL Server och SQL Managed Instance. Den här matchningen hjälper dig att undvika prestandaproblem om den sekundära repliken inte kan hänga med i replikeringen från den primära repliken eller efter redundansväxlingen. Prestandakapaciteten omfattar processorkärnor (eller virtuella kärnor i Azure), minne och I/O-dataflöde.

Förbereda din SQL Server-instans

Utför följande steg för att förbereda din SQL Server-instans:

Kontrollera att du har den version som stöds.
Skapa en databashuvudnyckel i master databasen.
Aktivera funktionen tillgänglighetsgrupper.
Lägg till rätt spårningsflaggor vid start.
Starta SQL Server och verifiera konfigurationen.
Ställ in databasen på en fullständig återhämtningsmodell.
Importera Azure-betrodda rotcertifikatutfärdarnycklar till SQL Server.
Aktivera Accelererad databasåterställning om du använder SQL Server 2019 eller senare och planerar att använda den på den SQL-hanterade målinstansen.
Aktivera Service Broker om du planerar att använda den på en mål-SQL-hanterad instans.

Du måste starta SQL Server för att ändringarna ska börja gälla.

Installera tjänstuppdateringar

Se till att din SQL Server version har rätt underhållsuppdatering installerad, enligt listan i tabellen versionssupport. Om du behöver installera uppdateringar måste du starta om din SQL Server instans under uppdateringen.

Om du vill kontrollera din SQL Server-version kör du följande Transact-SQL-skript (T-SQL) på SQL Server:

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

Skapa en huvudnyckel för databasen i huvuddatabasen

Länken använder certifikat för att kryptera autentisering och kommunikation mellan SQL Server och SQL Managed Instance. Databasens huvudnyckel skyddar de certifikat som används av länken. Om du redan har en huvudnyckel för databasen kan du hoppa över det här steget.

Skapa en databashuvudnyckel i master databasen. Infoga lösenordet i stället för <strong_password> i följande skript och förvara det på en konfidentiell och säker plats. Kör det här T-SQL-skriptet på SQL Server:

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

Kontrollera att du har databashuvudnyckeln genom att använda följande T-SQL-skript på SQL Server:

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

Förbereda SQL Server 2016-instanser

För SQL Server 2016 (13.x) måste du slutföra de extra stegen som beskrivs i Prepare SQL Server 2016-krav för länken. De här extra stegen krävs inte för SQL Server 2017 (14.x) och senare versioner som stöds av länken.

Aktivera tillgänglighetsgrupper

Länkfunktionen förlitar sig på funktionen Always On-tillgänglighetsgrupper, som är inaktiverad som standardinställning. Mer information finns i Aktivera funktionen AlwaysOn-tillgänglighetsgrupper.

Kontrollera att funktionen tillgänglighetsgrupper är aktiverad genom att köra följande T-SQL-skript på SQL Server:

-- 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'

Om funktionen tillgänglighetsgrupper inte är aktiverad följer du de här stegen för att aktivera den:

Öppna SQL Server Configuration Manager.
Välj SQL Server Services i det vänstra fönstret.
Högerklicka på tjänsten SQL Server och välj sedan Egenskaper:
Gå till fliken AlwaysOn-tillgänglighetsgrupper .
Markera kryssrutan Aktivera AlwaysOn-tillgänglighetsgrupper och välj sedan OK.
- Om du använder SQL Server 2016 (13.x) och alternativet Aktivera alwayson-tillgänglighetsgrupper inaktiveras med meddelandet This computer is not a node in a failover cluster, följ stegen som beskrivs i Prepare SQL Server 2016 krav för länken. När du har slutfört de här stegen går du tillbaka till det här steget och försöker igen.
Välj OK i dialogrutan.
Starta om SQL Server-tjänsten.

Aktivera spårningsflaggor vid start

Om du vill optimera prestanda för länken aktiverar du följande spårningsflaggor vid start:

-T1800: Den här spårningsflaggan optimerar prestanda när loggfilerna för de primära och sekundära replikerna i en tillgänglighetsgrupp finns på diskar med olika sektorstorlekar, till exempel 512 byte och 4 KB. Om både primära och sekundära repliker använder en disksektorstorlek på 4 KB behöver du inte den här spårningsflaggan. Mer information finns i KB3009974.
-T9567: Den här spårningsflaggan möjliggör komprimering av dataströmmen för tillgänglighetsgrupper under automatisk seeding. Komprimering ökar belastningen på processorn men kan avsevärt minska överföringstiden under seeding.

Använd följande steg för att aktivera dessa spårningsflaggor vid start:

Öppna SQL Server Configuration Manager.
Välj SQL Server Services i det vänstra fönstret.
Högerklicka på tjänsten SQL Server och välj sedan Egenskaper.
Gå till fliken Startparametrar . I Ange en startparameter anger -T1800 du och väljer Lägg till för att lägga till startparametern. Ange -T9567 sedan och välj Lägg till för att lägga till den andra spårningsflaggan. Välj Använd för att spara ändringarna.
Välj OK för att stänga fönstret Egenskaper .

Mer information finns i syntaxen för att aktivera spårningsflaggor.

Starta om SQL Server och verifiera konfigurationen

Om du inte behövde uppgradera versionen av SQL Server, aktivera funktionen tillgänglighetsgrupp eller lägga till startspårningsflaggor kan du hoppa över det här avsnittet.

När du har kontrollerat att du har en version av SQL Server som stöds aktiverar du funktionen AlwaysOn-tillgänglighetsgrupper och lägger till dina startspårningsflaggor och startar om SQL Server-instansen för att tillämpa alla dessa ändringar:

Öppna SQL Server Configuration Manager.
Välj SQL Server Services i det vänstra fönstret.
Högerklicka på tjänsten SQL Server och välj sedan Restart.

Efter omstarten kör du följande T-SQL-skript på SQL Server för att verifiera konfigurationen av din SQL Server-instans:

-- 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;

Din SQL Server version bör vara en av de versioner som stöds med lämpliga tjänstuppdateringar. Funktionen Always On-tillgänglighetsgrupper ska vara aktiverad, och du bör ha spårflaggorna -T1800 och -T9567 aktiverade. Följande skärmbild är ett exempel på det förväntade resultatet för en korrekt konfigurerad SQL Server instans:

Skärmbild som visar det förväntade resultatet i S S M S.

Ställ in databasen för fullständigt återställningsmodell

Databaser som migreras via länken måste finnas i den fullständiga återställningsmodellen och ha minst en säkerhetskopia.

Kör följande kod på SQL Server för alla databaser som du vill migrera. Ersätt <DatabaseName> med det faktiska databasnamnet.

-- 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

Importera Azure betrodda rotcertifikatutfärdarnycklar till SQL Server

Om du vill lita på de offentliga nyckelcertifikat för SQL Managed Instance som utfärdas av Azure, måste du importera Azure-betrodda rotcertifikatutfärdarnycklar (CA) till SQL Server.

Du kan ladda ned rotcertifikatutfärdarnycklarna från Azure information om certifikatutfärdare. Hämta minst DigiCert Global Root G2 och Microsoft RSA Root Certificate Authority 2017 certifikat och importera dem till din SQL Server-instans.

Anmärkning

Rotcertifikatet i certifieringssökvägen för ett offentligt nyckelcertifikat i en SQL Managed Instance utfärdas av en betrodd Azure rotcertifikatsutfärdare (CA). Den specifika rotcertifikatutfärdaren kan ändras med tiden när Azure uppdaterar listan över betrodda certifikatutfärdare. För en förenklad installation installerar du alla rot-CA-certifikat som anges i Azure Rotcertifikatutfärdare. Du kan bara installera den nödvändiga CA-nyckeln genom att identifiera utfärdaren av en tidigare importerad SQL Managed Instance offentlig nyckel.

Spara certifikaten lokalt i SQL Server-instansen, till exempel till sökvägen C:\certs\<name of certificate>.crt och importera sedan certifikaten från sökvägen med hjälp av följande Transact-SQL skript. Ersätt <name of certificate> med det faktiska certifikatnamnet: DigiCert Global Root G2 och Microsoft RSA Root Certificate Authority 2017, som är de namn som krävs för dessa två certifikat.

-- 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

Tips/Råd

Om den lagrade proceduren sp_certificate_add_issuer saknas i din SQL Server miljö har din SQL Server-instans förmodligen inte appropriate-tjänstuppdateringen installerad.

Kontrollera slutligen alla skapade certifikat med hjälp av följande dynamiska hanteringsvy (DMV):

-- Run on SQL Server
USE master
SELECT * FROM sys.certificates

Aktivera accelererad databasåterställning

För SQL Server 2019 och senare versioner aktiverar du accelerated database recovery och kontrollerar att det beständiga versionsarkivet (PVS) är inställt på PRIMARY. Om accelererad databasåterställning inte är aktiverad på källdatabasen SQL Server kan du inte aktivera den på sql-målhanterad instans när databasen har migrerats. Om det beständiga versionsarkivet (PVS) inte är inställt PRIMARYpå kan du få problem med återställningsåtgärder på den sql-hanterade målinstansen.

För SQL Server 2017 och tidigare versioner stöds inte accelererad databasåterställning, så det här steget är inte nödvändigt.

Följ dessa steg för att konfigurera accelererad databasåterställning korrekt på källdatabasen SQL Server:

Aktivera accelererad databasåterställning genom att köra följande Transact-SQL skript på SQL Server:
```
ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
```
Det beständiga versionsarkivet (PVS) måste anges till PRIMARY på källdatabasen, vilket är standardkonfigurationen. Om detta ändrades tidigare måste du ändra tillbaka det till PRIMÄR innan du påbörjar migreringen.

Aktivera Service Broker

Service Broker är aktiverat som standard för alla versioner av SQL Server. Om Service Broker har inaktiverats och du planerar att använda den på SQL Managed Instance aktiverar du Service Broker på källdatabasen SQL Server innan du migrerar till SQL Managed Instance. Om Service Broker inte är aktiverat på källdatabasen SQL Server kan du inte använda den på den sql-hanterade målinstansen.

Kontrollera om Service Broker är aktiverat genom att köra följande Transact-SQL skript på SQL Server instans:

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Om Service Broker är inaktiverat aktiverar du det genom att köra följande Transact-SQL skript på källdatabasen SQL Server:

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

Konfigurera nätverksanslutning

För att länken ska fungera måste du ha nätverksanslutning mellan SQL Server och SQL Managed Instance. Vilket nätverksalternativ du väljer beror på om din SQL Server instans finns i ett Azure nätverk eller inte.

SQL Server utanför Azure

Om du är värd för din SQL Server instans utanför Azure kan du upprätta en VPN-anslutning mellan SQL Server och SQL Managed Instance med något av följande alternativ:

Tips/Råd

Använd ExpressRoute för bästa nätverksprestanda vid replikering av data. Etablera en gateway med tillräckligt med bandbredd för ditt användningsfall.

SQL Server på Azure Virtual Machines

Att distribuera SQL Server på Azure Virtual Machines i samma Azure virtuella nätverk som är värd för SQL Managed Instance är den enklaste metoden, eftersom nätverksanslutningen automatiskt finns mellan de två instanserna. Mer information finns i Quickstart: Konfigurera en Azure virtuell dator för att ansluta till Azure SQL Managed Instance.

Om din SQL Server på Azure Virtual Machines instans finns i ett annat virtuellt nätverk än din SQL-hanterade instans måste du ansluta de två virtuella nätverken. Virtuella nätverk behöver inte finnas i samma prenumeration för att det här scenariot ska fungera.

Du har två alternativ för att ansluta virtuella nätverk:

Peering för Azure-virtuella nätverk
VNet-till-VNet VPN-gateway (Azure portal, PowerShell, Azure CLI)

Peering är att föredra eftersom det använder Microsoft stamnätverk. Så ur ett anslutningsperspektiv finns det ingen märkbar skillnad i svarstid mellan virtuella datorer i ett peer-kopplat virtuellt nätverk och i samma virtuella nätverk. Peering för virtuella nätverk stöds mellan nätverk i samma region. Global anslutning för virtuella nätverk stöds för instanser som är värdar i undernät skapade efter den 22 september 2020. Mer information finns i Vanliga frågor och svar.

Nätverksportar mellan miljöer

Oavsett anslutningsmekanism måste du uppfylla följande krav för att nätverkstrafiken ska kunna flöda mellan miljöerna:

NSG-reglerna (Network Security Group) i det undernät som är värd för SQL Managed Instance måste tillåta:

Inkommande port 5022 och portintervall 11000-11999 för att ta emot trafik från SQL Server-källans IP-adress
Utgående port 5022 för trafik till mål-SQL Serverns IP-adress

5022-porten kan inte ändras på SQL Managed Instance.

Alla brandväggar i nätverket som är värdar för SQL Server och värdoperativsystemet måste tillåta:

Inkommande port 5022 öppnades för att ta emot trafik från källans IP-intervall för MI-undernätet /24 (till exempel 10.0.0.0/24)
Utgående portar 5022 och portintervallet 11000-11999 öppnades för att skicka trafik till mål-IP-intervallet för MI-undernätet (exempel 10.0.0.0/24)

5022-porten kan anpassas på SQL Server sidan, men portintervallet 11000-11999 måste öppnas som det är.

I följande tabell beskrivs portåtgärder för varje miljö:

Miljö	Lämplig åtgärd
SQL Server (utanför Azure)	Öppna både inkommande och utgående trafik på port 5022 för nätverksbrandväggen till hela undernätets IP-intervall för SQL Managed Instance. Om det behövs gör du samma sak på Windows-brandväggen på SQL Servers värd-OS.
SQL Server (i Azure)	Öppna både inkommande och utgående trafik på port 5022 för nätverksbrandväggen till hela undernätets IP-intervall för SQL Managed Instance. Om det behövs gör du samma sak på Windows-brandväggen på SQL Servers värd-OS. Om du vill tillåta kommunikation på port 5022 skapar du en nätverkssäkerhetsgruppsregel (NSG) i det virtuella nätverk som är värd för den virtuella datorn (VM).
SQL Managed Instance	Skapa en NSG-regel i Azure portalen för att tillåta inkommande och utgående trafik från IP-adressen och nätverken som är värdar för SQL Server på port 5022 och portintervallet 11000-11999.

Om du vill öppna portar i Windows-brandväggen använder du följande PowerShell-skript på Windows värdoperativsystemet för SQL Server-instansen:

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

Följande diagram visar ett exempel på en lokal nätverksmiljö som anger att alla brandväggar i miljön måste ha öppna portar, inklusive os-brandväggen som är värd för SQL Server-instansen och eventuella företagsbrandväggar och gatewayer:

Viktigt!

Du måste öppna portar i varje brandvägg i nätverksmiljön, inklusive värdservern och eventuella företagsbrandväggar eller gatewayer i nätverket. I företagsmiljöer kan du behöva visa nätverksadministratören informationen i det här avsnittet för att öppna ytterligare portar i företagsnätverksskiktet.
Du kan välja att anpassa slutpunkten på SQL Server sidan, men du kan inte ändra eller anpassa portnummer för SQL Managed Instance.
IP-adressintervall för undernät som är värdar för hanterade instanser och SQL Server får inte överlappa varandra.

Lägg till URL:er i listan över tillåtna

Beroende på nätverkssäkerhetsinställningarna kan du behöva lägga till URL:er i listan över tillåtna för SQL Managed Instance FQDN och några av de resurshanteringsslutpunkter som används av Azure.

Lägg till följande resurser i listan över tillåtna resurser:

Det fullständigt kvalificerade domännamnet (FQDN) för din SQL Managed Instance. Till exempel: managedinstance.a1b2c3d4e5f6.database.windows.net.
Microsoft Entra Myndighet
Microsoft Entra Resurs-ID för slutpunkt
Resource Manager slutpunkt
Tjänstslutpunkt

Följ stegen i avsnittet Konfigurera SSMS för myndighetsmoln för att få åtkomst till gränssnittet Tools i SQL Server Management Studio (SSMS) och identifiera specifika URL:er för de resurser i molnet som du behöver lägga till i listan över tillåtna.

Migrera ett certifikat för en TDE-skyddad databas (valfritt)

Om du länkar en SQL Server databas som skyddas av Transparent Data Encryption (TDE) till en SQL-hanterad instans måste du migrera motsvarande krypteringscertifikat från den lokala eller Azure virtuella datorn SQL Server instans till den SQL-hanterade instansen innan du använder länken. Detaljerade steg finns i Migrera ett certifikat för en TDE-skyddad databas till Azure SQL Managed Instance.

SQL Managed Instance databaser som krypteras med tjänsthanterade TDE-nycklar kan inte länkas till SQL Server. Du kan bara länka en krypterad databas till SQL Server om du krypterade den med en kundhanterad nyckel och målservern har åtkomst till samma nyckel som används för att kryptera databasen. Mer information finns i Set up SQL Server TDE with Azure Key Vault.

Anmärkning

Azure Key Vault stöds av SQL Server on Linux från och med Cumulative Update 14 för SQL Server 2022.

Testa nätverksanslutning

Innan du påbörjar migreringen testar du nätverksanslutningen mellan din SQL Server-instans och SQL Managed Instance. Du kan testa anslutningen direkt från Azure portalen som en del av migreringsprocessen. Du kan dock även testa anslutningen manuellt med hjälp av Transact-SQL och SQL Server Agent. Mer information finns i Testa nätverksanslutning.

Följ dessa steg för att testa anslutningen via Azure-portalen:

Välj Migrera data i fönstret Database för din SQL Server instansresurs.
Välj alternativet MI-länk .
Välj de måldatabaser som du vill migrera och använd sedan Nästa: Inställningar för att gå till nästa flik.
På fliken Inställningar anger du namnet på länken och källtillgänglighetsgruppen. Använd sedan Testanslutning för att verifiera nätverksanslutningen mellan SQL Server och SQL Managed Instance:

Tänk på följande:

För att undvika falska negativa resultat måste alla brandväggar i nätverket tillåta ICMP-trafik (Internet Control Message Protocol).
För att undvika falska positiva resultat måste alla brandväggar längs nätverkets väg tillåta trafik på det proprietära SQL Server UCS-protokollet. Blockering av protokollet kan leda till ett lyckat anslutningstest, men länken kan inte skapas.
Avancerade brandväggsinstallationer med skyddsräcken på paketnivå måste konfigureras korrekt för att tillåta trafik mellan SQL Server och SQL Managed Instance.

Begränsningar

Tänk på följande begränsningar:

Begränsningarna för länken Managed Instance gäller för migreringar via Azure-portalen.
Azure-tillägget för SQL Server version 1.1.3238.349 och tidigare stöder endast migrering av en databas i taget via länken. Om du vill migrera flera databaser samtidigt uppgraderar du till Azure-tillägget för SQL Server version 1.1.3348.364 eller senare.
Om du avbryter en migrering krävs sysadmin behörigheter för källinstansen SQL Server. Om din SQL Server-instans inte använder minsta behörighet tilldelar du sysadmin behörigheter manuellt till kontot NT AUTHORITY\SYSTEM.
Att konfigurera en länk via Azure-portalen för migrering är inte kompatibelt med länkar som skapats manuellt, antingen via SQL Server Management Studio (SSMS) eller Transact-SQL (T-SQL). Läs det kända problemet om du vill veta mer.
Övervakning av migreringen via Azure-portalen är endast tillgängligt för SQL Server instanser som uppfyller övervakningskraven licensiering.

Felsökning av vanliga problem

Information om hur du felsöker vanliga problem vid migrering till Azure SQL Managed Instance finns i Felsöka migreringsproblem.

Nästa steg

Migrera till Azure SQL Managed Instance

Feedback

Var den här sidan till hjälp?

Last updated on 2026-04-16

Dela via

Förbered miljön för en Managed Instance-länkmigrering – SQL Server-migrering i Azure Arc

Förutsättningar

SQL Server versioner som stöds

Permissions

Matcha prestandakapacitet mellan repliker

Förbereda din SQL Server-instans

Installera tjänstuppdateringar

Skapa en huvudnyckel för databasen i huvuddatabasen

Förbereda SQL Server 2016-instanser

Aktivera tillgänglighetsgrupper

Aktivera spårningsflaggor vid start

Starta om SQL Server och verifiera konfigurationen

Ställ in databasen för fullständigt återställningsmodell

Importera Azure betrodda rotcertifikatutfärdarnycklar till SQL Server

Aktivera accelererad databasåterställning

Aktivera Service Broker

Konfigurera nätverksanslutning

SQL Server utanför Azure

SQL Server på Azure Virtual Machines

Nätverksportar mellan miljöer

Lägg till URL:er i listan över tillåtna

Migrera ett certifikat för en TDE-skyddad databas (valfritt)

Testa nätverksanslutning

Begränsningar

Felsökning av vanliga problem

Nästa steg

Relaterat innehåll

Feedback

Ytterligare resurser