Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
platí pro:SQL Server
Tento článek vám pomůže připravit prostředí pro migraci instance SQL Server, která je povolena Azure Arc, na Azure SQL Managed Instance v portálu Azure.
Pomocí odkazu můžete migrovat SQL Server databáze do Azure SQL Managed Instance pomocí replikace v reálném čase s distribuovanou skupinou dostupnosti (online migrace):
Poznámka:
- Svůj názor na prostředí migrace můžete poskytnout přímo produktové skupině.
- Migrace až 10 databází najednou počínaje rozšířením Azure pro SQL Server verze
1.1.3348.364.
Požadavky
Pokud chcete migrovat SQL Server databáze do Azure SQL Managed Instance prostřednictvím portálu Azure, potřebujete následující požadavky:
- Aktivní Azure předplatné. Pokud žádné nemáte, vytvořte si bezplatný účet.
- Instance SQL Serveru podporovaná a povolená pomocí Azure Arc s nejnovější verzí rozšíření Azure pro SQL Server. Chcete-li upgradovat své rozšíření, přečtěte si téma Aktualizace rozšíření.
Podporované verze SQL Server
Úrovně služby General Purpose a Business Critical v Azure SQL Managed Instance podporují funkci propojení Managed Instance. Migrace pomocí funkce propojení funguje s edicemi Enterprise, Developer a Standard SQL Server na Windows Server.
Následující tabulka uvádí minimální podporované verze SQL Server odkazu:
| verze SQL Server | Minimální požadovaná servisní aktualizace |
|---|---|
| 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) nebo novější a odpovídající SQL Server 2017 Azure Connect Pack (14.0.3490.10) sestavení |
| SQL Server 2016 (13.x) | SQL Server 2016 SP3 (13.0.6300.2) a odpovídající SQL Server 2016 Azure Connect Pack (13.0.7000.253) sestavení |
| SQL Server 2014 (12.x) a starší | Verze před SQL Server 2016 se nepodporují. |
Zpětná migrace se podporuje jenom pro SQL Server 2025 a SQL Server 2022 ze spravovaných instancí SQL s odpovídajícími zásadami update. Migraci můžete ručně převrátit pomocí jiných nástrojů, jako je nativní zálohování a obnovení, nebo ručně nakonfigurovat propojení v nástroji SSMS.
Povolení
Tato část popisuje oprávnění, která potřebujete k migraci instance SQL Server na SQL Managed Instance prostřednictvím portálu Azure.
Ve zdrojové SQL Server instanci potřebujete následující oprávnění:
- Pokud povolíte nejnižší oprávnění, získáte potřebná oprávnění, jako je správce systému, podle potřeby během procesu migrace databáze.
- Pokud nemůžete použít nejnižší úroveň oprávnění, potřebuje osoba provádějící migraci oprávnění sysadmin ke zdrojové instanci SQL Server. Pokud navíc potřebujete migraci zrušit, přiřaďte účtu oprávnění
NT AUTHORITY\SYSTEMtaké ručně.
Pokud chcete migrovat pomocí odkazu Managed Instance, potřebujete pro cíl SQL Managed Instance jedno z následujících oprávnění:
- Role Kontributora SQL Managed Instance
- Role Přispěvatel nebo Vlastník na úrovni předplatného
Minimální oprávnění najdete v tématu Vlastní oprávnění.
Poznámka:
Uživatelé s oprávněními SqlServerAvailabilityGroups_CreateManagedInstanceLink, SqlServerAvailabilityGroups_failoverMiLink a SqlServerAvailabilityGroups_deleteMiLink v Azure můžou provádět akce na panelu Migrace databáze během migračního procesu, které zvýší oprávnění SQL Serveru účtu používaného rozšířením, včetně role sysadmin.
Sladění výkonové kapacity mezi replikami
Když použijete funkci propojení, je důležité, aby odpovídala kapacitě výkonu mezi SQL Server a SQL Managed Instance. Tato shoda pomáhá vyhnout se problémům s výkonem, pokud sekundární replika nemůže držet krok s replikací z primární repliky nebo po převzetí služeb při selhání. Kapacita výkonu zahrnuje jádra procesoru (nebo virtuální jádra v Azure), paměť a propustnost vstupně-výstupních operací.
Příprava instance SQL Server
Pokud chcete připravit instanci SQL Server, proveďte následující kroky:
- Ověřte, že používáte podporovanou verzi.
- Vytvořte v databázi
master. - Povolte funkci skupin dostupnosti.
- Přidejte správné příznaky trasování při spuštění.
- Restart SQL Server a ověřte konfiguraci.
- Nastavte databázi na úplný model obnovení.
- Importujte klíče důvěryhodné kořenové certifikační autority Azure do serveru SQL Server.
- Povolte zrychlené obnovení databáze, pokud používáte SQL Server 2019 nebo novější, a plánujete jeho použití v cílové spravované instanci SQL.
- Povolte Service Broker, pokud jej plánujete použít v cílové spravované instanci SQL.
Aby se tyto změny projevily, musíte restart SQL Server.
Instalace aktualizací služby
Ujistěte se, že vaše verze SQL Server má nainstalovanou odpovídající aktualizaci údržby, jak je uvedeno v tabulce podpory . Pokud potřebujete nainstalovat všechny aktualizace, musíte během aktualizace restartovat instanci SQL Server.
Pokud chcete zkontrolovat SQL Server verzi, spusťte na SQL Server následující skript Transact-SQL (T-SQL):
-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
Vytvoření hlavního klíče databáze v hlavní databázi
Propojení používá certifikáty k šifrování ověřování a komunikace mezi SQL Server a SQL Managed Instance. Hlavní klíč databáze chrání certifikáty používané odkazem. Pokud už máte hlavní klíč databáze, můžete tento krok přeskočit.
Vytvořte v master databázi hlavní klíč databáze. Místo následujícího skriptu vložte heslo <strong_password> a uchovávejte ho na důvěrném a bezpečném místě. Spusťte tento skript T-SQL na SQL Server:
-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';
Abyste měli jistotu, že máte hlavní klíč databáze, použijte na SQL Server následující skript T-SQL:
-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';
Příprava instancí SQL Server 2016
Pro SQL Server 2016 (13.x) musíte provést dodatečné kroky zdokumentované v Přípravě předpokladů SQL Server 2016 pro odkaz. Tyto další kroky nejsou vyžadovány pro SQL Server 2017 (14.x) a novější verze podporované odkazem.
Povolení skupin dostupnosti
Funkce propojení spoléhá na funkci skupiny dostupnosti AlwaysOn, která je ve výchozím nastavení zakázaná. Další informace najdete v tématu Povolení funkce Skupiny dostupnosti AlwaysOn.
Pokud chcete ověřit, že je funkce skupin dostupnosti povolená, spusťte na SQL Server následující skript 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'
Pokud funkce skupin dostupnosti není povolená, povolte ji následujícím postupem:
Otevřete SQL Server Configuration Manager.
V levém podokně vyberte SQL Server Services.
Klikněte pravým tlačítkem na službu SQL Server a pak vyberte Properties:
Přejděte na kartu Always On Availability Groups.
Zaškrtněte políčko Povolit skupiny dostupnosti AlwaysOn a pak vyberte OK.
- Pokud používáte SQL Server 2016 (13.x) a možnost Enable Always On Availability Groups je zakázaná se zprávou
This computer is not a node in a failover cluster, postupujte podle kroků popsaných v části Příprava předpokladů pro propojení SQL Serveru 2016. Po dokončení těchto kroků se vraťte k tomuto kroku a zkuste to znovu.
- Pokud používáte SQL Server 2016 (13.x) a možnost Enable Always On Availability Groups je zakázaná se zprávou
V dialogovém okně vyberte OK .
Restartujte službu SQL Server.
Povolení příznaků trasování po spuštění
Pokud chcete optimalizovat výkon odkazu, povolte při spuštění následující příznaky trasování:
-
-T1800: Tento příznak trasování optimalizuje výkon, když jsou soubory protokolu pro primární a sekundární repliky ve skupině dostupnosti na discích s různými velikostmi sektorů, například 512 bajtů a 4 kB. Pokud primární i sekundární repliky používají sektor disku o velikosti 4 kB, tento příznak trasování nepotřebujete. Další informace najdete v tématu KB3009974. -
-T9567: Tento příznak trasování povoluje kompresi datového toku pro skupiny dostupnosti během automatického nasazení. Komprese zvyšuje zatížení procesoru, ale může výrazně zkrátit dobu přenosu během inicializace.
Pokud chcete při spuštění povolit tyto příznaky trasování, postupujte následovně:
Otevřete SQL Server Configuration Manager.
V levém podokně vyberte SQL Server Services.
Klikněte pravým tlačítkem na službu SQL Server a vyberte Properties.
Přejděte na kartu Spouštěcí parametry . V části Zadání spouštěcího parametru zadejte
-T1800a vyberte Přidat a přidejte spouštěcí parametr. Pak zadejte-T9567a vyberte Přidat a přidejte další příznak trasování. Výběrem možnosti Použít změny uložte.
Výběrem ok zavřete okno Vlastnosti .
Další informace najdete v syntaxi pro aktivaci sledovacích příznaků.
Restartujte SQL Server a ověřte konfiguraci.
Pokud jste nemuseli upgradovat verzi SQL Server, povolit funkci skupiny dostupnosti nebo přidat příznaky trasování po spuštění, můžete tuto část přeskočit.
Jakmile zajistíte, že používáte podporovanou verzi SQL Server, povolte funkci skupiny dostupnosti AlwaysOn a přidejte příznaky trasování po spuštění, restartujte instanci SQL Server, aby se použily všechny tyto změny:
Otevřete SQL Server Configuration Manager.
V levém podokně vyberte SQL Server Services.
Klikněte pravým tlačítkem na službu SQL Server a pak vyberte Restart.
Po restartování spusťte na SQL Server následující skript T-SQL, který ověří konfiguraci vaší instance 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;
Vaše SQL Server verze by měla být jednou z podporovaných verzí s použitými příslušnými aktualizacemi služby. Měla by být povolena funkce skupin dostupnosti Always On a měly by být povoleny -T1800 a -T9567 trasovací příznaky. Následující snímek obrazovky je příkladem očekávaného výsledku pro správně nakonfigurovanou instanci SQL Server:
Nastavení databáze na úplný model obnovení
Databáze migrované prostřednictvím propojení musí být v úplném modelu obnovení a musí mít aspoň jednu zálohu.
V SQL Server spusťte následující kód pro všechny databáze, které chcete migrovat. Nahraďte <DatabaseName> skutečným názvem databáze.
-- 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
Importovat klíče certifikační autority důvěryhodných kořenových certifikátů Azure do SQL Serveru
Chcete-li důvěřovat certifikátům veřejných klíčů SQL Managed Instance, které Azure vydává, musíte importovat klíče důvěryhodných kořenových certifikačních autorit (CA) Azure do SQL Server.
Klíče kořenové certifikační autority si můžete stáhnout z podrobností certifikační autority Azure. Minimálně si stáhněte certifikáty DigiCert Global Root G2 a Microsoft RSA Root Certificate Authority 2017 a importujte je do instance SQL Serveru.
Poznámka:
Kořenový certifikát v certifikační cestě pro certifikát veřejného klíče SQL Managed Instance vydává důvěryhodná kořenová certifikační autorita Azure (CA). Konkrétní kořenová certifikační autorita se může v průběhu času měnit, protože Azure aktualizuje seznam důvěryhodných certifikačních autorit. Pro zjednodušenou instalaci nainstalujte všechny kořenové certifikáty uvedené v Azure Kořenové Certifikační Autority. Stačí nainstalovat jenom požadovaný klíč certifikační autority tak, že identifikujete vystavitele dříve importovaného SQL Managed Instance veřejného klíče.
Uložte certifikáty místní do instance SQL Server, například do ukázkové cesty C:\certs\<name of certificate>.crt a pak importujte certifikáty z této cesty pomocí následujícího skriptu Transact-SQL. Nahraďte <name of certificate> skutečným názvem certifikátu: DigiCert Global Root G2 a Microsoft RSA Root Certificate Authority 2017, což jsou požadované názvy těchto dvou certifikátů.
-- 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
Návod
Pokud v prostředí SQL Server chybí uložená procedura sp_certificate_add_issuer, vaše instance SQL Server pravděpodobně nemá nainstalovanou aktualizaci služby apropriate.
Nakonec pomocí následujícího zobrazení dynamické správy ověřte všechny vytvořené certifikáty:
-- Run on SQL Server
USE master
SELECT * FROM sys.certificates
Povolení zrychleného obnovení databáze
Pro SQL Server 2019 a novější verze povolte zrychlené obnovení databáze a ujistěte se, že je trvalé úložiště verzí (PVS) nastavené na PRIMARY. Pokud ve zdrojové SQL Server databázi není povolené zrychlené obnovení databáze, nemůžete ji po migraci databáze povolit pro cílovou spravovanou instanci SQL. Pokud trvalé úložiště verzí (PVS) není nastavené PRIMARY, můžete zaznamenat problémy s operacemi obnovení v cílové spravované instanci SQL.
U SQL Server 2017 a starších verzí se akcelerované obnovení databáze nepodporuje, takže tento krok není potřeba.
Chcete-li správně nakonfigurovat zrychlené obnovení databáze ve zdrojové SQL Server databázi, postupujte takto:
Povolte zrychlené obnovení databáze spuštěním následujícího skriptu Transact-SQL na SQL Server:
ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;Úložiště trvalých verzí (PVS) musí být na zdrojové databázi nastaveno na
PRIMARY, což je výchozí konfigurace. Pokud se to dříve změnilo, musíte ho před zahájením migrace změnit zpátky na PRIMÁRNÍ .
Povolit Service Broker
Service Broker je ve výchozím nastavení povolená pro všechny verze SQL Server. Pokud byla služba Service Broker zakázaná a plánujete ji používat na SQL Managed Instance, povolte službu Service Broker ve zdrojové SQL Server databázi před migrací na SQL Managed Instance. Pokud služba Service Broker není ve zdrojové SQL Server databázi povolená, nemůžete ji použít v cílové spravované instanci SQL.
Pokud chcete zkontrolovat, jestli je služba Service Broker povolená, spusťte v instanci SQL Server následující skript Transact-SQL:
SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';
Pokud je služba Service Broker zakázaná, povolte ji spuštěním následujícího skriptu Transact-SQL ve zdrojové databázi SQL Server:
USE master;
GO
ALTER DATABASE [<database name>]
SET ENABLE_BROKER;
GO
Konfigurace síťového připojení
Aby propojení fungovalo, musíte mít síťové připojení mezi SQL Server a SQL Managed Instance. Možnost sítě, kterou zvolíte, závisí na tom, jestli je vaše instance SQL Server v síti Azure.
SQL Server mimo Azure
Pokud hostujete instanci SQL Server mimo Azure, můžete vytvořit připojení VPN mezi SQL Server a SQL Managed Instance pomocí některé z těchto možností:
Návod
Pokud chcete dosáhnout nejlepšího výkonu sítě při replikaci dat, použijte ExpressRoute. Zřiďte bránu s dostatečnou šířkou pásma pro váš případ použití.
SQL Server na virtuálních počítačích Azure
Nasazení SQL Server on Azure Virtual Machines ve stejné Azure virtuální síti, která hostuje SQL Managed Instance, je nejjednodušší metoda, protože mezi těmito dvěma instancemi automaticky existuje síťové připojení. Další informace najdete v tématu Quickstart: Konfigurace virtuálního počítače Azure pro připojení k Azure SQL Managed Instance.
Pokud je vaše instance SQL Server on Azure Virtual Machines v jiné virtuální síti než vaše spravovaná instance SQL, musíte obě virtuální sítě propojit. Virtuální sítě nemusí být ve stejném předplatném, aby tento scénář fungoval.
Virtuální sítě můžete propojit dvěma způsoby:
- propojování virtuálních sítí Azure
- Brána VPN typu VNet-to-VNet (portál Azure, PowerShell, Azure CLI)
Peering je vhodnější, protože používá páteřní síť Microsoft. Z hlediska připojení tedy neexistuje žádný znatelný rozdíl v latenci mezi virtuálními počítači v partnerské virtuální síti a ve stejné virtuální síti. Peering virtuálních sítí je podporováno mezi sítěmi ve stejném regionu. Globální propojení virtuálních sítí se podporuje pro instance hostované v podsítích vytvořených po 22. září 2020. Další informace najdete v tématu Nejčastější dotazy.
Síťové porty mezi prostředími
Bez ohledu na mechanismus připojení musíte splňovat následující požadavky pro tok síťového provozu mezi prostředími:
Pravidla skupiny zabezpečení sítě (NSG) v podsíti, která hostuje SQL Managed Instance, musí umožňovat:
- Příchozí port 5022 a rozsah portů 11000–11999 pro příjem provozu ze zdrojové SQL Server IP adresy
- Odchozí port 5022 pro odesílání provozu do cílové SQL Server IP adresy
Port 5022 nejde změnit na SQL Managed Instance.
Všechny brány firewall v síti, stejně jako hostitelský operační systém pro SQL Server, musí povolit:
- Příchozí port 5022 otevřený pro příjem provozu ze zdrojového rozsahu IP adres podsítě MI /24 (například 10.0.0.0/24)
- Odchozí porty 5022 a rozsah portů 11000–11999 otevřené pro odesílání provozu do cílového rozsahu IP adres podsítě MI (příklad 10.0.0.0/24)
Port 5022 lze přizpůsobit na straně SQL Server, ale rozsah portů 11000–11999 musí být otevřený tak, jak je.
Následující tabulka popisuje akce portů pro každé prostředí:
| Životní prostředí | Co dělat |
|---|---|
| SQL Server (mimo Azure) | Otevřete příchozí i odchozí provoz na portu 5022 pro bránu firewall sítě do celého rozsahu IP adres podsítě SQL Managed Instance. V případě potřeby proveďte totéž na hostitelském OS SQL Serveru v bráně Windows. |
| SQL Server (v Azure) | Otevřete příchozí i odchozí provoz na portu 5022 pro bránu firewall sítě do celého rozsahu IP adres podsítě SQL Managed Instance. V případě potřeby proveďte totéž na hostitelském OS SQL Serveru v bráně Windows. Pokud chcete povolit komunikaci na portu 5022, vytvořte ve virtuální síti pravidlo skupiny zabezpečení sítě (NSG), které je hostitelem virtuálního počítače. |
| SQL Managed Instance | Vytvořte pravidlo NSG na portálu Azure, abyste povolili příchozí a odchozí provoz z IP adresy a sítě, která hostí SQL Server, na portu 5022 a v rozsahu portů 11000–11999. |
Pokud chcete otevřít porty v bráně Windows Firewall, použijte následující skript PowerShellu v operačním systému hostitele SQL Server instance Windows:
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
Následující diagram ukazuje příklad místního síťového prostředí, což znamená, že všechny brány firewall v prostředí musí mít otevřené porty, včetně brány firewall operačního systému, která hostuje instanci SQL Serveru, a jakékoli podnikové brány firewall a vstupní brány.
Důležité
- Musíte otevřít porty v každém firewallu v síťovém prostředí, včetně hostitelského serveru a všech podnikových firewallů nebo brán v síti. V podnikových prostředích možná budete muset zobrazit informace správce sítě v této části, abyste mohli otevřít další porty v podnikové síťové vrstvě.
- I když se můžete rozhodnout přizpůsobit koncový bod na SQL Server straně, nemůžete změnit ani přizpůsobit čísla portů pro SQL Managed Instance.
- Rozsahy IP adres podsítí hostující spravované instance a SQL Server se nesmí překrývat.
Přidání adres URL do seznamu povolených adres
V závislosti na nastavení zabezpečení vaší sítě možná budete muset přidat adresy URL do seznamu povolených jak pro plně kvalifikovaný název domény (FQDN) SQL Managed Instance, tak pro některé koncové body správy prostředků používané službou Azure.
Do seznamu povolených přidejte následující zdroje informací:
- Plně kvalifikovaný název domény (FQDN) vašeho SQL Managed Instance. Například:
managedinstance.a1b2c3d4e5f6.database.windows.net. - Autorita Microsoft Entra
- ID prostředku koncového bodu Microsoft Entra
- Koncový bod Resource Manager
- Koncový bod služby
Postupujte podle kroků v části Konfigurujte SSMS pro cloudy pro státní správu a přejděte k rozhraní Tools v SQL Server Management Studio (SSMS) a určete konkrétní adresy URL pro prostředky v cloudu, které potřebujete přidat do seznamu povolených.
Migrace certifikátu databáze chráněné transparentním šifrováním dat (volitelné)
Pokud propojíte databázi SQL Server chráněnou Transparent Data Encryption (TDE) se spravovanou instancí SQL, musíte před použitím odkazu migrovat odpovídající šifrovací certifikát z místního nebo Azure virtuálního počítače SQL Server instance do spravované instance SQL. Podrobný postup najdete v tématu Migrace certifikátu databáze chráněné transparentním šifrováním dat do Azure SQL Managed Instance.
SQL Managed Instance databáze, které jsou šifrované pomocí klíčů transparentního šifrování dat spravované službou, není možné propojit s SQL Server. Šifrovanou databázi můžete propojit pouze s SQL Server pokud jste ji zašifrovali pomocí klíče spravovaného zákazníkem a cílový server má přístup ke stejnému klíči, který se používá k šifrování databáze. Další informace najdete v tématu Konfigurace šifrování dat SQL Server pomocí Azure Key Vault.
Poznámka:
SQL Server on Linux podporuje Azure Key Vault počínaje Cumulative Update 14 pro SQL Server 2022.
Testování připojení k síti
Před zahájením migrace otestujte síťové připojení mezi vaší instancí SQL Server a SQL Managed Instance. Připojení můžete otestovat přímo z portálu Azure v rámci procesu migrace. Připojení ale můžete otestovat také ručně pomocí Transact-SQL a SQL Server Agent. Další informace najdete v tématu Testování připojení k síti.
Pokud chcete otestovat připojení prostřednictvím portálu Azure, postupujte takto:
Vyberte Migrate data v podokně Database migration pro prostředek vaší instance SQL Serveru.
Vyberte možnost MI odkaz.
Vyberte cílové databáze, které chcete migrovat, a pak pomocí možnosti Další: Nastavení přejděte na další kartu.
Na kartě Nastavení zadejte název odkazu a skupinu dostupnosti zdroje. Pak pomocí Test připojení ověřte síťové připojení mezi SQL Server a SQL Managed Instance:
Snímek obrazovky, který zobrazuje tlačítko pro test připojení služby Managed Instance.
Vezměte v úvahu následující body:
- Aby se zabránilo falešně negativním výsledkům, musí všechny brány firewall v síťové cestě umožňovat provoz protokolu ICMP (Internet Control Message Protocol).
- Aby se zabránilo falešně pozitivním výsledkům, musí všechny firewally v rámci síťové trasy umožňovat provoz na proprietárním protokolu SQL Server UCS. Blokování protokolu může vést k úspěšnému testu připojení, ale propojení se nepodaří vytvořit.
- Pokročilá nastavení brány firewall s mantinely na úrovni paketů musí být správně nakonfigurovaná tak, aby umožňovala provoz mezi SQL Server a SQL Managed Instance.
Omezení
Berte v úvahu následující omezení:
- Omezení odkazu Managed Instance se vztahují na migrace prostřednictvím portálu Azure.
- rozšíření Azure pro SQL Server verzi
1.1.3238.349a starší podporuje migraci pouze jedné databáze najednou prostřednictvím odkazu. Pokud chcete migrovat více databází současně, upgradujte na rozšíření Azure pro SQL Server verzi1.1.3348.364nebo novější. - Zrušení migrace vyžaduje oprávnění sysadmin ke zdrojové instanci SQL Server. Pokud vaše instance SQL Server nepoužívá nejnižší oprávnění, ručně přiřaďte oprávnění sysadmin k účtu
NT AUTHORITY\SYSTEM. - Konfigurace odkazu prostřednictvím portálu Azure pro účely migrace není kompatibilní s odkazy vytvořenými ručně, buď prostřednictvím SQL Server Management Studio (SSMS), nebo Transact-SQL (T-SQL). Další informace najdete v známém problému .
- Monitorování migrace prostřednictvím portálu Azure je dostupné jenom pro SQL Server instance, které splňují požadavky na monitorování licencí.
Řešení běžných potíží
Informace o řešení běžných problémů při migraci na Azure SQL Managed Instance najdete v tématu Troubleshoot – problémy s migrací.
Další krok
Související obsah
- osvědčené postupy pro propojení Managed Instance
- Přehled migrace SQL Serveru v Azure Arc
- Připravené prostředí pro migraci LRS – migrace SQL Server v Azure Arc
- SQL Server povolený pomocí Azure Arc
- Zpětná vazba k zkušenostem s migrací přímo směřuje do produktové skupiny
- Migrace na Azure SQL Managed Instance – migrace SQL Server v Azure Arc