Migrowanie usługi Azure SQL Database z modelu opartego na jednostkach DTU do modelu opartego na rdzeniach wirtualnych
Dotyczy: 
Azure SQL Database
W tym artykule opisano sposób migrowania bazy danych w usłudze Azure SQL Database z modelu zakupów opartego na jednostkach DTU do modelu zakupów opartego na rdzeniach wirtualnych.
Migrowanie bazy danych
Migrowanie bazy danych z modelu zakupów opartego na jednostkach DTU do modelu zakupów opartego na rdzeniach wirtualnych jest podobne do skalowania między celami usług w warstwach usług Podstawowa, Standardowa i Premium, z podobnym czasem trwania i minimalnym przestojem na końcu procesu migracji. Baza danych zmigrowana do modelu zakupów opartego na rdzeniach wirtualnych może zostać zmigrowana z powrotem do modelu zakupów opartego na jednostkach DTU w dowolnym momencie przy użyciu tych samych kroków, z wyjątkiem baz danych migrowanych do warstwy usługi Hiperskala .
Bazę danych można migrować do innego modelu zakupów przy użyciu witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia platformy Azure i języka Transact-SQL.
- Witryna Azure Portal
- Program PowerShell
- Interfejs wiersza polecenia platformy Azure
- Język Transact-SQL
Aby przeprowadzić migrację bazy danych do innego modelu zakupów przy użyciu witryny Azure Portal, wykonaj następujące kroki:
Przejdź do bazy danych SQL w witrynie Azure Portal.
Wybierz pozycję Obliczenia i magazyn w obszarze Ustawienia.
Użyj listy rozwijanej w obszarze Warstwa usługi, aby wybrać nowy model zakupów i warstwę usług:
Wybieranie warstwy usługi i celu usługi rdzeni wirtualnych
W przypadku większości scenariuszy migracji jednostek DTU do rdzeni wirtualnych bazy danych i pul elastycznych w warstwach usług Podstawowa i Standardowa są mapowana na warstwę usługi Ogólnego przeznaczenia . Bazy danych i elastyczne pule w warstwie usługi Premium są mapowana na warstwę usługi Krytyczne dla działania firmy. W zależności od scenariusza i wymagań aplikacji warstwa usługi Hiperskala może być często używana jako cel migracji dla baz danych i elastycznych pul we wszystkich warstwach usług DTU.
Aby wybrać cel usługi lub rozmiar obliczeniowy, dla zmigrowanej bazy danych w modelu rdzeni wirtualnych można użyć podstawowej, ale przybliżonej reguły kciuka: co 100 jednostek DTU w warstwach Podstawowa lub Standardowa wymaga co najmniej 1 rdzeni wirtualnych, a co 125 jednostek DTU w warstwie Premium wymaga co najmniej 1 rdzeni wirtualnych.
Napiwek
Ta reguła jest przybliżona, ponieważ nie uwzględnia określonego typu sprzętu używanego dla bazy danych DTU lub elastycznej puli.
W modelu JEDNOSTEK DTU system może wybrać dowolną dostępną konfigurację sprzętu dla bazy danych lub elastycznej puli. Ponadto w modelu DTU masz tylko pośrednią kontrolę nad liczbą rdzeni wirtualnych (procesorów logicznych), wybierając wyższą lub niższą liczbę jednostek DTU lub eDTU.
W modelu rdzeni wirtualnych klienci muszą dokonać wyraźnego wyboru zarówno konfiguracji sprzętu, jak i liczby rdzeni wirtualnych (procesorów logicznych). Chociaż model jednostek DTU nie oferuje tych opcji, typ sprzętu i liczba logicznych procesorów CPU używanych dla każdej bazy danych i elastycznej puli są widoczne za pośrednictwem dynamicznych widoków zarządzania. Dzięki temu można dokładniej określić pasujący cel usługi rdzeni wirtualnych.
Poniższe podejście wykorzystuje te informacje do określenia celu usługi rdzeni wirtualnych z podobną alokacją zasobów w celu uzyskania podobnego poziomu wydajności po migracji do modelu rdzeni wirtualnych.
Mapowanie jednostek DTU na rdzenie wirtualne
Następujące zapytanie Języka Transact-SQL, wykonywane w kontekście bazy danych DTU do zmigrowania, zwraca zgodną (prawdopodobnie ułamkową) liczbę rdzeni wirtualnych w każdej konfiguracji sprzętu w modelu rdzeni wirtualnych. Tę liczbę można zaokrąglić do najbliższej liczby rdzeni wirtualnych dostępnych dla baz danych i elastycznych pul w każdej konfiguracji sprzętu w modelu rdzeni wirtualnych. Klienci mogą wybrać cel usługi rdzeni wirtualnych, który jest najbliższym dopasowaniem dla bazy danych DTU lub elastycznej puli.
Przykładowe scenariusze migracji korzystające z tego podejścia zostały opisane w sekcji Przykłady .
Wykonaj to zapytanie w kontekście bazy danych, która ma zostać zmigrowana, a nie w master bazie danych. Podczas migracji elastycznej puli wykonaj zapytanie w kontekście dowolnej bazy danych w puli.
;WITH dtu_vcore_map
AS (
SELECT rg.slo_name,
CAST(DATABASEPROPERTYEX(DB_NAME(), 'Edition') AS NVARCHAR(40)) COLLATE DATABASE_DEFAULT AS dtu_service_tier,
CASE
WHEN slo.slo_name LIKE '%SQLG4%' THEN 'Gen4' --Gen4 is retired.
WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4' --Gen4 is retired.
WHEN slo.slo_name LIKE '%SQLG5%' THEN 'standard_series'
WHEN slo.slo_name LIKE '%SQLG6%' THEN 'standard_series'
WHEN slo.slo_name LIKE '%SQLG7%' THEN 'standard_series'
WHEN slo.slo_name LIKE '%GPGEN8%' THEN 'standard_series'
END COLLATE DATABASE_DEFAULT AS dtu_hardware_gen,
s.scheduler_count * CAST(rg.instance_cap_cpu / 100. AS DECIMAL(3, 2)) AS dtu_logical_cpus,
CAST((jo.process_memory_limit_mb / s.scheduler_count) / 1024. AS DECIMAL(4, 2)) AS dtu_memory_per_core_gb
FROM sys.dm_user_db_resource_governance AS rg
CROSS JOIN (
SELECT COUNT(1) AS scheduler_count
FROM sys.dm_os_schedulers
WHERE status COLLATE DATABASE_DEFAULT = 'VISIBLE ONLINE'
) AS s
CROSS JOIN sys.dm_os_job_object AS jo
CROSS APPLY (SELECT UPPER(rg.slo_name) COLLATE DATABASE_DEFAULT AS slo_name) slo
WHERE rg.dtu_limit > 0
AND DB_NAME() COLLATE DATABASE_DEFAULT <> 'master'
AND rg.database_id = DB_ID()
)
SELECT dtu_logical_cpus,
dtu_memory_per_core_gb,
dtu_service_tier,
CASE
WHEN dtu_service_tier = 'Basic' THEN 'General Purpose'
WHEN dtu_service_tier = 'Standard' THEN 'General Purpose or Hyperscale'
WHEN dtu_service_tier = 'Premium' THEN 'Business Critical or Hyperscale'
END AS vcore_service_tier,
CASE
WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.7
WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus
END AS standard_series_vcores,
5.05 AS standard_series_memory_per_core_gb,
CASE
WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus
WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.8
END AS Fsv2_vcores,
1.89 AS Fsv2_memory_per_core_gb,
CASE
WHEN dtu_hardware_gen = 'Gen4' THEN dtu_logical_cpus * 1.4
WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.9
END AS M_vcores,
29.4 AS M_memory_per_core_gb
FROM dtu_vcore_map;
Dodatkowe czynniki
Oprócz liczby rdzeni wirtualnych (procesorów logicznych) i typu sprzętu kilka innych czynników może mieć wpływ na wybór celu usługi rdzeni wirtualnych:
Mapowanie zapytania Transact-SQL odpowiada celom jednostek DTU i usług rdzeni wirtualnych pod względem ich pojemności procesora CPU, dlatego wyniki są dokładniejsze dla obciążeń powiązanych z procesorem CPU.
W przypadku tego samego typu sprzętu i tej samej liczby rdzeni wirtualnych limity zasobów przepływności operacji we/wy na sekundę i dziennika transakcji dla baz danych rdzeni wirtualnych są często wyższe niż w przypadku baz danych jednostek DTU. W przypadku obciążeń związanych z operacjami we/wy może być możliwe obniżenie liczby rdzeni wirtualnych w modelu rdzeni wirtualnych w celu osiągnięcia tego samego poziomu wydajności. Rzeczywiste limity zasobów dla baz danych jednostek DTU i rdzeni wirtualnych są widoczne w widoku sys.dm_user_db_resource_governance . Porównanie tych wartości między bazą danych lub pulą jednostek DTU do zmigrowania oraz bazą danych lub pulą rdzeni wirtualnych z około pasującym celem usługi może pomóc dokładniej wybrać cel usługi rdzeni wirtualnych.
Zapytanie mapowania zwraca również ilość pamięci na rdzeń dla bazy danych DTU lub elastycznej puli do zmigrowania oraz dla każdej konfiguracji sprzętu w modelu rdzeni wirtualnych. Zapewnienie podobnej lub większej całkowitej ilości pamięci po migracji do rdzeni wirtualnych jest ważne w przypadku obciążeń wymagających dużej pamięci podręcznej danych w celu osiągnięcia wystarczającej wydajności lub obciążeń wymagających dużych przydziałów pamięci na potrzeby przetwarzania zapytań. W przypadku takich obciążeń w zależności od rzeczywistej wydajności może być konieczne zwiększenie liczby rdzeni wirtualnych w celu uzyskania wystarczającej całkowitej ilości pamięci.
Historyczne wykorzystanie zasobów bazy danych DTU należy wziąć pod uwagę podczas wybierania celu usługi rdzeni wirtualnych. Bazy danych jednostek DTU ze stale niedostatecznie wykorzystywanymi zasobami procesora CPU mogą wymagać mniejszej liczby rdzeni wirtualnych niż liczba zwracana przez zapytanie mapowania. Z drugiej strony bazy danych jednostek DTU, w których stale wysokie wykorzystanie procesora CPU powoduje niewystarczającą wydajność obciążenia, może wymagać więcej rdzeni wirtualnych niż zwracane przez zapytanie.
W przypadku migrowania baz danych z sporadycznymi lub nieprzewidywalnymi wzorcami użycia rozważ użycie bezserwerowej warstwy obliczeniowej dla warstwy obliczeniowej usługi Azure SQL Database . Maksymalna liczba współbieżnych procesów roboczych w trybie bezserwerowym wynosi 75% limitu w aprowizowanych obliczeniach dla tej samej liczby skonfigurowanych maksymalnej liczby rdzeni wirtualnych. Ponadto maksymalna ilość pamięci dostępnej w trybie bezserwerowym wynosi 3 GB niż maksymalna liczba skonfigurowanych rdzeni wirtualnych, która jest mniejsza niż pamięć na rdzeń dla aprowizowania zasobów obliczeniowych. Na przykład maksymalna pamięć gen5 wynosi 120 GB, gdy maksymalnie 40 rdzeni wirtualnych jest skonfigurowanych w trybie bezserwerowym, a 204 GB dla aprowizowanego procesora obliczeniowego z 40 rdzeniami wirtualnymi.
W modelu rdzeni wirtualnych obsługiwany maksymalny rozmiar bazy danych może się różnić w zależności od sprzętu. W przypadku dużych baz danych sprawdź obsługiwane maksymalne rozmiary w modelu rdzeni wirtualnych dla pojedynczych baz danych i pul elastycznych.
W przypadku pul elastycznych limity zasobów dla pul elastycznych przy użyciu modelu zakupów jednostek DTU i modeli rdzeni wirtualnych mają różnice w maksymalnej obsługiwanej liczbie baz danych na pulę. Należy to wziąć pod uwagę podczas migracji elastycznych pul z wieloma bazami danych.
Niektóre konfiguracje sprzętowe mogą nie być dostępne w każdym regionie. Sprawdź dostępność w obszarze Konfiguracja sprzętu dla usługi SQL Database.
Wytyczne dotyczące określania rozmiaru jednostek DTU do rdzeni wirtualnych podane w tej sekcji pomagają w początkowym oszacowaniu docelowego celu usługi bazy danych.
Optymalna konfiguracja docelowej bazy danych jest zależna od obciążenia. W związku z tym, aby osiągnąć optymalny stosunek ceny/wydajności po migracji, może być konieczne użycie elastyczności modelu rdzeni wirtualnych w celu dostosowania liczby rdzeni wirtualnych, konfiguracji sprzętu i warstw usług i obliczeń. Może być również konieczne dostosowanie parametrów konfiguracji bazy danych, takich jak maksymalny stopień równoległości i/lub zmiana poziomu zgodności bazy danych w celu włączenia ostatnich ulepszeń aparatu bazy danych.
Przykłady migracji jednostek DTU do rdzeni wirtualnych
Uwaga
Wartości w poniższych przykładach są przeznaczone tylko do celów ilustracyjnych. Rzeczywiste wartości zwracane w opisanych scenariuszach mogą być inne.
Migrowanie standardowej bazy danych S9
Zapytanie mapowania zwraca następujący wynik (niektóre kolumny nie są wyświetlane w celu zwięzłości):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 24.00 | 5,40 | 24.000 | 5,05 |
Widzimy, że standardowa baza danych DTU ma 24 procesory logiczne (rdzenie wirtualne), z 5,4 GB pamięci na rdzeń wirtualny. Bezpośrednie dopasowanie do tego jest bazą danych ogólnego przeznaczenia 2 rdzeni wirtualnych na sprzęcie z serii Standardowa (Gen5), celem usługi GP_Gen5_24 rdzeni wirtualnych.
Migrowanie standardowej bazy danych S0
Zapytanie mapowania zwraca następujący wynik (niektóre kolumny nie są wyświetlane w celu zwięzłości):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 0.25 | 1.3 | 0.500 | 5,05 |
Widzimy, że baza danych DTU ma odpowiednik 0,25 procesorów logicznych (rdzeni wirtualnych), z 1,3 GB pamięci na rdzeń wirtualny. Najmniejsze cele usługi rdzeni wirtualnych w konfiguracji sprzętowej serii standardowej (Gen5), GP_Gen5_2, zapewniają więcej zasobów obliczeniowych niż standardowa baza danych S0, więc bezpośrednie dopasowanie nie jest możliwe. Preferowana jest opcja GP_Gen5_2 . Ponadto jeśli obciążenie jest odpowiednie dla bezserwerowej warstwy obliczeniowej, GP_S_Gen5_1 byłoby bliżej dopasowane.
Migrowanie bazy danych Premium P15
Zapytanie mapowania zwraca następujący wynik (niektóre kolumny nie są wyświetlane w celu zwięzłości):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 42.00 | 4.86 | 42.000 | 5,05 |
Widzimy, że baza danych DTU ma 42 procesory logiczne (rdzenie wirtualne), z 4,86 GB pamięci na rdzeń wirtualny. Chociaż nie ma celu usługi rdzeni wirtualnych z 42 rdzeniami, cel usługi BC_Gen5_40 jest prawie równoważny pod względem wydajności procesora CPU i pamięci i jest dobrym dopasowaniem.
Migrowanie elastycznej puli podstawowej 200 eDTU
Zapytanie mapowania zwraca następujący wynik (niektóre kolumny nie są wyświetlane w celu zwięzłości):
| dtu_logical_cpus | dtu_memory_per_core_gb | standard_series_vcores | standard_series_memory_per_core_gb |
|---|---|---|---|
| 4,00 | 5,40 | 4000 | 5,05 |
Widzimy, że elastyczna pula DTU ma 4 logiczne procesory CPU (rdzenie wirtualne), z 5,4 GB pamięci na rdzeń wirtualny. Sprzęt serii Standardowa wywołuje jednak 4 rdzenie wirtualne, jednak ten cel usługi obsługuje maksymalnie 200 baz danych na pulę, podczas gdy elastyczna pula podstawowa 200 eDTU obsługuje maksymalnie 500 baz danych. Jeśli migrowana elastyczna pula ma ponad 200 baz danych, pasujący cel usługi rdzeni wirtualnych musi być GP_Gen5_6, który obsługuje maksymalnie 500 baz danych.
Migrowanie baz danych replikowanych geograficznie
Migracja z modelu opartego na jednostkach DTU do modelu zakupów opartego na rdzeniach wirtualnych jest podobna do uaktualniania lub obniżania relacji replikacji geograficznej między bazami danych w warstwach usług Standardowa i Premium. Podczas migracji nie trzeba zatrzymywać replikacji geograficznej dla warstw ogólnego przeznaczenia i Krytyczne dla działania firmy usług, ale należy przestrzegać następujących reguł sekwencjonowania:
- Podczas uaktualniania należy najpierw uaktualnić pomocniczą bazę danych, a następnie uaktualnić bazę podstawową.
- Podczas obniżania poziomu należy odwrócić kolejność: najpierw należy obniżyć podstawową bazę danych, a następnie obniżyć dół pomocniczej bazy danych.
Aby przeprowadzić migrację do warstwy usługi Hiperskala, replikacja geograficzna powinna zostać tymczasowo usunięta. Aby uzyskać więcej informacji, zobacz Migrowanie istniejącej bazy danych do warstwy Hiperskala.
W przypadku korzystania z replikacji geograficznej między dwiema elastycznymi pulami zalecamy wyznaczenie jednej puli jako podstawowej i drugiej jako pomocniczej. W takim przypadku podczas migracji elastycznych pul należy użyć tych samych wskazówek dotyczących sekwencjonowania. Jeśli jednak masz elastyczne pule zawierające zarówno podstawowe, jak i pomocnicze bazy danych, należy traktować pulę z wyższym wykorzystaniem jako podstawową i odpowiednio postępować zgodnie z regułami sekwencjonowania.
Poniższa tabela zawiera wskazówki dotyczące określonych scenariuszy migracji:
| Bieżąca warstwa usługi | Docelowa warstwa usługi | Typ migracji | Akcje użytkownika |
|---|---|---|---|
| Standardowa | Ogólnego przeznaczenia | Boczny | Można przeprowadzić migrację w dowolnej kolejności, ale należy zapewnić odpowiednie rozmiary rdzeni wirtualnych zgodnie z wcześniejszym opisem |
| Premium | Krytyczne dla działania firmy | Boczny | Można przeprowadzić migrację w dowolnej kolejności, ale należy zapewnić odpowiednie rozmiary rdzeni wirtualnych zgodnie z wcześniejszym opisem |
| Standardowa | Krytyczne dla działania firmy | Uaktualnienie | Najpierw należy przeprowadzić migrację pomocniczą |
| Krytyczne dla działania firmy | Standardowa | Zmiana na starszą lub mniej zaawansowaną wersję | Najpierw należy przeprowadzić migrację podstawowego |
| Premium | Ogólnego przeznaczenia | Zmiana na starszą lub mniej zaawansowaną wersję | Najpierw należy przeprowadzić migrację podstawowego |
| Ogólnego przeznaczenia | Premium | Uaktualnienie | Najpierw należy przeprowadzić migrację pomocniczą |
| Krytyczne dla działania firmy | Ogólnego przeznaczenia | Zmiana na starszą lub mniej zaawansowaną wersję | Najpierw należy przeprowadzić migrację podstawowego |
| Ogólnego przeznaczenia | Krytyczne dla działania firmy | Uaktualnienie | Najpierw należy przeprowadzić migrację pomocniczą |
| Standardowa | Hiperskala | Boczny | Replikacja geograficzna do wyłączenia przed migracją do warstwy Hiperskala |
| Premium | Hiperskala | Boczny | Replikacja geograficzna do wyłączenia przed migracją do warstwy Hiperskala |
Migrowanie grup trybu failover
Migracja grup trybu failover z wieloma bazami danych wymaga indywidualnej migracji podstawowych i pomocniczych baz danych. W trakcie tego procesu mają zastosowanie te same zagadnienia i reguły sekwencjonowania. Po przekonwertowaniu baz danych na model zakupów oparty na rdzeniach wirtualnych grupa trybu failover pozostanie w mocy z tymi samymi ustawieniami zasad.
Tworzenie pomocniczej bazy danych replikacji geograficznej
Dodatkową bazę danych replikacji geograficznej (pomocniczą geograficzną) można utworzyć tylko przy użyciu tej samej warstwy usługi, która była używana dla podstawowej bazy danych. W przypadku baz danych o wysokim współczynniku generowania dzienników zalecamy utworzenie pomocniczego obszaru geograficznego o takim samym rozmiarze obliczeniowym jak podstawowy.
W przypadku utworzenia pomocniczego obszaru geograficznego w elastycznej puli dla pojedynczej podstawowej bazy danych upewnij się, że maxVCore ustawienie puli jest zgodne z rozmiarem obliczeniowym podstawowej bazy danych. W przypadku utworzenia pomocniczego obszaru geograficznego dla elementu podstawowego w innej elastycznej puli zalecamy, aby pule miały te same maxVCore ustawienia.
Migrowanie z jednostek DTU do rdzeni wirtualnych przy użyciu kopiowania bazy danych
Kopia bazy danych tworzy transakcyjnie spójną migawkę danych w określonym momencie po rozpoczęciu operacji kopiowania. Nie synchronizuje danych między źródłem a obiektem docelowym po tym punkcie w czasie.
Dowolną bazę danych z rozmiarem obliczeniowym opartym na jednostkach DTU można skopiować do bazy danych o rozmiarze obliczeniowym opartym na rdzeniach wirtualnych przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure lub języka Transact-SQL bez ograniczeń lub specjalnego sekwencjonowania, o ile docelowy rozmiar obliczeniowy obsługuje maksymalny rozmiar bazy danych źródłowej bazy danych. Kopiowanie bazy danych do innej warstwy usługi nie jest obsługiwane w witrynie Azure Portal.