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

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 een 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 behulp van dezelfde stappen, met uitzondering van databases die zijn gemigreerd naar de Hyperscale servicelaag.

U kunt uw database migreren naar een ander aankoopmodel met behulp van Azure Portal, PowerShell, De Azure CLI en Transact-SQL.

$parameters = @{
     ResourceGroupName = "<resource group name>"
     DatabaseName = "<database name>"
     ServerName = "<server name>"
     Edition = "<service tier, such as Hyperscale>"
     RequestedServiceObjectiveName = "<hardware such as HS_Gen5_2>"
}

Set-AzSqlDatabase @parameters

az sql db update --resource-group "<resource group name>" --server "<server name>" --name "<database name>" --edition <service tier, such as Hyperscale> --capacity 4 --family Gen5

ALTER DATABASE <database name> MODIFY (EDITION = '<service tier, such as Hyperscale>');

De vCore-servicelaag en servicedoelstelling kiezen

Voor de meeste DTU-naar-vCore-migratiescenario's zijn databases en elastische pools in de servicelagen Basic en Standard toegewezen aan de servicelaag Algemeen gebruik. Databases en elastische pools in de Premium-servicelaag komen overeen met de servicelaag Bedrijfskritiek. Afhankelijk van het toepassingsscenario en de vereisten, kan de Hyperscale-servicelaag 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.

In het DTU-model kan het systeem alle beschikbare hardwareconfiguratie selecteren voor uw database of elastische pool. 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 het 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

De volgende Transact-SQL query, 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 meest overeenkomt met hun DTU-database of elastische pool.

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 toewijzingsquery Transact-SQL stemt overeen met de DTU- en vCore-servicedoelstellingen qua CPU-capaciteit, waardoor de resultaten nauwkeuriger zijn voor CPU-afhankelijke werkbelastingen.

• Voor hetzelfde hardwaretype en hetzelfde aantal vCores zijn IOPS- en transactielogboekdoorvoerresourcelimieten voor vCore-databases vaak hoger dan voor DTU-databases. Voor IO-gebonden 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 de elastische pool die gemigreerd moet worden, 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 middelengebruik van de DTU-database dient overwogen te worden bij het kiezen van de vCore service-doelstelling. DTU-databases met consequent onderbenutte CPU-bronnen hebben mogelijk minder vCores nodig dan het aantal dat door de koppelingsquery wordt geretourneerd. DTU-databases waar consistent hoog CPU-gebruik leidt tot onvoldoende workloadprestaties, vereisen daarentegen mogelijk meer vCores dan wordt geretourneerd door de query.

• Als u databases migreert met onregelmatige of onvoorspelbare gebruikspatronen, kunt u het gebruik van serverloze rekenlaag voor Azure SQL Database rekenlaag overwegen. Het maximum aantal gelijktijdige werknemers in serverless is 75%% van de limiet in ingerichte computing 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 120 GB bij Gen5 wanneer 40 vCores zijn geconfigureerd in serverless, vergeleken met 204 GB voor een toegewezen rekenkracht van 40 vCores.

• 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 Resourcelimieten voor elastische pools met behulp van het DTU-aankoopmodel en vCore--modellen verschillen in het maximaal ondersteunde aantal databases per pool. Dit moet worden overwogen wanneer u elastische pools migreert met veel databases.

• Sommige hardwareconfiguraties zijn mogelijk niet beschikbaar in elke regio. Controleer de beschikbaarheid onder Hardwareconfiguratie voor SQL Database.

De richtlijnen voor het aanpassen van de grootte van DTU naar vCores in deze sectie 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 de flexibiliteit van het vCore-model gebruiken om het aantal vCores, hardwareconfiguratie en service- en rekenlagen aan te passen. Mogelijk moet u ook parameters voor databaseconfiguratie aanpassen, zoals maximale mate van parallelle uitvoeringen/of het compatibiliteitsniveau van de database wijzigen om recente verbeteringen in de database-engine mogelijk te maken.

Voorbeelden van DTU-naar-vCore-migratie

Een Standard S9-database migreren

De koppelingsquery retourneert het volgende resultaat (sommige kolommen worden niet weergegeven voor de leesbaarheid):

We zien dat de DTU-standaarddatabase 24 logische CPU's (vCores) heeft, met 5,4 GB geheugen per vCore. De directe tegenhanger daarvan is een General Purpose 2 vCore-database op standaard-serie (Gen5) hardware, de GP_Gen5_24 vCore-doelstelling voor de dienst.

Een Standard S0-database migreren

De mappingquery retourneert het volgende resultaat (sommige kolommen zijn weggelaten voor de duidelijkheid):

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 Series (Gen5), GP_Gen5_2, bieden meer rekenresources dan de Standard S0-database, zodat er geen directe overeenkomst mogelijk is. De GP_Gen5_2 optie heeft de voorkeur. Als de workload bovendien geschikt is voor de serverloze rekenlaag, is GP_S_Gen5_1 een betere keuze.

Een Premium P15-database migreren

De mappingquery retourneert het volgende resultaat (sommige kolommen worden niet weergegeven omwille van de bondigheid).

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 het 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 koppelingsquery retourneert het volgende resultaat (sommige kolommen worden niet weergegeven omwille van de beknoptheid):

We zien dat de elastische DTU-pool 4 logische CPU's (vCores) heeft, met 5,4 GB geheugen per vCore. Hardware van de Standard-serie vereist 4 vCores, maar deze service-doelstelling 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 voor de lagen Algemeen gebruik en Bedrijfskritieke service, 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.

Als u een database wilt converteren naar de Hyperscale-servicelaag, moet geo-replicatie tijdelijk worden verwijderd. Zie Een bestaande database converteren naar Hyperscalevoor meer informatie.

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. Wanneer u elastische pools migreert, moet u in dat geval dezelfde richtlijnen voor sequentiëren gebruiken. 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:

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-secondary voor een primaire 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

Databasekopie maakt een transactioneel consistente momentopname van de gegevens op een bepaald moment nadat de kopieerbewerking is gestart. Gegevens tussen de bron en het doel worden na dat tijdstip niet gesynchroniseerd.

U kunt elke database met een op DTU gebaseerde rekenkracht kopiëren naar een database met een rekenkracht op basis van vCore met behulp van PowerShell, de Azure CLI of Transact-SQL zonder beperkingen of speciale sequencing, zolang de doelrekengrootte de maximale databasegrootte van de brondatabase ondersteunt. Het kopiëren van een database naar een andere servicelaag wordt niet ondersteund in Azure Portal.

Verwante inhoud

• resourcelimieten voor individuele databases met behulp van het vCore-aankoopmodel
• Resourcelimieten voor elastische pools met behulp van het vCore-aankoopmodel