Migrowanie bazy danych Azure SQL z modelu opartego na jednostkach DTU do modelu opartego na rdzeniach wirtualnych

  • Artykuł
  • Czas czytania: 11 min

Dotyczy: baza danych Azure SQL

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 opartegona rdzeniach wirtualnych.

Migrowanie bazy danych

Migracja bazy danych z modelu zakupów opartego na jednostkach DTU do modelu zakupów opartego na rdzeniach wirtualnych jest podobna do skalowania między celami usług w warstwach usługi 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 w taki sam sposób, z wyjątkiem baz danych migrowanych do warstwy usługi Hiperskala .

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ługi Podstawowa i Standardowa zostaną zamapowana na warstwę usługi Ogólnego przeznaczenia. Bazy danych i elastyczne pule w warstwie usługi Premium będą mapować 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 pojedynczych baz danych 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ć prostej, ale przybliżonej reguły kciuka: co 100 jednostek DTU w warstwie Podstawowa lub Standardowa wymaga co najmniej 1 rdzeni wirtualnych, a co 125 jednostek DTU w warstwie Premium wymaga co najmniej 1 rdzeni wirtualnych.

Porada

Ta reguła jest przybliżona, ponieważ nie uwzględnia określonego typu sprzętu używanego dla bazy danych DTU lub puli elastycznej.

W modelu 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 (logicznych procesorów CPU), wybierając wyższą lub niższą liczbę jednostek DTU lub eDTU.

W modelu rdzeni wirtualnych klienci muszą dokonać jawnego wyboru zarówno konfiguracji sprzętu, jak i liczby rdzeni wirtualnych (logicznych procesorów CPU). Chociaż model DTU nie oferuje tych opcji, typ sprzętu i liczba logicznych procesorów 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 używa tych informacji 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

Poniższe zapytanie T-SQL, wykonywane w kontekście bazy danych DTU do migracji, zwraca zgodną (prawdopodobnie ułamkową) liczbę rdzeni wirtualnych w każdej konfiguracji sprzętu w modelu rdzeni wirtualnych. Zaokrąglając tę liczbę do najbliższej liczby rdzeni wirtualnych dostępnych dla baz danych i pul elastycznych 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 jednostek DTU lub puli elastycznej.

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'
            WHEN slo.slo_name LIKE '%SQLGZ%' THEN 'Gen4'
            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
            WHEN dtu_hardware_gen = 'standard_series' THEN dtu_logical_cpus * 0.7
       END AS Gen4_vcores,
       7 AS Gen4_memory_per_core_gb,
       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 (logicznych procesorów CPU) 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 pojemności procesora CPU, dlatego wyniki będą bardziej dokładne 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ń powiązanych z operacjami we/wy można zmniejszyć liczbę 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, a baza danych lub pula rdzeni wirtualnych z przybliżonym celem usługi pomoże Ci 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ętowej w modelu rdzeni wirtualnych. Zapewnienie podobnej lub większej całkowitej ilości pamięci po migracji do rdzeni wirtualnych jest ważne dla obciążeń, które wymagają dużej pamięci podręcznej danych pamięci w celu osiągnięcia wystarczającej wydajności lub obciążeń wymagających dużych dotacji 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 używanymi 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 nieodpowiednią wydajność obciążenia, może wymagać więcej rdzeni wirtualnych niż zwracane przez zapytanie.
  • Jeśli migrowanie baz danych ze sporadycznymi lub nieprzewidywalnymi wzorcami użycia, rozważ użycie warstwy obliczeniowej bezserwerowej. Należy pamiętać, że maksymalna liczba współbieżnych procesów roboczych bezserwerowych wynosi 75% limitu w aprowizowanych obliczeniach dla tej samej liczby skonfigurowanych maksymalnej liczby rdzeni wirtualnych. Ponadto maksymalna ilość dostępnej pamięci bezserwerowej wynosi 3 GB razy większa niż maksymalna liczba skonfigurowanych rdzeni wirtualnych, która jest mniejsza niż pamięć na rdzeń dla aprowizowania zasobów obliczeniowych. Na przykład maksymalna ilość pamięci gen5 wynosi 120 GB, gdy 40 maksymalnych rdzeni wirtualnych jest skonfigurowanych bezserwerowo, a 204 GB dla aprowizowanej mocy obliczeniowej 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 modele jednostek DTU i rdzeni wirtualnych mają różnice w maksymalnej obsługiwanej liczbie baz danych na pulę. Należy to wziąć pod uwagę podczas migrowania 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 SQL Database.

Ważne

Powyższe wytyczne dotyczące ustalania rozmiaru jednostek DTU do rdzeni wirtualnych ułatwiają wstępne oszacowanie 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 wykorzystanie 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. Wartości rzeczywiste zwracane w opisanych scenariuszach mogą być różne.

Migrowanie standardowej bazy danych S9

Zapytanie mapowania zwraca następujący wynik (niektóre kolumny nie są wyświetlane dla zwięzłości):

dtu_logical_cpus dtu_memory_per_core_gb Gen4_vcores Gen4_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
24.00 5.40 16.800 7 24.000 5.05

Widzimy, że baza danych DTU ma 24 logiczne procesory CPU (rdzenie wirtualne), z 5,4 GB pamięci na rdzeń wirtualny. Bezpośrednie dopasowanie do tego jest bazą danych Ogólnego przeznaczenia 24 rdzeni wirtualnych na sprzęcie 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 dla zwięzłości):

dtu_logical_cpus dtu_memory_per_core_gb Gen4_vcores Gen4_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
0,25 0.42 0,250 7 0,425 5.05

Widzimy, że baza danych DTU ma odpowiednik 0,25 logicznych procesorów CPU (rdzeni wirtualnych), z 0,42 GB pamięci na rdzeń wirtualny. Najmniejsze cele usługi rdzeni wirtualnych w konfiguracji sprzętowej serii Standardowa (Gen5), GP_Gen5_2, zapewniają więcej zasobów obliczeniowych niż Standardowa S0 bazy danych, więc bezpośrednie dopasowanie nie jest możliwe. Ponieważ sprzęt gen4 jest likwidowany, preferowana jest opcja GP_Gen5_2 . Ponadto jeśli obciążenie jest dobrze dopasowane do warstwy obliczeniowej bezserwerowej , GP_S_Gen5_1 będzie bliżej dopasowana.

Migrowanie bazy danych Premium P15

Zapytanie mapowania zwraca następujący wynik (niektóre kolumny nie są wyświetlane dla zwięzłości):

dtu_logical_cpus dtu_memory_per_core_gb Gen4_vcores Gen4_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
42.00 4.86 29.400 7 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 bardzo blisko zarówno pod względem wydajności procesora, jak i pamięci, i jest dobrym rozwiązaniem.

Migrowanie elastycznej puli eDTU w warstwie Podstawowa 200

Zapytanie mapowania zwraca następujący wynik (niektóre kolumny nie są wyświetlane dla zwięzłości):

dtu_logical_cpus dtu_memory_per_core_gb Gen4_vcores Gen4_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
4,00 5.40 2.800 7 4.000 5.05

Widzimy, że elastyczna pula DTU ma 4 procesory logiczne (rdzenie wirtualne), z 5,4 GB pamięci na rdzeń wirtualny. Bezpośrednie dopasowanie w modelu rdzeni wirtualnych jest GP_Gen5_4 elastyczną pulą. Jednak ten cel usługi obsługuje maksymalnie 200 baz danych na pulę, podczas gdy elastyczna pula jednostek eDTU w warstwie Podstawowa 200 obsługuje maksymalnie 500 baz danych. Jeśli migrowana elastyczna pula zawiera 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ługi Standardowa i Premium. Podczas migracji nie trzeba zatrzymywać replikacji geograficznej, ale należy postępować zgodnie z następującymi regułami 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.

W przypadku korzystania z replikacji geograficznej między dwiema elastycznymi pulami zalecamy wyznaczenie jednej puli jako podstawowej, a drugiej jako pomocniczej. W takim przypadku podczas migrowania pul elastycznych należy użyć tych samych wskazówek dotyczących sekwencjonowania. Jeśli jednak masz elastyczne pule, które zawierają 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 konkretnych scenariuszy migracji:

Bieżąca warstwa usługi Docelowa warstwa usługi Typ migracji Akcje użytkownika
Standardowa (Standard) Ogólnego przeznaczenia Boczne Można przeprowadzić migrację w dowolnej kolejności, ale należy zapewnić odpowiednie rozmiary rdzeni wirtualnych zgodnie z powyższym opisem
Premium Krytyczne dla działania firmy Boczne Można przeprowadzić migrację w dowolnej kolejności, ale należy zapewnić odpowiednie rozmiary rdzeni wirtualnych zgodnie z powyższym opisem
Standardowa (Standard) Krytyczne dla działania firmy Uaktualnienie Najpierw należy przeprowadzić migrację pomocniczą
Krytyczne dla działania firmy Standardowa (Standard) 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ą

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

Pomocniczą 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 wysokiej szybkości generowania dzienników zalecamy utworzenie pomocniczego obszaru geograficznego o takim samym rozmiarze obliczeniowym jak podstawowy.

Jeśli tworzysz pomocniczy obszar geograficzny w elastycznej puli dla pojedynczej podstawowej bazy danych, upewnij się, że maxVCore ustawienie puli jest zgodne z rozmiarem obliczeniowym podstawowej bazy danych. Jeśli tworzysz pomocniczy obszar geograficzny dla bazy podstawowej w innej elastycznej puli, zalecamy, aby pule miały te same maxVCore ustawienia.

Migrowanie z jednostek DTU do rdzeni wirtualnych przy użyciu kopii bazy danych

Możesz skopiować dowolną bazę danych o rozmiarze obliczeniowym opartym na jednostkach DTU do bazy danych z rozmiarem obliczeniowym opartym na rdzeniach wirtualnych bez ograniczeń ani specjalnego sekwencjonowania, o ile docelowy rozmiar obliczeniowy obsługuje maksymalny rozmiar bazy danych źródłowej bazy danych. Kopia bazy danych tworzy transakcyjnie spójną migawkę danych w określonym punkcie w czasie po rozpoczęciu operacji kopiowania. Nie synchronizuje danych między źródłem a obiektem docelowym po tym punkcie w czasie.

Następne kroki