Przygotowywanie środowiska do migracji linków Managed Instance — migracja SQL Server w Azure Arc

Dotyczy:SQL Server

Ten artykuł pomaga przygotować swoje środowisko do migracji wystąpienia SQL Server zintegrowanego z Azure Arc na Azure SQL Managed Instance w portalu Azure.

Za pomocą linku można migrować bazy danych SQL Server do Azure SQL Managed Instance przy użyciu replikacji w czasie rzeczywistym z rozproszoną grupą dostępności (migracja online):

Diagram przedstawiający Managed Instance link migration.

Uwaga / Notatka

Możesz przekazać opinię na temat doświadczenia z migracji bezpośrednio do grupy produktów.
Migruj naraz do 10 baz danych, rozpoczynając od rozszerzenia Azure dla SQL Server w wersji 1.1.3348.364.

Wymagania wstępne

Aby przeprowadzić migrację baz danych SQL Server do Azure SQL Managed Instance za pośrednictwem portalu Azure, potrzebne są następujące wymagania wstępne:

Aktywna subskrypcja Azure. Jeśli jej nie masz, utwórz bezpłatne konto.
Obsługiwane wystąpienie SQL Server włączone z pomocą Azure Arc z najnowszą wersją rozszerzenia Azure dla SQL Server. Aby uaktualnić rozszerzenie, zobacz Uaktualnianie rozszerzenia.

Obsługiwane wersje SQL Server

Zarówno warstwy usługi Ogólnego Przeznaczenia, jak i Krytycznego dla Biznesu Azure SQL Managed Instance obsługują łącze Managed Instance. Funkcja migracji z linkiem współpracuje z wersjami Enterprise, Developer i Standard SQL Server w Windows Server.

W poniższej tabeli wymieniono minimalną obsługiwaną wersję SQL Server linku:

wersja SQL Server	Minimalna wymagana aktualizacja obsługi
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) lub nowszy oraz pasująca kompilacja pakietu SQL Server 2017 Azure Connect (14.0.3490.10)
SQL Server 2016 (13.x)	SQL Server 2016 SP3 (13.0.6300.2) i pasujący SQL Server 2016 Azure pakiet Connect (13.0.7000.253) kompilacja
SQL Server 2014 (12.x) i starsze	Wersje przed SQL Server 2016 nie są obsługiwane.

Migracja odwrotna jest obsługiwana tylko do SQL Server 2025 i SQL Server 2022 z wystąpień zarządzanych SQL zgodnie z odpowiednią polityką aktualizacji. Migrację można ręcznie odwrócić za pomocą innych narzędzi, takich jak natywna kopia zapasowa i przywracanie, lub ręcznie skonfigurować link w programie SSMS.

Permissions

W tej sekcji opisano uprawnienia, które są potrzebne do migracji wystąpienia SQL Server do SQL Managed Instance za pośrednictwem portalu Azure.

W wystąpieniu źródłowym SQL Server potrzebne są następujące uprawnienia:

Jeśli włączysz najmniejsze uprawnienia, niezbędne uprawnienia, takie jak sysadmin , są przyznawane zgodnie z potrzebami podczas procesu migracji bazy danych.
Jeśli nie możesz użyć zasady najmniejszych uprawnień, osoba wykonująca migrację musi mieć uprawnienia sysadmin na wystąpieniu źródłowym SQL Server. Ponadto, jeśli musisz anulować migrację, również ręcznie przypisz uprawnienia administratora systemu do NT AUTHORITY\SYSTEM konta.

Aby przeprowadzić migrację za pomocą linku Managed Instance, musisz mieć jedno z następujących uprawnień w SQL Managed Instance docelowym:

rola współautora SQL Managed Instance
Rola współautora lub właściciela na poziomie subskrypcji

Aby uzyskać minimalne uprawnienia, zobacz Uprawnienia niestandardowe.

Uwaga / Notatka

Użytkownicy z uprawnieniami SqlServerAvailabilityGroups_CreateManagedInstanceLink, SqlServerAvailabilityGroups_failoverMiLink i SqlServerAvailabilityGroups_deleteMiLink w Azure mogą wykonywać akcje w okienku migracji bazy danych podczas procesu migracji, co podnosi uprawnienia SQL Server konta używanego przez rozszerzenie, w tym rolę sysadmin.

Dopasowywanie wydajności między replikami

Jeśli używasz funkcji linku, ważne jest, aby dopasować wydajność systemową między SQL Server a Instancją Zarządzaną SQL. To dopasowanie pomaga uniknąć problemów z wydajnością, jeśli replika pomocnicza nie jest w stanie dotrzymać tempa replikacji z repliki podstawowej lub po wystąpieniu przełączenia awaryjnego. Wydajność obejmuje rdzenie procesora CPU (lub rdzenie wirtualne [vCores] w Azure), pamięć i przepływność operacji we/wy.

Przygotuj instancję SQL Server

Aby przygotować wystąpienie SQL Server, wykonaj następujące kroki:

Sprawdź, czy korzystasz z obsługiwanej wersji.
Utwórz klucz główny bazy danych w master bazie danych.
Włącz funkcję grup dostępności.
Dodaj odpowiednie flagi śledzenia podczas uruchamiania.
Restart SQL Server i zweryfikuj konfigurację.
Ustaw bazę danych na pełny model odzyskiwania.
Importuj klucze głównego urzędu certyfikacji zaufane przez Azure do SQL Server.
Włącz przyspieszone odzyskiwanie bazy danych, jeśli korzystasz z SQL Server 2019 lub nowszego i planujesz jego użycie w docelowym wystąpieniu zarządzanym SQL.
Włącz usługę Service Broker , jeśli planujesz używać go w docelowym wystąpieniu zarządzanym SQL.

Musisz restart SQL Server aby te zmiany zaczęły obowiązywać.

Instalowanie aktualizacji usługi

Upewnij się, że w Twojej wersji SQL Server zainstalowano odpowiednią aktualizację serwisową, jak wymieniono w tabeli zgodności wersji version supportability table. Jeśli musisz zainstalować jakiekolwiek aktualizacje, musisz ponownie uruchomić wystąpienie SQL Server podczas aktualizacji.

Aby sprawdzić wersję SQL Server, uruchom następujący skrypt Transact-SQL (T-SQL) w SQL Server:

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

Utwórz klucz główny bazy danych w bazie danych głównej.

Link używa certyfikatów do szyfrowania uwierzytelniania i komunikacji między SQL Server i SQL Managed Instance. Klucz główny bazy danych chroni certyfikaty używane przez łącze. Jeśli masz już klucz główny bazy danych, możesz pominąć ten krok.

Utwórz klucz główny bazy danych w master bazie danych. Wstaw hasło zamiast <strong_password> w poniższym skrypcie i zachowaj je w bezpiecznym miejscu. Uruchom ten skrypt języka T-SQL w SQL Server:

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

Aby upewnić się, że masz klucz główny bazy danych, użyj następującego skryptu języka T-SQL w SQL Server:

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

Przygotowywanie wystąpień SQL Server 2016

W przypadku SQL Server 2016 (13.x) należy wykonać dodatkowe kroki opisane w dokumencie Prepare SQL Server 2016 prerequisites for the link. Te dodatkowe kroki nie są wymagane w przypadku SQL Server 2017 (14.x) i nowszych wersji obsługiwanych przez link.

Włączanie grup dostępności

Funkcja linku korzysta z funkcji Zawsze włączone grupy dostępności, która jest domyślnie wyłączona. Aby uzyskać więcej informacji, zobacz Włączanie funkcji Grup dostępności Always On.

Aby upewnić się, że funkcja grup dostępności jest włączona, uruchom następujący skrypt języka T-SQL w 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'

Jeśli funkcja grup dostępności nie jest włączona, wykonaj następujące kroki, aby ją włączyć:

Otwórz SQL Server Configuration Manager.
Wybierz pozycję SQL Server Services w okienku po lewej stronie.
Kliknij prawym przyciskiem myszy usługę SQL Server, a następnie wybierz pozycję Właściwości:
Przejdź do zakładki Always On Availability Groups.
Zaznacz pole wyboru Włącz zawsze włączone grupy dostępności , a następnie wybierz przycisk OK.
- Jeśli używasz SQL Server 2016 (13.x) i opcja Włącz Zawsze włączone grupy dostępności jest wyłączona z komunikatem This computer is not a node in a failover cluster, wykonaj kroki opisane w Przygotowanie wymagań wstępnych dla SQL Server 2016 dla linku. Po wykonaniu tych kroków wróć do tego kroku i spróbuj ponownie.
Wybierz przycisk OK w oknie dialogowym.
Uruchom ponownie usługę SQL Server.

Włącz flagi śledzenia uruchamiania

Aby zoptymalizować wydajność linku, włącz następujące flagi śledzenia podczas uruchamiania:

-T1800: Flaga śledzenia optymalizuje wydajność, gdy pliki dzienników dla głównych i pomocniczych replik w grupie dostępności są umieszczone na dyskach o różnych rozmiarach sektorów, takich jak 512 bajtów i 4 KB. Jeśli zarówno repliki podstawowe, jak i pomocnicze używają rozmiaru sektora dysku o rozmiarze 4 KB, nie potrzebujesz tej flagi śledzenia. Aby uzyskać więcej informacji, zobacz KB3009974.
-T9567: Ta flaga śledzenia umożliwia kompresję strumienia danych dla grup dostępności podczas automatycznego rozmieszczania. Kompresja zwiększa obciążenie procesora, ale może znacznie skrócić czas transferu podczas seedowania.

Aby włączyć te flagi śledzenia podczas uruchamiania, wykonaj następujące kroki:

Otwórz SQL Server Configuration Manager.
Wybierz pozycję SQL Server Services w okienku po lewej stronie.
Kliknij prawym przyciskiem myszy usługę SQL Server, a następnie wybierz pozycję Właściwości.
Przejdź do karty Parametry uruchamiania. W obszarze Określ parametr uruchamiania wprowadź -T1800 i wybierz pozycję Dodaj, aby dodać parametr startowy. Następnie wprowadź -T9567 i wybierz pozycję Dodaj , aby dodać inną flagę śledzenia. Wybierz pozycję Zastosuj, aby zapisać zmiany.
Wybierz przycisk OK , aby zamknąć okno Właściwości .

Aby uzyskać więcej informacji, zobacz składnię włączenia flag śledzenia.

Uruchom ponownie SQL Server i zweryfikuj konfigurację

Jeśli nie musisz uaktualnić wersji SQL Server, włączyć funkcję grupy dostępności lub dodać flagi śledzenia uruchamiania, możesz pominąć tę sekcję.

Po upewnieniu się, że korzystasz z obsługiwanej wersji SQL Server, włącz funkcję grupy dostępności Always On i dodaj flagi śladowe uruchamiania, a następnie uruchom ponownie wystąpienie SQL Server, aby zastosować wszystkie te zmiany.

Otwórz SQL Server Configuration Manager.
Wybierz pozycję SQL Server Services w okienku po lewej stronie.
Kliknij prawym przyciskiem myszy usługę SQL Server, a następnie wybierz pozycję Restart.

Po ponownym uruchomieniu uruchom następujący skrypt języka T-SQL w SQL Server, aby zweryfikować konfigurację wystąpienia 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;

Wersja SQL Server powinna być jedną z obsługiwanych wersji z zastosowanymi odpowiednimi aktualizacjami usług. Funkcja Always On availability groups powinna być włączona, a flagi śledzenia -T1800 oraz -T9567 powinny być aktywowane. Poniższy zrzut ekranu to przykład oczekiwanego wyniku dla prawidłowo skonfigurowanej instancji SQL Server.

Zrzut ekranu przedstawiający oczekiwany wynik w S S M S.

Ustawianie bazy danych na model pełnego odzyskiwania

Bazy danych migrowane za pośrednictwem linku muszą znajdować się w modelu pełnego odzyskiwania i mieć co najmniej jedną kopię zapasową.

Uruchom następujący kod w SQL Server dla wszystkich baz danych, które chcesz zmigrować. Zastąp <DatabaseName> rzeczywistą nazwą bazy danych.

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

Importowanie kluczy głównego urzędu certyfikacji zaufanego przez Azure do SQL Server

Aby ufać certyfikatom kluczy publicznych SQL Managed Instance wystawianym przez Azure, należy zaimportować do SQL Server klucze urzędu certyfikacji głównego zaufanego przez Azure.

Klucze urzędu certyfikacji nadrzędnego można pobrać z Szczegóły usługi Azure Certificate Authority. Pobierz co najmniej certyfikaty DigiCert Global Root G2 i Microsoft RSA Root Certificate Authority 2017 i zaimportuj je do wystąpienia SQL Server.

Uwaga / Notatka

Certyfikat główny w ścieżce certyfikacji dla certyfikatu klucza publicznego SQL Managed Instance jest wystawiany przez zaufany główny urząd certyfikacji "Azure". Określony główny urząd certyfikacji może ulec zmianie w miarę upływu czasu, ponieważ Azure aktualizuje listę zaufanych urzędów certyfikacji. W przypadku uproszczonej konfiguracji zainstaluj wszystkie certyfikaty urzędów certyfikacji głównej wymienione w Azure Root Certificate Authorities. Można zainstalować tylko wymagany klucz urzędu certyfikacji, identyfikując wystawcę klucza publicznego SQL Managed Instance, który został wcześniej zaimportowany.

Zapisz certyfikaty lokalne w wystąpieniu SQL Server, na przykład w przykładowej ścieżce C:\certs\<name of certificate>.crt, a następnie zaimportuj certyfikaty z tej ścieżki przy użyciu następującego skryptu Transact-SQL. Zastąp <name of certificate> rzeczywistą nazwą certyfikatu: DigiCert Global Root G2 i Microsoft RSA Root Certificate Authority 2017, które są wymaganymi nazwami tych dwóch certyfikatów.

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

Wskazówka

Jeśli w środowisku SQL Server brakuje procedury składowanej sp_certificate_add_issuer, to prawdopodobnie instancja SQL Server nie ma zainstalowanej odpowiedniej aktualizacji usługi .

Na koniec sprawdź wszystkie utworzone certyfikaty przy użyciu następującego dynamicznego widoku zarządzania (DMV):

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

Włączanie przyspieszonego odzyskiwania bazy danych

W przypadku SQL Server 2019 i nowszych wersji włącz przyspieszone odzyskiwanie bazy danych i upewnij się, że magazyn wersji trwałej (PVS) jest odpowiednio skonfigurowany, aby działał jak ustalono w PRIMARY. Jeśli przyspieszone odzyskiwanie bazy danych nie jest włączone w źródłowej bazie danych SQL Server, nie można włączyć jej w docelowym wystąpieniu zarządzanym SQL po przeprowadzeniu migracji bazy danych. Jeśli magazyn wersji trwałej (PVS) nie jest ustawiony na PRIMARY, mogą wystąpić problemy z operacjami przywracania w docelowym instancji SQL zarządzanej.

W przypadku SQL Server 2017 i starszych wersji przyspieszone odzyskiwanie bazy danych nie jest obsługiwane, więc ten krok nie jest konieczny.

Aby prawidłowo skonfigurować przyspieszone odzyskiwanie bazy danych w źródłowej bazie danych SQL Server, wykonaj następujące kroki:

Włącz przyspieszone odzyskiwanie bazy danych, uruchamiając następujący skrypt Transact-SQL w SQL Server:
```
ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
```
Magazyn wersji trwałej (PVS) musi być ustawiony na PRIMARY dla źródłowej bazy danych, co jest konfiguracją domyślną. Jeśli ta zmiana została wcześniej zmieniona, przed rozpoczęciem migracji należy zmienić ją z powrotem na PRIMARY .

Włącz Service Broker

Service Broker jest domyślnie włączona dla wszystkich wersji SQL Server. Jeśli usługa Service Broker została wyłączona i planujesz używać jej w SQL Managed Instance, przed przeprowadzeniem migracji do SQL Managed Instance włącz usługę Service Broker w źródłowej bazie danych SQL Server. Jeśli usługa Service Broker nie jest włączona w źródłowej bazie danych SQL Server, nie można jej używać w docelowym wystąpieniu zarządzanym SQL.

Aby sprawdzić, czy usługa Service Broker jest włączona, uruchom następujący skrypt Transact-SQL w wystąpieniu SQL Server:

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

Jeśli usługa Service Broker jest wyłączona, włącz ją, uruchamiając następujący skrypt Transact-SQL w źródłowej bazie danych SQL Server:

USE master;
GO

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

Konfigurowanie łączności sieciowej

Aby połączenie działało, musisz mieć łączność sieciową między SQL Server i SQL Managed Instance. Wybrana opcja sieci zależy od tego, czy wystąpienie SQL Server znajduje się w sieci Azure.

SQL Server poza Azure

Jeśli hostujesz wystąpienie SQL Server poza Azure, możesz ustanowić połączenie sieci VPN między SQL Server i SQL Managed Instance przy użyciu jednej z następujących opcji:

Wskazówka

Aby uzyskać najlepszą wydajność sieci podczas replikowania danych, użyj usługi ExpressRoute. Aprowizuj bramę z wystarczającą przepustowością dla twojego przypadku użycia.

SQL Server na platformie Azure Virtual Machines

Wdrażanie SQL Server on Azure Virtual Machines w tej samej sieci wirtualnej Azure, która hostuje SQL Managed Instance, jest najprostszą metodą, ponieważ łączność sieciowa automatycznie istnieje między dwoma wystąpieniami. Aby uzyskać więcej informacji, zobacz Quickstart: Configure an Azure VM to connect to Azure SQL Managed Instance (Konfigurowanie maszyny wirtualnej Azure SQL Managed Instance

Jeśli wystąpienie SQL Server on Azure Virtual Machines znajduje się w innej sieci wirtualnej niż wystąpienie zarządzane SQL, musisz połączyć te dwie sieci wirtualne. Sieci wirtualne nie muszą znajdować się w tej samej subskrypcji, aby ten scenariusz działał.

Dostępne są dwie opcje łączenia sieci wirtualnych:

Azure komunikacja równorzędna sieci wirtualnych
Brama sieci VPN między sieciami wirtualnymi (portal Azure, PowerShell, Azure CLI)

Peering jest preferowane, ponieważ korzysta z sieci szkieletowej Microsoft. Z perspektywy łączności nie ma zauważalnej różnicy w opóźnieniu między maszynami wirtualnymi w równorzędnej sieci wirtualnej i w tej samej sieci wirtualnej. Peering sieci wirtualnych jest obsługiwany między sieciami w tym samym regionie. Globalne równorzędne połączenia sieci wirtualnych są obsługiwane dla instancji hostowanych w podsieciach utworzonych po 22 września 2020 r. Aby uzyskać więcej informacji, zobacz Często zadawane pytania.

Porty sieciowe między środowiskami

Niezależnie od mechanizmu łączności, należy spełnić następujące wymagania dotyczące ruchu sieciowego do przepływu między środowiskami:

Reguły grupy zabezpieczeń sieciowych w podsieciach, które hostują instancję zarządzaną SQL, muszą zezwalać na:

Port przychodzący 5022 i zakres portów 11000–11999 do odbierania ruchu ze źródłowego adresu IP SQL Server
Port wychodzący 5022 do przesyłania ruchu do docelowego adresu IP serwera SQL

Nie można zmienić portu 5022 na SQL Managed Instance.

Wszystkie zapory na sieci, która hostuje SQL Server, oraz system operacyjny hosta muszą zezwalać na:

Port wejściowy 5022 został otwarty w celu odbierania ruchu ze źródłowego zakresu adresów IP podsieci MI /24 (na przykład 10.0.0.0/24)
Porty wychodzące 5022 oraz zakres portów 11000-11999 zostały otwarte do wysyłania ruchu do docelowego zakresu adresów IP w podsieci MI (na przykład 10.0.0.0/24).

Port 5022 można dostosować po stronie SQL Server, ale zakres portów 11000-11999 musi być otwarty w następujący sposób.

W poniższej tabeli opisano akcje portów dla każdego środowiska:

Środowisko	Postępowanie
SQL Server (poza Azure)	Otwórz ruch przychodzący i wychodzący na porcie 5022 na firewallu dla całego zakresu adresów IP podsieci usługi SQL Managed Instance. W razie potrzeby wykonaj to samo w zaporze systemu operacyjnego hosta SQL Server Windows.
SQL Server (w Azure)	Otwórz ruch przychodzący i wychodzący na porcie 5022 na firewallu dla całego zakresu adresów IP podsieci usługi SQL Managed Instance. W razie potrzeby wykonaj to samo w zaporze systemu operacyjnego hosta SQL Server Windows. Aby zezwolić na komunikację na porcie 5022, utwórz regułę sieciowej grupy zabezpieczeń w sieci wirtualnej, która hostuje maszynę wirtualną.
SQL Managed Instance	Utwórz regułę sieciowej grupy zabezpieczeń w portalu Azure, aby zezwolić na ruch przychodzący i wychodzący z adresu IP oraz sieci hostujących SQL Server na porcie 5022 i zakresie portów 11000-11999.

Aby otworzyć porty w Zaporze systemu Windows, użyj następującego skryptu PowerShell w systemie operacyjnym Windows na komputerze-host wystąpienia SQL Server.

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

Na poniższym diagramie przedstawiono przykład lokalnego środowiska sieciowego, który pokazuje, że wszystkie zapory w środowisku muszą mieć otwarte porty, w tym zaporę systemu operacyjnego, która hostuje wystąpienie SQL Server, oraz wszelkie zapory i bramy korporacyjne.

Ważne

Należy otworzyć porty w każdej zaporze sieciowej w środowisku, w tym na serwerze hostującym oraz we wszelkich firmowych zaporach i bramkach w sieci. W środowiskach firmowych może być konieczne wyświetlenie administratorowi sieci informacji w tej sekcji, aby ułatwić otwieranie dodatkowych portów w warstwie sieci firmowej.
Chociaż możesz dostosować punkt końcowy po stronie SQL Server, nie można zmienić ani dostosować numerów portów dla SQL Managed Instance.
Zakresy adresów IP podsieci zawierających zarządzane instancje i SQL Server nie mogą się nakładać.

Dodaj adresy URL do listy dopuszczonych

W zależności od ustawień zabezpieczeń sieci możesz potrzebować dodać adresy URL do listy dozwolonych dla w pełni kwalifikowanej nazwy domeny (FQDN) usługi SQL Managed Instance oraz niektórych punktów końcowych zarządzania zasobami używanych przez Azure.

Dodaj następujące zasoby do listy dozwolonych:

Pełna nazwa domeny (FQDN) zarządzanej instancji SQL. Na przykład: managedinstance.a1b2c3d4e5f6.database.windows.net.
urząd Microsoft Entra
identyfikator zasobu punktu końcowego Microsoft Entra
Punkt końcowy Menedżer Zasobów
Punkt końcowy usługi

Wykonaj kroki opisane w sekcji Configure SSMS for government clouds w celu uzyskania dostępu do Tools interfejsu w SQL Server Management Studio (SSMS) i zidentyfikuj określone adresy URL zasobów w chmurze, które należy dodać do listy dozwolonych.

Migrowanie certyfikatu bazy danych chronionej przez funkcję TDE (opcjonalnie)

Jeśli łączysz bazę danych SQL Server chronioną przez Transparent Data Encryption (TDE) z zarządzanym wystąpieniem SQL, przed użyciem linku musisz przeprowadzić migrację odpowiedniego certyfikatu szyfrowania z lokalnego wystąpienia SQL Server lub z wystąpienia SQL Server na maszynie wirtualnej Azure do zarządzanego wystąpienia SQL. Aby uzyskać szczegółowe instrukcje, zobacz Migracja certyfikatu bazy danych chronionej przez TDE do usługi Azure SQL Managed Instance.

Bazy danych na SQL Managed Instance, które są zaszyfrowane z użyciem kluczy TDE zarządzanych przez usługę, nie mogą być łączone z SQL Server. Zaszyfrowaną bazę danych można połączyć tylko z SQL Server, jeśli zaszyfrowano ją przy użyciu klucza zarządzanego przez klienta, a serwer docelowy ma dostęp do tego samego klucza używanego do szyfrowania bazy danych. Aby uzyskać więcej informacji, zobacz Konfigurowanie funkcji TDE SQL Server za pomocą Azure Key Vault.

Uwaga / Notatka

Azure Key Vault jest obsługiwana przez SQL Server on Linux począwszy od Cumulative Update 14 dla SQL Server 2022.

Testowanie łączności sieciowej

Przed rozpoczęciem migracji przetestuj łączność sieciową między wystąpieniem SQL Server i SQL Managed Instance. Łączność można przetestować bezpośrednio z portalu Azure w ramach procesu migracji. Można jednak również ręcznie przetestować łączność przy użyciu Transact-SQL i SQL Server Agent. Aby uzyskać więcej informacji, zobacz Testowanie łączności sieciowej.

Aby przetestować łączność za pośrednictwem portalu Azure, wykonaj następujące kroki:

Wybierz Migrate data w Database migration okienku migracji bazy danych dla zasobu swojego wystąpienia SQL Server.
Wybierz opcję MI link.
Wybierz docelowe bazy danych, które chcesz zmigrować, a następnie użyj pozycji Dalej: Ustawienia , aby przejść do następnej karty.
Na karcie Ustawienia podaj nazwę linku i źródłową grupę dostępności. Następnie użyj połączenia Test aby zweryfikować łączność sieciową między SQL Server i SQL Managed Instance:

Rozważ następujące kwestie:

Aby uniknąć wyników fałszywie ujemnych, wszystkie zapory wzdłuż ścieżki sieciowej muszą zezwalać na ruch protokołu ICMP (Internet Control Message Protocol).
Aby uniknąć fałszywie dodatnich wyników, wszystkie zapory sieciowe wzdłuż trasy sieci muszą zezwalać na ruch w zastrzeżonym protokole SQL Server UCS. Zablokowanie protokołu może prowadzić do pomyślnego testu połączenia, ale nie udaje się utworzyć połączenia.
Aby umożliwić ruch między SQL Server i SQL Managed Instance, należy prawidłowo skonfigurować zaawansowane konfiguracje zapory z zabezpieczeniami na poziomie pakietów.

Ograniczenia

Rozważ następujące ograniczenia:

Ograniczenia linku Managed Instance mają zastosowanie do migracji za pośrednictwem portalu Azure.
rozszerzenie Azure dla wersji SQL Server 1.1.3238.349 i wcześniejsze obsługuje tylko migrację jednej bazy danych naraz za pośrednictwem linku. Aby przeprowadzić migrację wielu baz danych jednocześnie, zaktualizuj do Azure Extension dla SQL Server w wersji 1.1.3348.364 lub nowszej.
Anulowanie migracji wymaga uprawnień sysadmin w wystąpieniu SQL Server źródłowym. Jeśli wystąpienie SQL Server nie jest skonfigurowane do korzystania z minimalnych uprawnień, ręcznie przypisz uprawnienia sysadmin do konta NT AUTHORITY\SYSTEM.
Konfigurowanie linku za pośrednictwem portalu Azure w celu migracji nie jest zgodne z linkami utworzonymi ręcznie za pośrednictwem SQL Server Management Studio (SSMS) lub Transact-SQL (T-SQL). Zapoznaj się ze znanym problemem , aby dowiedzieć się więcej.
Monitorowanie migracji za pośrednictwem portalu Azure jest dostępne tylko dla wystąpień SQL Server spełniających wymagania licencyjne.

Rozwiązywanie typowych problemów

Aby rozwiązać typowe problemy podczas migracji do Azure SQL Managed Instance, zobacz Rozwiązywanie problemów z migracją.

Następne kroki

Przenieś na Azure SQL Managed Instance

Opinia

Czy ta strona była pomocna?

Last updated on 2026-04-16

Przygotowywanie środowiska do migracji linków Managed Instance — migracja SQL Server w Azure Arc

Wymagania wstępne

Obsługiwane wersje SQL Server

Permissions

Dopasowywanie wydajności między replikami

Przygotuj instancję SQL Server

Instalowanie aktualizacji usługi

Utwórz klucz główny bazy danych w bazie danych głównej.

Przygotowywanie wystąpień SQL Server 2016

Włączanie grup dostępności

Włącz flagi śledzenia uruchamiania

Uruchom ponownie SQL Server i zweryfikuj konfigurację

Ustawianie bazy danych na model pełnego odzyskiwania

Importowanie kluczy głównego urzędu certyfikacji zaufanego przez Azure do SQL Server

Włączanie przyspieszonego odzyskiwania bazy danych

Włącz Service Broker

Konfigurowanie łączności sieciowej

SQL Server poza Azure

SQL Server na platformie Azure Virtual Machines

Porty sieciowe między środowiskami

Dodaj adresy URL do listy dopuszczonych

Migrowanie certyfikatu bazy danych chronionej przez funkcję TDE (opcjonalnie)

Testowanie łączności sieciowej

Ograniczenia

Rozwiązywanie typowych problemów

Następne kroki

Treści powiązane

Opinia

Dodatkowe zasoby