Azure SQL Database migreren van het DTU-model naar het vCore-model

  • Artikel

Van toepassing op: Azure SQL Database

In dit artikel wordt beschreven hoe u uw database in Azure SQL Database migreert van het aankoopmodel op basis van DTU naar het aankoopmodel op basis van vCore.

Een database migreren

Het migreren van een database van het aankoopmodel op basis van DTU naar het aankoopmodel op basis van vCore is vergelijkbaar met het schalen tussen servicedoelstellingen in de servicelagen Basic, Standard en Premium, met vergelijkbare duur en minimale downtime aan het einde van het migratieproces. Een database die is gemigreerd naar het aankoopmodel op basis van vCore, kan op elk gewenst moment worden gemigreerd naar het aankoopmodel op basis van DTU, met uitzondering van databases die zijn gemigreerd naar de Hyperscale-servicelaag .

De vCore-servicelaag en servicedoelstelling kiezen

Voor de meeste DTU-naar-vCore-migratiescenario's worden databases en elastische pools in de Basic- en Standard-servicelagen toegewezen aan de servicelaag Algemeen gebruik . Databases en elastische pools in de Premium-servicelaag worden toegewezen aan de servicelaag Bedrijfskritiek . Afhankelijk van het toepassingsscenario en de vereisten kan de Hyperscale-servicelaag vaak worden gebruikt als migratiedoel voor databases en elastische pools in alle DTU-servicelagen.

Als u de servicedoelstelling of rekengrootte wilt kiezen, kunt u voor de gemigreerde database in het vCore-model een eenvoudige maar geschatte vuistregel gebruiken: elke 100 DTU's in de Basic- of Standard-laag vereisen ten minste 1 vCore en elke 125 DTU's in de Premium-laag vereisen ten minste 1 vCore.

Fooi

Deze regel is bij benadering omdat er geen rekening wordt gehouden met het specifieke type hardware dat wordt gebruikt voor de DTU-database of elastische pool.

In het DTU-model kan het systeem elke beschikbare hardwareconfiguratie voor uw database of elastische pool selecteren. Verder hebt u in het DTU-model alleen indirecte controle over het aantal vCores (logische CPU's) door hogere of lagere DTU- of eDTU-waarden te kiezen.

In het vCore-model moeten klanten een expliciete keuze maken voor zowel de hardwareconfiguratie als het aantal vCores (logische CPU's). Hoewel het DTU-model deze opties niet biedt, worden hardwaretype en het aantal logische CPU's dat wordt gebruikt voor elke database en elastische pool weergegeven via dynamische beheerweergaven. Dit maakt het mogelijk om de overeenkomende vCore-servicedoelstelling nauwkeuriger te bepalen.

De volgende benadering gebruikt deze informatie om een vCore-servicedoelstelling te bepalen met een vergelijkbare toewijzing van resources, om na de migratie naar het vCore-model een vergelijkbaar prestatieniveau te verkrijgen.

Toewijzing van DTU naar vCore

Een T-SQL-query hieronder, wanneer deze wordt uitgevoerd in de context van een te migreren DTU-database, retourneert een overeenkomend (mogelijk fractioneel) aantal vCores in elke hardwareconfiguratie in het vCore-model. U kunt dit aantal afronden op het dichtstbijzijnde aantal vCores dat beschikbaar is voor databases en elastische pools in elke hardwareconfiguratie in het vCore-model. Klanten kunnen de vCore-servicedoelstelling kiezen die het dichtst bij hun DTU-database of elastische pool past.

Voorbeeldmigratiescenario's die deze aanpak gebruiken, worden beschreven in de sectie Voorbeelden .

Voer deze query uit in de context van de database die moet worden gemigreerd in plaats van in de master database. Wanneer u een elastische pool migreert, voert u de query uit in de context van een database in de pool.


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;

Aanvullende factoren

Naast het aantal vCores (logische CPU's) en het type hardware kunnen verschillende andere factoren van invloed zijn op de keuze van de vCore-servicedoelstelling:

  • De transact-SQL-query voor toewijzingen komt overeen met de DTU- en vCore-servicedoelstellingen in termen van hun CPU-capaciteit. De resultaten zijn daarom nauwkeuriger voor CPU-afhankelijke workloads.
  • Voor hetzelfde hardwaretype en hetzelfde aantal vCores zijn IOPS- en transactielogboekdoorvoerresourcelimieten voor vCore-databases vaak hoger dan voor DTU-databases. Voor IO-afhankelijke workloads is het mogelijk om het aantal vCores in het vCore-model te verlagen om hetzelfde prestatieniveau te bereiken. Werkelijke resourcelimieten voor DTU- en vCore-databases worden weergegeven in de weergave sys.dm_user_db_resource_governance . Als u deze waarden vergelijkt tussen de DTU-database of -pool die moet worden gemigreerd en een vCore-database of -pool met een ongeveer overeenkomende servicedoelstelling, kunt u de vCore-servicedoelstelling nauwkeuriger selecteren.
  • De toewijzingsquery retourneert ook de hoeveelheid geheugen per kern voor de DTU-database of elastische pool die moet worden gemigreerd, en voor elke hardwareconfiguratie in het vCore-model. Het garanderen van vergelijkbaar of hoger totaal geheugen na migratie naar vCore is belangrijk voor workloads waarvoor een grote geheugengegevenscache nodig is om voldoende prestaties te bereiken, of werkbelastingen waarvoor grote geheugentoelagen nodig zijn voor het verwerken van query's. Afhankelijk van de werkelijke prestaties kan het nodig zijn om het aantal vCores te verhogen om voldoende geheugen te krijgen voor dergelijke workloads.
  • Het historische resourcegebruik van de DTU-database moet worden overwogen bij het kiezen van de vCore-servicedoelstelling. DTU-databases met consistent onderbenutte CPU-resources hebben mogelijk minder vCores nodig dan het aantal dat wordt geretourneerd door de toewijzingsquery. DTU-databases waar consistent hoog CPU-gebruik leidt tot onvoldoende workloadprestaties, kunnen daarentegen meer vCores vereisen dan door de query wordt geretourneerd.
  • Als u databases migreert met onregelmatige of onvoorspelbare gebruikspatronen, kunt u overwegen om de serverloze rekenlaag te gebruiken. Houd er rekening mee dat het maximum aantal gelijktijdige werkrollen in serverloze servers 75% van de limiet is in ingerichte rekenkracht voor hetzelfde aantal maximaal geconfigureerde vCores. Bovendien is het maximale geheugen dat beschikbaar is in serverloos, 3 GB maal het maximum aantal geconfigureerde vCores, dat kleiner is dan het per-coregeheugen voor ingerichte rekenkracht. Zo is het maximale geheugen van Gen5 120 GB wanneer 40 maximale vCores zijn geconfigureerd in serverloos, versus 204 GB voor een 40 vCore-rekenkracht.
  • In het vCore-model kan de ondersteunde maximale databasegrootte verschillen, afhankelijk van hardware. Voor grote databases controleert u de ondersteunde maximale grootten in het vCore-model voor individuele databases en elastische pools.
  • Voor elastische pools hebben de DTU - en vCore-modellen verschillen in het maximaal ondersteunde aantal databases per pool. Dit moet worden overwogen bij het migreren van elastische pools met veel databases.
  • Sommige hardwareconfiguraties zijn mogelijk niet beschikbaar in elke regio. Controleer de beschikbaarheid onder Hardwareconfiguratie voor SQL Database.

Belangrijk

De bovenstaande richtlijnen voor het aanpassen van de grootte van DTU naar vCores worden verstrekt om u te helpen bij de eerste schatting van de doeldatabaseservicedoelstelling.

De optimale configuratie van de doeldatabase is afhankelijk van de workload. Om de optimale prijs-/prestatieverhouding na de migratie te bereiken, moet u mogelijk gebruikmaken van de flexibiliteit van het vCore-model om het aantal vCores, hardwareconfiguratie en service- en rekenlagen aan te passen. Mogelijk moet u ook databaseconfiguratieparameters aanpassen, zoals maximale mate van parallelle uitvoering en/of het compatibiliteitsniveau van de database wijzigen om recente verbeteringen in de database-engine mogelijk te maken.

Voorbeelden van DTU-naar-vCore-migratie

Notitie

De waarden in de onderstaande voorbeelden zijn alleen ter illustratie bedoeld. De werkelijke waarden die in beschreven scenario's worden geretourneerd, kunnen afwijken.

Een Standard S9-database migreren

De toewijzingsquery retourneert het volgende resultaat (sommige kolommen worden niet weergegeven voor beknoptheid):

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

We zien dat de DTU-standaarddatabase 24 logische CPU's (vCores) heeft, met 5,4 GB geheugen per vCore. De directe overeenkomst met die is een Algemeen gebruik 2 vCore-database op standaardreekshardware (Gen5), de GP_Gen5_24 vCore-servicedoelstelling.

Een Standard S0-database migreren

De toewijzingsquery retourneert het volgende resultaat (sommige kolommen worden niet weergegeven voor beknoptheid):

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

We zien dat de DTU-database het equivalent heeft van 0,25 logische CPU's (vCores), met 1,3 GB geheugen per vCore. De kleinste vCore-servicedoelstellingen in de hardwareconfiguratie van de Standard-serie (Gen5), GP_Gen5_2, biedt meer rekenresources dan de Standard S0-database, zodat een directe overeenkomst niet mogelijk is. De optie GP_Gen5_2 heeft de voorkeur. Als de workload bovendien geschikt is voor de serverloze rekenlaag, is GP_S_Gen5_1 een betere overeenkomst.

Een Premium P15-database migreren

De toewijzingsquery retourneert het volgende resultaat (sommige kolommen worden niet weergegeven voor beknoptheid):

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

We zien dat de DTU-database 42 logische CPU's (vCores) heeft, met 4,86 GB geheugen per vCore. Hoewel er geen vCore-servicedoelstelling is met 42 kernen, is de BC_Gen5_40 servicedoelstelling bijna gelijk in termen van CPU- en geheugencapaciteit en is het een goede overeenkomst.

Een elastische basic 200 eDTU-pool migreren

De toewijzingsquery retourneert het volgende resultaat (sommige kolommen worden niet weergegeven voor beknoptheid):

dtu_logical_cpus dtu_memory_per_core_gb standard_series_vcores standard_series_memory_per_core_gb
4,00 5,40 4,000 5,05

We zien dat de elastische DTU-pool 4 logische CPU's (vCores) heeft, met 5,4 GB geheugen per vCore. Hardwareoproepen van de Standard-serie voor 4 vCores, maar deze servicedoelstelling ondersteunt maximaal 200 databases per pool, terwijl de elastische Basic 200 eDTU-pool maximaal 500 databases ondersteunt. Als de elastische pool die moet worden gemigreerd meer dan 200 databases heeft, moet de overeenkomende vCore-servicedoelstelling worden GP_Gen5_6, die maximaal 500 databases ondersteunt.

Geo-gerepliceerde databases migreren

Migreren van het DTU-model naar het aankoopmodel op basis van vCore is vergelijkbaar met het upgraden of downgraden van de geo-replicatierelaties tussen databases in de Standard- en Premium-servicelagen. Tijdens de migratie hoeft u geo-replicatie niet te stoppen, maar moet u de volgende regels voor sequentiëren volgen:

  • Wanneer u een upgrade uitvoert, moet u eerst de secundaire database upgraden en vervolgens de primaire database bijwerken.
  • Wanneer u een downgrade uitvoert, moet u de volgorde omkeren: u moet eerst de primaire database downgraden en vervolgens de secundaire database downgraden.

Wanneer u geo-replicatie tussen twee elastische pools gebruikt, raden we u aan om één pool aan te wijzen als de primaire en de andere als secundaire pool. In dat geval moet u dezelfde richtlijnen voor sequentiëren gebruiken wanneer u elastische pools migreert. Als u echter elastische pools hebt die zowel primaire als secundaire databases bevatten, behandelt u de pool met het hogere gebruik als primaire en volgt u de regels voor sequentiëren dienovereenkomstig.

De volgende tabel bevat richtlijnen voor specifieke migratiescenario's:

Huidige servicelaag Doelservicelaag Migratietype Gebruikersacties
Standaard Algemeen gebruik Laterale Kan in elke gewenste volgorde migreren, maar moet ervoor zorgen dat de juiste vCore-grootte wordt bepaald zoals hierboven wordt beschreven
Premium Bedrijfskritiek Laterale Kan in elke gewenste volgorde migreren, maar moet ervoor zorgen dat de juiste vCore-grootte wordt bepaald zoals hierboven wordt beschreven
Standaard Bedrijfskritiek Upgraden Moet eerst secundaire migreren
Bedrijfskritiek Standaard Downgrade Moet eerst primaire migreren
Premium Algemeen gebruik Downgrade Moet eerst primaire migreren
Algemeen gebruik Premium Upgraden Moet eerst secundaire migreren
Bedrijfskritiek Algemeen gebruik Downgrade Moet eerst primaire migreren
Algemeen gebruik Bedrijfskritiek Upgraden Moet eerst secundaire migreren

Failovergroepen migreren

Migratie van failovergroepen met meerdere databases vereist afzonderlijke migratie van de primaire en secundaire databases. Tijdens dit proces zijn dezelfde overwegingen en sequentiërende regels van toepassing. Nadat de databases zijn geconverteerd naar het aankoopmodel op basis van vCore, blijft de failovergroep van kracht met dezelfde beleidsinstellingen.

Een secundaire database voor geo-replicatie maken

U kunt alleen een secundaire database voor geo-replicatie (een geo-secundaire) maken met dezelfde servicelaag als die u hebt gebruikt voor de primaire database. Voor databases met een hoge snelheid voor het genereren van logboeken raden we u aan om de geo-secundaire database te maken met dezelfde rekengrootte als de primaire.

Als u een geo-secundaire pool maakt in de elastische pool voor één primaire database, moet u ervoor zorgen dat de maxVCore instelling voor de pool overeenkomt met de rekenkracht van de primaire database. Als u een geo-secundaire voor een primaire pool in een andere elastische pool maakt, raden we aan dat de pools dezelfde maxVCore instellingen hebben.

Databasekopie gebruiken om van DTU naar vCore te migreren

U kunt elke database met een op DTU gebaseerde rekenkracht kopiëren naar een database met een vCore-rekenkracht zonder beperkingen of speciale sequencing, zolang de doelrekengrootte de maximale databasegrootte van de brondatabase ondersteunt. Databasekopie maakt een transactioneel consistente momentopname van de gegevens vanaf een bepaald tijdstip nadat de kopieerbewerking is gestart. Gegevens tussen de bron en het doel worden na dat tijdstip niet gesynchroniseerd.

Volgende stappen