Przygotowywanie środowiska do migracji LRS — migracja SQL Server w Azure Arc

Dotyczy:SQL Server

Ten artykuł pomaga przygotować środowisko do migracji wystąpienia SQL Server uruchomionego za pomocą Azure Arc z wykorzystaniem Log Replay Service (LRS) do Azure SQL Managed Instance w portalu Azure.

Usługa LRS umożliwia migrowanie baz danych SQL Server do Azure SQL Managed Instance przy użyciu kopii zapasowej i przywracania za pośrednictwem wysyłania dzienników (migracja online):

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

Migracja z LRS działa z każdą edycją SQL Server na Windowsie. Chociaż migracja do warstw usług Ogólnego Przeznaczenia i Krytyczne dla Działalności Biznesowej w ramach SQL Managed Instance jest obsługiwana, migracja bezpośrednio do warstwy usługi Krytyczne dla Działalności Biznesowej ma pewne ważne ograniczenia do rozważenia.

W poniższej tabeli wymieniono minimalne obsługiwane wersje SQL Server dla LRS.

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ć najniższych uprawnień, musisz mieć uprawnienia sysadmin w wystąpieniu źródłowym SQL Server.

Aby przeprowadzić migrację przy użyciu standardu LRS, musisz mieć jedno z następujących uprawnień dotyczących docelowej instancji SQL Managed Instance:

• rola współautora SQL Managed Instance
• Rola z następującym uprawnieniem: Microsoft.Sql/managedInstances/databases/*

Utwórz konto przechowywania

Konto Azure Blob Storage jest używane jako magazyn pośredniczący dla plików kopii zapasowych między wystąpieniem SQL Server a wdrożeniem SQL Managed Instance. Konto magazynu musi znajdować się w tej samej subskrypcji Azure co docelowa usługa SQL Managed Instance.

Aby utworzyć nowe konto magazynowe i kontener obiektów typu blob w koncie magazynowym:

1. Utwórz konto magazynowe:
   1. Wyszukaj Konta magazynu w portalu Azure i wybierz Utwórz.
   2. Na karcie Podstawy wybierz swoją subskrypcję i grupę zasobów. Region powinien być taki sam jak docelowy SQL Managed Instance.
   3. Pozostawić preferowany typ magazynu pusty.
   4. Użyj ustawień domyślnych dla pozostałych kart, a następnie wybierz pozycję Review + create.
   5. Po zakończeniu walidacji wybierz pozycję Utwórz.
2. Utwórz kontener obiektów blob na koncie magazynowym.
   1. Przejdź do swojego nowego konta magazynowego w portalu Azure.
   2. W sekcji Przechowywanie danych wybierz Kontenery.
   3. Użyj polecenia Dodaj kontener , aby otworzyć okienko Nowy kontener .
   4. Wprowadź nazwę kontenera, pozostaw wartości domyślne opcji i wybierz pozycję Utwórz , aby utworzyć kontener.
3. (Opcjonalnie) Jeśli Azure Storage znajduje się za zaporą, Azure Blob Storage wymaga dodatkowej konfiguracji po aprowizacji wystąpienia zarządzanego SQL.

Udzielanie uprawnień do Azure Blob Storage

Migracja SQL Server w Azure Arc z wykorzystaniem magazynu LRS używa tożsamości zarządzanej do uwierzytelniania w Azure Blob Storage.

Musisz przyznać następujące uprawnienia:

• Udziel użytkownikowi dostępu do konta magazynu , na którym planujesz przechowywać kopie zapasowe podczas procesu migracji.
• Udziel użytkownikowi dostępu do grupy zasobów zawierającej konto magazynowe.
• Udziel tożsamości zarządzanej dostępu do konta magazynowego po utworzeniu wystąpienia zarządzanego SQL.

Przyznaj użytkownikowi dostęp do konta storage

pl-PL: Aby uzyskać dostęp do kopii zapasowych bazy danych podczas procesu migracji, przypisz użytkownika, który loguje się do portalu Azure i wykonuje migrację, do roli Storage Blob Data Reader dla konta magazynu zawierającego kopie zapasowe.

Aby przypisać rolę, wykonaj następujące kroki:

1. W portalu Azure przejdź do grupy zasobów, która zawiera twoje konto magazynu.

2. Wybierz pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami) z menu zasobów.

3. Użyj pozycji + Dodaj , aby wybrać pozycję Dodaj przypisanie roli i otworzyć okienko Dodawanie przypisania roli .

4. Wyszukaj i wybierz rolę Odczyt danych obiektu blob Storage. Następnie wybierz Dalej.

   

5. Użyj pozycji + Wybierz członków , aby otworzyć okienko Wybierz członków i wyszukać konto użytkownika osoby wykonującej migrację. Jeśli wiele osób migruje dane, przyznaj wszystkim tym użytkownikom ten dostęp. Wybierz konto użytkownika, a następnie wybierz pozycję Wybierz , aby zapisać wybór. Zaznacz opcję przypisania dostępu do użytkownika, grupy lub jednostki usługi.

6. Wybierz Przejrzyj i przypisz, aby przejść do karty Przejrzyj i przypisz, a następnie wybierz Przejrzyj i przypisz ponownie, aby ukończyć przypisanie roli.

Udzielanie użytkownikowi dostępu do grupy zasobów

Aby uzyskać dostęp do kopii zapasowych bazy danych podczas procesu migracji, użytkownik logujący się do portalu Azure i wykonujący migrację powinien mieć przypisaną rolę Reader w grupie zasobów zawierającej konto magazynu.

Aby przypisać rolę, wykonaj następujące kroki:

1. W portalu Azure przejdź do grupy zasobów, która zawiera twoje konto magazynu.

2. Wybierz pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami) z menu zasobów.

3. Użyj pozycji + Dodaj , aby wybrać pozycję Dodaj przypisanie roli i otworzyć okienko Dodawanie przypisania roli .

4. Wyszukaj i wybierz rolę Czytelnik . Następnie wybierz Dalej.

   

5. Użyj pozycji + Wybierz członków , aby otworzyć okienko Wybierz członków i wyszukać konto użytkownika osoby wykonującej migrację. Jeśli wiele osób migruje dane, przyznaj wszystkim tym użytkownikom ten dostęp. Wybierz konto użytkownika, a następnie wybierz pozycję Wybierz , aby zapisać wybór. Zaznacz opcję przypisania dostępu do użytkownika, grupy lub jednostki usługi, a następnie użyj pozycji Dalej , aby kontynuować.

6. Na karcie Typ przypisania ustaw wartość Typ przypisania na Aktywny, a czas trwania przypisania na Trwały:

   

7. Wybierz Przejrzyj i przypisz, aby przejść do karty Przejrzyj i przypisz, a następnie wybierz Przejrzyj i przypisz ponownie, aby ukończyć przypisanie roli.

Udzielanie tożsamości zarządzanej dostępu do konta magazynu

Po utworzeniu wystąpienia zarządzanego SQL należy przypisać zarządzaną tożsamość wystąpienia SQL do roli Czytnika danych obiektu blob magazynu, aby mógł uzyskać dostęp do Twojego konta Azure Blob Storage podczas procesu migracji.

Najpierw należy określić rodzaj tożsamości zarządzanej używanej przez wystąpienie zarządzane SQL. W tym celu wykonaj następujące kroki:

1. Przejdź do wystąpienia zarządzanego SQL w portalu Azure.
2. W obszarze Zabezpieczenia wybierz pozycję Tożsamość.
   1. Jeśli w obszarze Tożsamość zarządzana przypisana przez użytkownika zostanie wyświetlona opcja Nie znaleziono tożsamości zarządzanych przypisanych przez użytkownika, wystąpienie zarządzane SQL używa domyślnej tożsamości zarządzanej przypisanej przez system.
   2. Jeśli w polu Tożsamość podstawowa widoczny jest wpis, to wystąpienie zarządzane SQL korzysta z niestandardowej tożsamości zarządzanej przypisanej przez użytkownika. Zanotuj tę tożsamość, aby użyć jej w kroku, w którym wybierasz tożsamość zarządzaną przy udzielaniu dostępu Storage Blob Data Reader do konta magazynowego.

Aby udzielić dostępu do konta magazynu, wykonaj następujące kroki:

1. Przejdź do konta Azure Blob Storage w portalu Azure, którego zamierzasz użyć do migracji.
2. Wybierz pozycję Kontrola dostępu (Zarządzanie dostępem i tożsamościami) z menu zasobów.
3. Użyj pozycji + Dodaj , aby wybrać pozycję Dodaj przypisanie roli i otworzyć okienko Dodawanie przypisania roli .
4. Wyszukaj i wybierz rolę Odczyt danych obiektu blob Storage. Następnie wybierz Dalej.
5. W obszarze Przypisz dostęp do wybierz opcję Tożsamość zarządzana.
6. Użyj pozycji Wybierz członków , aby otworzyć okienko Wybierz członków .
7. Jeśli wystąpienie zarządzane SQL używa domyślnej tożsamości zarządzanej przypisanej przez system:
   1. W obszarze Tożsamość zarządzana, wybierz opcję Wystąpienie zarządzane SQL.
   2. Wyszukaj i wybierz nazwę zarządzanego wystąpienia SQL.
   3. Użyj pozycji Wybierz , aby zapisać wybór.
8. Jeśli wystąpienie zarządzane SQL używa tożsamości zarządzanej przypisanej przez użytkownika:
   1. W obszarze Tożsamość zarządzana wybierz pozycję Tożsamość zarządzana przypisana przez użytkownika.
   2. Wyszukaj zanotowaną wcześniej nazwę tożsamości podstawowej na stronie Tożsamość z wystąpienia zarządzanego SQL i wybierz ją.
   3. Użyj pozycji Wybierz , aby zapisać wybór.
9. Wybierz Przejrzyj i przypisz, aby przejść do karty Przejrzyj i przypisz, a następnie wybierz Przejrzyj i przypisz ponownie, aby ukończyć przypisanie roli.

Po przesłaniu przynajmniej jednej pełnej kopii zapasowej na to konto magazynowe, możesz uruchomić następujące polecenie na zarządzanym wystąpieniu SQL, aby sprawdzić, czy może uzyskać dostęp do konta Azure Blob Storage.

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

Konfigurowanie źródłowej bazy danych SQL Server

Włącz przyspieszone odzyskiwanie bazy danych i usługę Service Broker w wystąpieniu źródłowym SQL Server, jeśli planujesz używać tych funkcji na docelowym SQL Managed Instance po migracji, ponieważ nie można włączyć tych funkcji po migracji, jeśli nie zostały jeszcze włączone w wystąpieniu źródłowym SQL Server.

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:

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

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

Przekazywanie kopii zapasowych do konta Blob Storage

Gdy kontener obiektów blob jest gotowy i potwierdzono, że wystąpienie zarządzane SQL może uzyskać dostęp do kontenera, możesz rozpocząć przesyłanie swoich kopii zapasowych na swoje konto w usłudze Azure Blob Storage. Po przesłaniu wszystkich kopii zapasowych na konto dyskowe, jesteś gotowy do przystąpienia do migracji.

Aby przekazać kopie zapasowe do Azure:

• Wykonaj kopie zapasowe na wystąpieniu SQL Server.
• Kopiuj kopie zapasowe na koncie Blob Storage.
• Alternatywnie, w SQL Server 2025 (17.x) na Windows Server wprowadzono obsługę tożsamości zarządzanej dla kopii zapasowych bezpośrednio do adresu URL. Aby wykonywać kopię zapasową bezpośrednio do adresu URL dla SQL Server 2022 i starszych, należy użyć tokenu SAS. Aby użyć tożsamości zarządzanej z SQL Server 2022 i starszych wersji, skopiuj kopie zapasowe na konto Blob Storage przy użyciu AzCopy. Jedynym wyjątkiem jest migracja z SQL Server na maszynach wirtualnych Azure, które obsługują tworzenie kopii zapasowych bezpośrednio pod adresem URL przy użyciu uwierzytelniania tożsamości zarządzanej, począwszy od SQL Server 2022 CU 17.

Rozważ następujące najlepsze rozwiązania:

• Wykonaj kopie zapasowe z opcjami COMPRESSION i CHECKSUM, aby zmniejszyć rozmiar plików kopii zapasowych oraz zapobiec migracji uszkodzonej bazy danych.
• Wykonywanie kopii zapasowych w mniejszych partiach.
• Użyj równoległych wątków wysyłania.
• Utwórz możliwie najmniejszy ostatni plik kopii zapasowej.
• Aby przeprowadzić migrację wielu baz danych przy użyciu tego samego kontenera Azure Blob Storage, umieść wszystkie pliki kopii zapasowej dla pojedynczej bazy danych w oddzielnym folderze wewnątrz kontenera. Użyj struktury plików prostych dla każdego folderu bazy danych. Zagnieżdżanie folderów wewnątrz folderów bazy danych nie jest obsługiwane.

Tworzenie kopii zapasowych dla wystąpienia SQL Server

W krokach w tej sekcji pokazano, jak utworzyć kopię zapasową lokalnie, ale można utworzyć kopię zapasową bezpośrednio pod adresem URL.

Ustaw bazy danych, które chcesz zmigrować do pełnego modelu odzyskiwania, aby można było tworzyć kopie zapasowe dzienników.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master;

ALTER DATABASE SampleDB
SET RECOVERY FULL;
GO

Jeśli nie masz jeszcze istniejących kopii zapasowych, wykonaj ręcznie pełne, różnicowe i dziennikowe kopie zapasowe bazy danych do lokalnego magazynu, używając poniższych przykładowych skryptów języka T-SQL. CHECKSUM nie jest wymagane, ale zaleca się zapobieganie migrowaniu uszkodzonej bazy danych i skrócenie czasu przywracania.

Poniższy przykład wykonuje pełną kopię zapasową bazy danych na dysku lokalnym:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

Poniższy przykład wykonuje różnicową kopię zapasową na dysku lokalnym:

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

Poniższy przykład wykonuje kopię zapasową dziennika transakcji na dysku lokalnym:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
GO

Kopiowanie kopii zapasowych na konto Blob Storage

Gdy kopie zapasowe są gotowe i chcesz rozpocząć migrację baz danych do wystąpienia zarządzanego SQL za pomocą LRS, zastosuj następujące metody kopiowania istniejących kopii zapasowych na konto Blob Storage:

• Pobierz i zainstaluj AzCopy.
• Pobierz i zainstaluj Azure Storage Explorer.
• Użyj Storage Explorer w portalu Azure.

Ograniczenia

Ograniczenia LRS mają zastosowanie do migracji za pośrednictwem portalu Azure.

Ograniczenia dotyczące migracji do warstwy usługi Krytyczne dla działania firmy

Podczas migracji do SQL Managed Instance w warstwie usługi Business Critical należy wziąć pod uwagę następujące ograniczenia:

• Podczas migrowania dużych baz danych może wystąpić znaczny przestój, ponieważ bazy danych są niedostępne po przełączeniu, gdy są replikowane do replik pomocniczych warstwy usługi Krytyczne dla działania firmy. Obejścia są wymienione w sekcji dłuższego przełączenia.
• Migracja jest automatycznie uruchamiana ponownie od początku, jeśli nieplanowana praca w trybie failover, aktualizacja systemu lub poprawka zabezpieczeń przerywa migrację. To ograniczenie utrudnia zaplanowanie przewidywalnej migracji bez niespodzianek w ostatniej chwili.

Dłuższe przecięcie w warstwie usługi Krytyczne dla działania firmy

Jeśli przeprowadzasz migrację do SQL Managed Instance w warstwie usługi Business Critical, uwzględnij opóźnienie w udostępnieniu baz danych w trybie online na replice podstawowej, gdy są one replikowane do replik pomocniczych. To opóźnienie dotyczy szczególnie większych baz danych.

Migrowanie do SQL Managed Instance w warstwie usługi Business Critical trwa dłużej niż w warstwie usługi General Purpose. Po zakończeniu migracji do Azure bazy danych są niedostępne, dopóki nie zostaną zsynchronizowane z repliki podstawowej do trzech replik pomocniczych. Proces zasiewania może zająć dużo czasu w zależności od rozmiaru bazy danych. Im większa baza danych, tym dłużej trwa rozmieszczanie kopii zapasowych - potencjalnie do kilku godzin.

Jeśli ważne jest, aby bazy danych były dostępne zaraz po zakończeniu przełączenia, rozważ następujące obejścia:

• Najpierw przeprowadź migrację do warstwy usługi Ogólnego przeznaczenia, a następnie uaktualnij ją do warstwy usługi Krytyczne dla działania firmy . Uaktualnienie poziomu usługi to operacja online, która utrzymuje bazy danych online, aż do krótkiego przełączenia w tryb awaryjny jako ostatniego kroku operacji uaktualniania.
• Użyj linku Managed Instance do migracji online wystąpienia Business Critical bez czekania na dostępność baz danych po przełączeniu.

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

Treści powiązane

• migracja SQL Server w Azure Arc
• Przygotuj środowisko do migracji linku Managed Instance
• Przegląd SQL Server obsługiwanego przez Azure Arc
• Przekaż opinie dotyczące migracji bezpośrednio do grupy produktu
• Migration do Azure SQL Managed Instance — migracja SQL Server w Azure Arc