Omówienie linku Managed Instance

Dotyczy:Azure SQL Managed Instance

Ten artykuł zawiera omówienie linku Managed Instance, który umożliwia replikację danych niemal w czasie rzeczywistym między SQL Server a Azure SQL Managed Instance. Link zapewnia elastyczność hybrydową i mobilność bazy danych, ponieważ odblokuje kilka scenariuszy, takich jak skalowanie obciążeń tylko do odczytu, odciążanie analiz i raportowanie do Azure oraz migrowanie do Azure. W przypadku SQL Server 2022 i nowszych, link umożliwia internetowe odzyskiwanie po awarii i przywracanie z powrotem do SQL Server, a także konfigurację linku z SQL Managed Instance do SQL Server.

Aby rozpocząć, zapoznaj się z przygotowaniem środowiska do łącza.

Omówienie

Link Instancja Zarządzana używa rozproszonych grup dostępności w celu rozszerzenia zestawu danych w sposób bezpieczny i pewny. Synchronizuje dane niemal w czasie rzeczywistym z SQL Server hostowanego w dowolnym miejscu do Azure SQL Managed Instance lub z Azure SQL Managed Instance do SQL Server 2022 lub nowszego hostowanego w dowolnym miejscu.

Łącze obsługuje instancje SQL Server dla pojedynczego i wielu węzłów, z istniejącymi grupami dostępności lub bez nich. Dzięki temu linkowi możesz korzystać z zalet Azure bez konieczności migracji całego swojego SQL Server do chmury.

Funkcja linku oferuje obecnie następujące funkcje:

• Replikacja jednokierunkowa z SQL Server w wersji 2016, 2017 i 2019: użyj funkcji linku, aby replikować dane w jeden sposób z wystąpienia SQL do Azure SQL Managed Instance. Chociaż w przypadku awarii możesz ręcznie przełączyć się na swoje wystąpienie zarządzane, powoduje to zerwanie połączenia, a powrót nie jest możliwy.
• Odzyskiwanie po awarii (SQL Server 2022 i SQL Server 2025): użyj funkcji łącza, aby replikować dane między SQL Server 2022 lub SQL Server 2025 i SQL Managed Instance, ręcznie przełącz na pomocniczy podczas awarii i po ograniczeniu awarii powróć do podstawowego. SQL Server lub SQL Managed Instance może być początkowym elementem podstawowym.

Możesz nadal uruchamiać link tak długo, jak jest potrzebny, przez wiele miesięcy, a nawet lat naraz. Ponadto w przypadku procesu modernizacji, jeśli lub gdy będziesz gotowy do migracji do Azure, link umożliwia znacznie ulepszony proces migracji. Migracja za pośrednictwem linku oferuje minimalny przestój w porównaniu ze wszystkimi innymi dostępnymi opcjami migracji, zapewniając prawdziwą migrację online do SQL Managed Instance.

Można użyć baz danych replikowanych za pośrednictwem połączenia między SQL Server i Azure SQL Managed Instance w kilku scenariuszach, takich jak:

• Odzyskiwanie po awarii
• Korzystanie z usług Azure bez migracji do chmury
• Odciążanie obciążeń tylko do odczytu do Azure
• Migrowanie do Azure
• Kopiowanie danych lokalnych

Tryby łącza

Link Managed Instance obsługuje dwa tryby. Tryb ten określa, czy łącze replikuje jedną bazę danych, czy wszystkie bazy danych w istniejącej grupie dostępności SQL Server Always On.

Tryb wielu baz danych wymaga konkretnych aktualizacji SQL Server, obsługiwanych edycji oraz zgody na każdą replikę SQL Server. Odpowiadająca polityka aktualizacji SQL Managed Instance jest wymagana, gdy SQL Managed Instance jest podstawowym lub gdy rola wraca do SQL Server. Replikacja nie może celować w niższą wersję, niezależnie od tego, która instancja jest docelowa. Aby replikować w jedną stronę i przełączyć się z SQL Server do SQL Managed Instance, polityka aktualizacji docelowej musi odpowiadać lub być wyższa niż wersja źródłowa SQL Server. SQL Server 2022 wspiera polityki SQL Server 2022, SQL Server 2025 oraz Always-up-to-date. SQL Server 2025 wspiera polityki SQL Server 2025 i Always-up-to-dat, ale nie SQL Server 2022. Nie możesz replikować danych ani wrócić do SQL Server po cutoverze, jeśli polityki się nie zgadzają. W celu uzyskania tych wymagań zobacz Obsługa łącza wielobazowego.

Linki w trybie pojedynczej bazy danych i wielobazowej nie mogą współistnieć na tej samej instancji SQL Server. Nie możesz zmienić trybu linku na miejscu. Aby zmienić tryb, usuń wszystkie istniejące linki, zmień tryb na każdej repliki SQL Server, a następnie odtworz linki.

Możliwość obsługi wersji

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

Replikacja jednokierunkowa z SQL Server do Azure SQL Managed Instance jest ogólnie dostępna dla każdej obsługiwanej wersji SQL Server. Odzyskiwanie po awarii z replikacją dwukierunkową i powrotem po awarii jest obsługiwane od SQL Server 2022 i opiera się na polityce aktualizacji, z którą skonfigurowane jest wystąpienie zarządzane SQL.

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

¹ Tworzenie linku z SQL Server 2022 jako początkowym wiodącym jest obsługiwane od wersji RTM SQL Server 2022, natomiast utworzenie linku z Azure SQL Managed Instance jako początkowym wiodącym jest obsługiwane dopiero od SQL Server 2022 CU10. Jeśli utworzysz link z początkowego serwera podstawowego SQL Managed Instance, obniżenie wersji SQL Server poniżej CU10 nie jest obsługiwane, gdy link jest aktywny, ponieważ może to powodować problemy po przełączeniu w tryb awaryjny w dowolnym kierunku.

Wersje SQL Server wcześniejsze niż 2016 (SQL Server 2008 - 2014) nie są obsługiwane, ponieważ funkcjonalność linków opiera się na technologii rozproszonej grupy dostępności, która została wprowadzona w SQL Server 2016.

Oprócz obsługiwanej wersji SQL Server potrzebne są następujące elementy:

• Łączność sieciowa między instancją SQL Server a instancją zarządzaną. Jeśli SQL Server działa lokalnie, użyj linku sieci VPN lub Azure ExpressRoute. Jeśli SQL Server jest uruchomiony na maszynie wirtualnej Azure, wdróż maszynę wirtualną w tej samej sieci wirtualnej co wystąpienie zarządzane lub użyj peeringu sieci wirtualnej, aby połączyć dwie oddzielne podsieci.
• Wdrożenie Azure SQL Managed Instance aprowidowane w dowolnej warstwie usługi.

Potrzebne są również następujące narzędzia:

Jak działa link

Funkcja linku dla SQL Managed Instance działa przez utworzenie rozproszonej grupy dostępności między SQL Server i Azure SQL Managed Instance. Rozwiązanie obsługuje systemy z pojedynczym węzłem, zarówno z istniejącymi grupami dostępności, jak i bez nich, oraz systemy z wieloma węzłami z istniejącymi grupami dostępności.

Połączenie prywatne, takie jak sieć VPN lub Azure ExpressRoute, łączy sieć lokalną i Azure. Jeśli hostujesz SQL Server na maszynie wirtualnej Azure, wewnętrzna sieć szkieletowa Azure może połączyć tę maszynę z wystąpieniem zarządzanym SQL, na przykład poprzez peering sieci wirtualnych. Dwa systemy ustanawiają zaufanie przy użyciu uwierzytelniania opartego na certyfikatach, gdzie SQL Server i SQL Managed Instance wymieniają klucze publiczne odpowiednich certyfikatów.

Azure SQL Managed Instance obsługuje wiele łączy z tych samych lub różnych źródeł SQL Server. Pojemność bazy danych jest współdzielona między wszystkimi łączami i innymi bazami danych na zarządzanej instancji. Uniwersalne i biznesowe wsparcie do 100 baz danych na instancję, a Next-gen General Purpose obsługuje do 500. Istniejące bazy danych zmniejszają dostępną pojemność dla powiązanych baz danych. Aby uzyskać szczegółowe informacje, zobacz Limity zasobów.

W trybie pojedynczej bazy danych każdy link replikuje jedną bazę danych. W trybie wielu baz danych jedno łącze może replikować wiele baz danych, a każda replikowana baza danych liczy się do tego samego limitu bazy danych dla całej instancji. Tworzenie większej liczby linków nie zwiększa tego limitu. Na przykład zarządzana instancja z limitem 100 baz danych i 10 istniejącymi bazami danych ma pojemność na 90 kolejnych baz danych, niezależnie od tego, czy replikujesz je przez jedno połączenie z wieloma bazami danych, czy oddzielne linki pojedynczej bazy danych od odpowiednio skonfigurowanych instancji SQL Server.

Jedna instancja SQL Server może tworzyć wiele równoległych łączy z kilkoma instancjami zarządzanymi SQL, nawet w różnych regionach Azure. Wszystkie linki na tej instancji SQL Server muszą korzystać z tego samego trybu linku.

Użyj linku

Aby ułatwić skonfigurowanie środowiska początkowego, zapoznaj się z przewodnikiem przygotowywania środowiska SQL Server do korzystania z funkcji linku z SQL Managed Instance:

• Przygotuj środowisko dla linku SQL Server 2019 lub nowszego lub SQL Server 2016
• Automatyzowanie przygotowywania środowiska dla linku Managed Instance przy użyciu skryptu do pobrania. Aby uzyskać więcej informacji, zobacz blog Automatyzowanie konfiguracji linków.

Po spełnieniu wymagań dotyczących środowiska początkowego utwórz link przy użyciu kreatora zautomatyzowanego w programie SQL Server Management Studio (SSMS) lub skonfiguruj link ręcznie przy użyciu skryptów:

• Konfigurowanie linku za pomocą programu SSMS
• Konfigurowanie linku za pomocą skryptów

Po utworzeniu linku postępuj zgodnie z najlepszymi rozwiązaniami, aby zachować link:

• Najlepsze rozwiązania dotyczące obsługi linku

Extend an Always On availability group to Azure (preview)

Użyj trybu linku z wieloma bazami danych, aby rozszerzyć istniejącą grupę dostępności SQL Server Always On do Azure SQL Managed Instance. Aby uzyskać wymagania podglądowe i konfigurację, zobacz Extend an Always On availability group to Azure SQL Managed Instance.

Odzyskiwanie po awarii

Link Managed Instance umożliwia disaster recovery gdzie w przypadku awarii można ręcznie przeładować obciążenie z poziomu podstawowego do pomocniczego. Aby rozpocząć, przejrzyj Odzyskiwanie po awarii z użyciem Managed Instance.

W przypadku SQL Server 2016 do SQL Server 2019 podstawowe jest zawsze SQL Server, a przejście w tryb failover do pomocniczego wystąpienia zarządzanego SQL jest jednokierunkowe. Powrót po awarii do SQL Server nie jest obsługiwany. Można jednak odzyskać dane do SQL Server przy użyciu opcji przenoszenia danych, takich jak replikacja transakcyjna lub eksportowanie pliku BACPAC.

W przypadku SQL Server 2022 i SQL Server 2025 r. SQL Server lub SQL Managed Instance (z pasującymi zasadami aktualizuj) może być początkowym elementem podstawowym i można ustanowić link z SQL Server lub SQL Managed Instance. Można przenosić obciążenia robocze między lokalizacją podstawową a pomocniczą, zapewniając prawdziwe dwukierunkowe odzyskiwanie po awarii.

W przypadku przywracania po awarii do SQL Server masz do wyboru:

• online używając linku Managed Instance bezpośrednio.
• offline wykonując kopię zapasową bazy danych z SQL Managed Instance i przywracając ją do wystąpienia SQL Server.

Korzystanie z usług Azure

Użyj funkcji linku, aby korzystać z usług Azure przy użyciu SQL Server danych bez migrowania ich do chmury. Przykłady obejmują raportowanie, analizę, kopie zapasowe, uczenie maszynowe i inne zadania, które wysyłają dane do Azure.

Odciążanie obciążeń do Azure

Możesz również użyć funkcji linku, aby odciążyć obciążenia do Azure. Na przykład aplikacja może używać SQL Server do obciążeń odczytu/zapisu, podczas gdy obciążenia tylko do odczytu przenosi do wdrożeń SQL Managed Instance w dowolnym regionie Azure na całym świecie. Po ustanowieniu linku podstawowa baza danych na SQL Server jest dostępna do odczytu/zapisu, podczas gdy replikowane dane do wystąpienia zarządzanego SQL w Azure są dostępne tylko do odczytu. Takie rozwiązanie umożliwia korzystanie z różnych scenariuszy, w których replikowane bazy danych w wystąpieniu zarządzanym SQL mogą służyć do skalowania odczytu w poziomie i przenoszenia obciążeń tylko do odczytu do Azure. Wystąpienie zarządzane SQL równolegle może również hostować niezależne bazy danych odczytu/zapisu, co umożliwia również kopiowanie replikowanej bazy danych do innej bazy danych odczytu/zapisu w tym samym wystąpieniu zarządzanym SQL w celu dalszego przetwarzania danych.

Aby odciążyć wystąpienie zarządzane SQL, połącz aplikację z replikowaną bazą danych i kieruj do niej zapytania tylko do odczytu. Możesz nawiązać połączenie przy użyciu jednego z następujących punktów końcowych:

• Punkt końcowy VNet-local, który jest dostępny z sieci wirtualnej obsługującej wystąpienie zarządzane SQL lub z sieci równorzędnych. Jest to zalecane podejście, gdy aplikacja działa w Azure lub łączy się za pośrednictwem sieci VPN lub usługi ExpressRoute.
• Publiczny punkt końcowy, który jest dostępny za pośrednictwem Internetu. Użyj tego podejścia, gdy aplikacja musi nawiązać połączenie spoza sieci wirtualnej, a komunikacja równorzędna lub prywatne punkty końcowe nie są dostępne. Publiczny punkt końcowy obsługuje wyłącznie ruch klientów i nie może być używany do replikacji danych połączenia, która zawsze korzysta z punktu końcowego lokalnego dla sieci wirtualnej.

Link ten umożliwia konsolidację i dekonsolidację obciążeń w Azure. Na przykład możesz replikować bazy danych z wielu instancji SQL Server do jednego wdrożenia SQL Managed Instance w Azure (konsolidacja), albo replikować bazy danych z jednej instancji SQL Server do wielu instancji zarządzanych SQL w dowolnym regionie Azure na świecie (dekonsolidacja). Ta opcja zapewnia wydajny sposób na szybkie zbliżenie obciążeń roboczych do klientów w dowolnym regionie na całym świecie, umożliwiając ich użycie jako replik tylko do odczytu.

Migrowanie do Azure

Funkcja linku ułatwia również migrację z SQL Server do SQL Managed Instance, co umożliwia:

• Najbardziej efektywna migracja o minimalnym czasie przestoju w porównaniu do wszystkich innych dostępnych obecnie rozwiązań.
• Prawdziwa migracja online do SQL Managed Instance w dowolnej warstwie usługi.

Ponieważ funkcja linku umożliwia migrację z minimalnymi przestojami, możesz przeprowadzić migrację do zarządzanego wystąpienia, utrzymując swoje obciążenie główne w trybie online. Chociaż obecnie jest możliwe osiągnięcie migracji online do warstwy usługi Ogólnego przeznaczenia z innymi rozwiązaniami, funkcja linku jest jedynym rozwiązaniem, które umożliwia prawdziwe migracje online do warstwy usługi Krytyczne dla działania firmy . Aby uzyskać szczegółowe porównanie migracji między migracją za pomocą łącza a usługą ponownego odtwarzania dziennika, zobacz Porównaj łącze zarządzanej instancji do LRS.

Kopiowanie danych lokalnych

Dzięki SQL Server 2022 i nowszym możesz ustanowić link z SQL Managed Instance do SQL Server, odblokowując dodatkowe scenariusze, takie jak tworzenie repliki bazy danych niemal w czasie rzeczywistym poza Azure, testowanie planów ciągłości działania i spełnianie wymagań dotyczących zgodności.

Automatyczne kopie zapasowe

Po skonfigurowaniu łącza z Azure SQL Managed Instance, bazy danych na SQL Managed Instance są automatycznie tworzone kopie zapasowe w Azure Storage, niezależnie od tego, czy SQL Managed Instance jest podstawowy. Automatyczne tworzenie kopii zapasowych z wykorzystaniem linku obejmuje pełne kopie zapasowe oraz kopie zapasowe dziennika transakcji, ale nie różnicowe kopie zapasowe, co może prowadzić do dłuższego czasu przywracania.

Możesz zmniejszyć koszty lokalnego zarządzania i operacji, jednocześnie ciesząc się niezawodnością Azure kopii zapasowych replikowanych baz danych. Następnie można wykonać przywracanie point-in-time zreplikowanej bazy danych do dowolnego wdrożenia SQL Managed Instance w tym samym regionie, co w przypadku innych automowanych kopii zapasowych.

Pasywna replika bez opłat licencyjnych

Możesz zaoszczędzić na kosztach licencjonowania rdzeni wirtualnych, jeśli aktywujesz korzyść hybrydowego trybu awaryjnego dla pomocniczego pasywnego odzyskiwania po awarii zarządzanych wystąpień SQL bez obciążeń.

Aby rozpocząć, zapoznaj się z artykułem Replika pasywna bez licencji.

Analiza kosztów i korzyści

Jeśli wyznaczysz replikę wystąpienia zarządzanego tylko na potrzeby odzyskiwania po awarii, Microsoft nie nalicza kosztów licencjonowania SQL Server dla vCores używanych przez wystąpienie pomocnicze. Opłaty za instancję są naliczane w rozliczeniu godzinowym i nadal mogą być naliczane koszty licencjonowania za pełną godzinę, jeśli zaktualizujesz warunki licencjonowania w ciągu godziny.

Korzyść działa inaczej w przypadku modelu rozliczeń pay-as-you-go i Korzyść użycia hybrydowego platformy Azure. W przypadku modelu rozliczeń z płatnością zgodnie z rzeczywistym użyciem rdzenie wirtualne są objęte zniżką na fakturze. Jeśli używasz Korzyść użycia hybrydowego platformy Azure dla repliki pasywnej, liczba rdzeni wirtualnych używanych przez replikę pomocniczą zostanie zwrócona do puli licencji.

Na przykład jako klient z rozliczeniem w modelu "płacisz za to, co zużywasz", jeśli masz przypisane 16 vCores do wystąpienia pomocniczego, otrzymasz zniżkę na 16 vCores, która pojawi się na Twojej fakturze, jeśli wyznaczysz swoje wystąpienie pomocnicze do trybu hybrydowego przełączenia awaryjnego.

W innym przykładzie, jeśli masz 16 licencji Korzyść użycia hybrydowego platformy Azure, a zarządzane wystąpienie pomocnicze SQL używa 8 rdzeni wirtualnych, po wyznaczeniu wystąpienia pomocniczego na potrzeby hybrydowego trybu przełączania awaryjnego, 8 rdzeni wirtualnych zostanie zwróconych do puli licencji, z której można korzystać z innymi wdrożeniami Azure SQL.

Aby uzyskać dokładne warunki i postanowienia dotyczące korzyści z hybrydowych praw do trybu failover, zobacz sekcję dotyczącą licencji SQL Server online w SQL Server — prawa do trybu failover.

Ograniczenia

Podczas korzystania z linku należy wziąć pod uwagę następujące ograniczenia.

Ograniczenia obsługi wersji obejmują:

• Nie można używać klientów Windows 10 i 11 do hostowania wystąpienia SQL Server, ponieważ nie można włączyć funkcji Always On grupy dostępności wymaganej do połączenia. Musisz hostować instancje SQL Server na Windows Server 2012 lub nowszym.
• Funkcja linku nie obsługuje SQL Server wersji 2008 do 2014, ponieważ aparat SQL tych wersji nie ma wbudowanej obsługi rozproszonych grup dostępności wymaganych dla linku. Zaktualizuj do nowszej wersji serwera SQL, żeby móc użyć linku.
• Replikacja danych i failover z SQL Managed Instance do SQL Server 2022 lub SQL Server 2025 nie są obsługiwane w przypadku wystąpień skonfigurowanych zgodnie z zasadą aktualizacji Always-up-to-date. Wystąpienie musi być skonfigurowane zgodnie z odpowiednią polityką aktualizacji SQL Server 2022 lub SQL Server 2025 polityka aktualizacji aby wykonać poniższe czynności:
  • Ustanów link z SQL Managed Instance do SQL Server.
  • Przełączenie awaryjne z SQL Managed Instance do SQL Server.
• Chociaż można ustanowić łącze z SQL Server 2022 lub SQL Server 2025 do zarządzanej instancji SQL skonfigurowanej przy użyciu Always-up-to-date update policy, po przejściu w tryb failover do zarządzanej instancji SQL nie można replikować danych ani powrócić do SQL Server.

Ograniczenia replikacji danych obejmują:

• Można replikować tylko bazy danych użytkowników. Replikacja systemowych baz danych nie jest obsługiwana.
• Rozwiązanie nie replikuje obiektów na poziomie serwera, zadań agenta ani logowań użytkowników z SQL Server do SQL Managed Instance.
• W przypadku SQL Server wersji 2016, 2017 i 2019 replikacja baz danych użytkowników z wystąpień SQL Server do wdrożeń SQL Managed Instance jest jednym ze sposobów. Nie można replikować baz danych użytkowników z wdrożeń SQL Managed Instance z powrotem do wystąpień SQL Server za pośrednictwem linku. Replikacja dwukierunkowa do wystąpienia SQL Server z powrotem po awarii dostępna jest tylko dla SQL Server 2022 lub SQL Server 2025, gdy usługa SQL Managed Instance jest skonfigurowana z odpowiednią polityką aktualizacji.
• Konfigurowanie linku z SQL Managed Instance do SQL Server nie jest obsługiwane w przypadku baz danych SQL Managed Instance, które są już połączone.

Ograniczenia konfiguracji obejmują:

• Jeśli na serwerze istnieje wiele wystąpień SQL Server, można skonfigurować łącze dla każdego wystąpienia, ale każde wystąpienie należy skonfigurować tak, aby używało oddzielnego punktu końcowego dublowania bazy danych z dedykowanym portem na wystąpienie. Tylko wystąpienie domyślne powinno używać portu 5022 dla punktu końcowego mirroringu bazy danych.
• W trybie łącza z jedną bazą danych każdy link replikuje jedną bazę danych. Możesz replikować wiele baz danych, ustanawiając oddzielne łącza z jedną bazą danych. Aby replikować wszystkie bazy danych w istniejącej grupie dostępności przez jedno łącze, użyj trybu linku wielobazowego (podgląd). Wymagane skumulowane aktualizacje i zgoda na przystąpienie są obowiązkowe na każdej repliki SQL Server; zobacz: obsługa rozszerzenia AG.
• Tryb łącza z jedną bazą danych wymaga grupy dostępności zawierającej tylko jedną bazę danych. To ograniczenie nie dotyczy trybu łącza z wieloma bazami danych, który replikuje wszystkie bazy danych w istniejącej grupie. Nie usuwaj baz danych z grupy dostępności, aby korzystać z trybu wielobazowego; podążaj za rozszerzeniem grupy dostępności Always On do Azure SQL Managed Instance.
• Pojedynczy SQL Managed Instance ogólnego przeznaczenia lub krytycznego dla działania firmy obsługuje maksymalnie 100 łączy, a jeden SQL Managed Instance ogólnego przeznaczenia następnej generacji obsługuje maksymalnie 500 łączy z tych samych lub z wielu źródeł SQL Server.
• Link Managed Instance może replikować bazę danych o dowolnym rozmiarze, jeśli pasuje do wybranego rozmiaru magazynu docelowego SQL Managed Instance wdrożenia.
• Uwierzytelnianie linków Managed Instance między "SQL Server" i "SQL Managed Instance" jest oparte na certyfikatach i dostępne tylko poprzez wymianę certyfikatów. Nie można użyć autoryzacji Windows do nawiązania połączenia między wystąpieniem SQL Server a wystąpieniem zarządzanym SQL.
• Możesz ustanowić połączenie tylko z punktem końcowym VNet-local do SQL Managed Instance.
• Nie można użyć publicznego punktu końcowego ani prywatnych punktów końcowych do nawiązania połączenia z wystąpieniem zarządzanym.
• Nie można replikować baz danych z wieloma plikami dziennika, ponieważ SQL Managed Instance nie obsługuje wielu plików dziennika.

Ograniczenia funkcji obejmują:

• Nie można używać grup trybu failover z wystąpieniami korzystającymi z funkcji linku. Nie można ustanowić łącza w wystąpieniu zarządzanym SQL, które jest częścią grupy failover, i odwrotnie, nie można skonfigurować grupy failover w wystąpieniu, które ma ustanowione łącze.
• Jeśli używasz funkcji przechwytywania zmian danych (CDC), wysyłania dzienników lub brokera usług z bazami danych replikowanymi na instancji SQL Server, podczas migracji bazy danych do wdrożenia SQL Managed Instance, klienci muszą po przejściu do trybu failover do Azure nawiązać połączenie przy użyciu nazwy instancji bieżącej globalnej repliki podstawowej. Należy ręcznie ponownie skonfigurować te ustawienia.
• Jeśli używasz replikacji transakcyjnej w bazie danych z ustalonym linkiem, rozważ następujące kwestie:
  • Połączona baza danych na pomocniczej replice nie może być wydawcą w topologii replikacji transakcyjnej.
  • Jeśli migrujesz bazę danych skonfigurowaną jako Publisher w topologii replikacji transakcyjnej przy użyciu linku, musisz ponownie skonfigurować bazę danych jako Publisher w wystąpieniu docelowym po zakończeniu migracji.
• Jeśli używasz transakcji rozproszonych z bazą danych replikowaną z wystąpienia SQL Server i w scenariuszu migracji, przy przeniesieniu do chmury, funkcje Koordynatora Transakcji Rozproszonych nie zostaną przeniesione. Nie można realizować transakcji rozproszonych pomiędzy zmigrowaną bazą danych a wystąpieniem SQL Server, ponieważ wdrożenie SQL Managed Instance nie obsługuje takich transakcji z SQL Server. Do celów referencyjnych SQL Managed Instance obecnie obsługuje transakcje rozproszone tylko między innymi wystąpieniami zarządzanymi. Aby uzyskać więcej informacji, zobacz Transakcje rozproszone w bazach danych w chmurze.
• Jeśli używasz Transparent Data Encryption (TDE) do szyfrowania baz danych SQL Server, musisz wyeksportować klucz szyfrowania bazy danych z SQL Server i przekazać go do Azure Key Vault, a także skonfigurować opcję TDE byOK na SQL Managed Instance przed utworzeniem linku.
• Jeśli przyspieszone odzyskiwanie bazy danych jest wyłączone na twoim źródłowym serwerze SQL Server 2019 i nowszych wystąpieniach, nie można go już włączyć po migracji do Azure SQL Managed Instance. Ponadto, jeśli magazyn wersji trwałej (PVS) nie jest ustawiony na PRIMARYwartość, mogą wystąpić problemy z operacjami przywracania w docelowym wystąpieniu zarządzanym SQL.
• Jeśli Service Broker jest wyłączona w wystąpieniu źródłowym SQL Server, nie można użyć usługi Service Broker w docelowym wystąpieniu zarządzanym SQL po migracji.
• Nie można połączyć baz danych z SQL Managed Instance, które są zaszyfrowane przy użyciu kluczy TDE zarządzanych przez usługę, z SQL Server. Zaszyfrowaną bazę danych można połączyć z SQL Server tylko wtedy, gdy zaszyfrowano ją przy użyciu klucza zarządzanego przez klienta, a serwer docelowy ma dostęp do tego samego klucza, który jest używany do szyfrowania bazy danych. Aby uzyskać więcej informacji, zobacz Konfigurowanie funkcji TDE SQL Server za pomocą Azure Key Vault.
• Nie można ustanowić połączenia między SQL Server a SQL Managed Instance, jeśli funkcjonalność używana w wystąpieniu SQL Server nie jest obsługiwana w SQL Managed Instance. Na przykład:
  • Nie można replikować baz danych z tabelami plików i strumieniami plików, ponieważ SQL Managed Instance nie obsługuje tabel plików ani strumieni plików.
  • Można replikować bazy danych, które używają In-Memory OLTP tylko do SQL Managed Instance w warstwie usługi Business Critical, ponieważ Ogólne przeznaczenie warstwa usługi nie obsługuje In-Memory OLTP. SQL Managed Instance nie obsługuje baz danych z wieloma plikami OLTP In-Memory i nie można ich replikować.

Próba dodania nieobsługiwanej funkcji do replikowanej bazy danych w:

• SQL Server 2017, 2019 i 2022 kończy się niepowodzeniem z powodu błędu.
• SQL Server 2016 powoduje przerwanie linku, który następnie należy usunąć i utworzyć ponownie.

Aby uzyskać pełną listę różnic między SQL Server a SQL Managed Instance, zobacz różnice T-SQL między SQL Server i Azure SQL Managed Instance.

Powiązana zawartość

Aby użyć linku:

• Przygotuj środowisko dla łącza Managed Instance
• Konfiguruj połączenie między SQL Server i wystąpieniem zarządzanym SQL za pomocą programu SSMS
• Konfiguruj połączenie między SQL Server i wystąpieniem zarządzanym SQL za pomocą skryptów
• Przełączenie łącza w tryb awaryjny
• Migrowanie za pomocą linku
• Najlepsze rozwiązania dotyczące obsługi linku
• Rozwiązywanie problemów z linkiem

Aby dowiedzieć się więcej na temat linku:

• Odzyskiwanie po awarii z linkiem Managed Instance

W przypadku innych scenariuszy replikacji i migracji należy wziąć pod uwagę następujące kwestie:

• Replikacja transakcyjna w ramach SQL Managed Instance
• Usługa ponownego odtwarzania dziennika (LRS)
• Dokumentacja referencyjna modyfikowalnej konfiguracji dla usługi Azure SQL Managed Instance