Migrera Azure SQL Database från den DTU-baserade modellen till den vCore-baserade modellen

gäller för:Azure SQL Database

Den här artikeln beskriver hur du migrerar din databas i Azure SQL Database från den DTU-baserade inköpsmodellen till den vCore-baserade inköpsmodellen.

Migrera en databas

Att migrera en databas från den DTU-baserade inköpsmodellen till den vCore-baserade inköpsmodellen liknar skalning mellan tjänstmål på tjänstnivåerna Basic, Standard och Premium, med liknande varaktighet och en minimal stilleståndstid i slutet av migreringsprocessen. En databas som migreras till den vCore-baserade inköpsmodellen kan när som helst migreras tillbaka till den DTU-baserade inköpsmodellen med samma steg, förutom databaser som migreras till tjänstnivån Hyperskala.

Du kan migrera databasen till en annan inköpsmodell med hjälp av Azure-portalen, PowerShell, Azure CLI och 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>');

Välj tjänstnivå och tjänstmål för vCore

För de flesta scenarier för migrering från DTU till vCore mappar databaser och elastiska pooler på tjänstnivåerna Basic och Standard till Generell användning. Databaser och elastiska pooler på Premium-tjänstnivån mappas till tjänstnivån Affärskritisk. Beroende på programscenario och krav kan Hyperskala tjänstnivå ofta användas som migreringsmål för databaser och elastiska pooler på alla DTU-tjänstnivåer.

Om du vill välja tjänstmål eller beräkningsstorlek för den migrerade databasen i modellen för virtuell kärna kan du använda en grundläggande men ungefärlig tumregel: var 100 DTU:er på nivåerna Basic eller Standard kräver minst 1 virtuell kärna, och var 125 DTU:er på Premium-nivån kräver minst 1 virtuell kärna.

I DTU-modellen kan systemet välja alla tillgängliga maskinvarukonfiguration för din databas eller elastiska pool. I DTU-modellen har du dessutom bara indirekt kontroll över antalet virtuella kärnor (logiska processorer) genom att välja högre eller lägre DTU- eller eDTU-värden.

I modellen med virtuella kärnor måste kunderna göra ett explicit val av både maskinvarukonfigurationen och antalet virtuella kärnor (logiska processorer). DTU-modellen erbjuder inte dessa alternativ, men maskinvarutyp och antalet logiska processorer som används för varje databas och elastisk pool exponeras via dynamiska hanteringsvyer. Detta gör det möjligt att fastställa det matchande vCore-tjänstmålet mer exakt.

Följande metod använder den här informationen för att fastställa ett tjänstmål för virtuell kärna med en liknande resursallokering för att få en liknande prestandanivå efter migreringen som modellen med virtuella kärnor.

DTU till vCore-kartläggning

Följande Transact-SQL-fråga, när den körs i kontexten av en DTU-databas som ska migreras, returnerar ett matchande (eventuellt bråktal) antal virtuella kärnor i varje maskinvarukonfiguration i vCores-modellen. Du kan avrunda det här numret till det närmaste tillgängliga antalet virtuella kärnor för databaser och elastiska pooler i varje maskinvarukonfiguration. I modellen för virtuella kärnor kan kunderna välja det vCore-tjänstmål som bäst matchar deras DTU-databas eller elastiska pool.

Exempel på migreringsscenarier med den här metoden beskrivs i avsnittet Exempel.

Kör den här frågan i kontexten för databasen som ska migreras i stället för i master-databasen. När du migrerar en elastisk pool kör du frågan i kontexten för alla databaser i poolen.

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

Ytterligare faktorer

Förutom antalet virtuella kärnor (logiska processorer) och typen av maskinvara kan flera andra faktorer påverka valet av vCore-tjänstmål:

• Frågan om mappning Transact-SQL överensstämmer med DTU- och vCore-tjänstmål i fråga om CPU-kapacitet, och därför blir resultaten mer exakta för CPU-intensiva arbetsbelastningar.

• För samma maskinvarutyp och samma antal virtuella kärnor är resursgränserna för IOPS och transaktionsloggens dataflöde för virtuella kärnor ofta högre än för DTU-databaser. För I/O-bundna arbetsbelastningar kan det vara möjligt att sänka antalet virtuella kärnor i modellen för virtuell kärna för att uppnå samma prestandanivå. Faktiska resursgränser för DTU- och vCore-databaser exponeras i vyn sys.dm_user_db_resource_governance. Om du jämför dessa värden mellan DTU-databasen eller poolen som ska migreras, och en databas eller pool med virtuell kärna med ett ungefär matchande tjänstmål, kan du välja tjänstmålet för virtuell kärna mer exakt.

• Mappningsfrågan returnerar också mängden minne per kärna för DTU-databasen eller den elastiska poolen som ska migreras och för varje maskinvarukonfiguration i modellen med virtuella kärnor. Att säkerställa liknande eller högre totalt minne efter migreringen till virtuell kärna är viktigt för arbetsbelastningar som kräver en stor minnesdatacache för att uppnå tillräcklig prestanda eller arbetsbelastningar som kräver stora minnesbidrag för frågebearbetning. För sådana arbetsbelastningar kan det, beroende på faktiska prestanda, vara nödvändigt att öka antalet virtuella kärnor för att få tillräckligt med totalt minne.

• Den historiska resursanvändningen för DTU-databasen bör beaktas när du väljer tjänstemål för vCore. DTU-databaser med konsekvent underutnyttjade CPU-resurser kan behöva färre virtuella kärnor än antalet som returneras av mappningsfrågan. Omvänt kan DTU-databaser där konsekvent hög CPU-användning orsakar otillräcklig arbetsbelastningsprestanda kräva fler virtuella kärnor än vad som returneras av frågan.

• Om du migrerar databaser med tillfälliga eller oförutsägbara användningsmönster bör du överväga att använda serverlös beräkningsnivå för Azure SQL Database beräkningsnivå. Det maximala antalet samtidiga arbetare i serverlös är 75% av gränsen i etablerad beräkning för samma antal konfigurerade maximala virtuella kärnor. Dessutom är det maximala tillgängliga minnet i serverlöst 3 GB gånger det maximala antalet konfigurerade virtuella kärnor, vilket är mindre än minne per kärna för etablerad beräkning. På Gen5 är till exempel maximalt minne 120 GB när 40 maximala virtuella kärnor konfigureras i serverlöst, jämfört med 204 GB för en etablerad beräkning med 40 virtuella kärnor.

• I modellen med virtuella kärnor kan den maximala databasstorleken som stöds variera beroende på maskinvara. För stora databaser bör du kontrollera de maximala storlekar som stöds i modellen för virtuella kärnor, både för enskilda databaser och elastiska pooler.

• För elastiska pooler har Resursgränser för elastiska pooler med hjälp av DTU-inköpsmodellen och virtuella kärnor modeller skillnader i det maximala antalet databaser per pool som stöds. Detta bör beaktas när du migrerar elastiska pooler med många databaser.

• Vissa maskinvarukonfigurationer kanske inte är tillgängliga i alla regioner. Kontrollera tillgängligheten under Maskinvarukonfiguration för SQL Database.

Riktlinjerna för storleksändring av DTU till virtuella kärnor som anges i det här avsnittet hjälper till med den första uppskattningen av målet för databastjänsten.

Den optimala konfigurationen av måldatabasen är arbetsbelastningsberoende. För att uppnå optimalt pris/prestanda-förhållande efter migreringen kan du därför behöva använda flexibiliteten i modellen för virtuell kärna för att justera antalet virtuella kärnor, maskinvarukonfiguration och tjänst- och beräkningsnivåer. Du kan också behöva justera databaskonfigurationsparametrar, till exempel maximal grad av parallellitetoch/eller ändra databasen kompatibilitetsnivå för att möjliggöra de senaste förbättringarna i databasmotorn.

Exempel på migrering från DTU till vCore

Migrera en Standard S9-databas

Mappningsfrågan returnerar följande resultat (vissa kolumner visas inte för korthet):

Vi ser att DTU-standarddatabasen har 24 logiska processorer (virtuella kärnor), med 5,4 GB minne per virtuell kärna. Den direkta matchningen är en Allmän användning 2 vCore-databas på standardserie (Gen5) hårdvara, GP_Gen5_24 vCore-tjänstavsikt.

Migrera en Standard S0-databas

Mappningsfrågan returnerar följande resultat (vissa kolumner visas inte för korthet):

Vi ser att DTU-databasen har motsvarande 0,25 logiska processorer (virtuella kärnor), med 1,3 GB minne per virtuell kärna. De minsta vCore-tjänstmålen i standardseriens (Gen5) maskinvarukonfiguration, GP_Gen5_2, ger fler beräkningsresurser än Standard S0-databasen, så det går inte att matcha direkt. Alternativet GP_Gen5_2 är att föredra. Om arbetsbelastningen dessutom passar bra för den serverlösa beräkningsnivån skulle GP_S_Gen5_1 vara en närmare matchning.

Migrera en Premium P15-databas

Mappningsfrågan returnerar följande resultat (vissa kolumner visas inte för korthet):

Vi ser att DTU-databasen har 42 logiska processorer (virtuella kärnor), med 4,86 GB minne per virtuell kärna. Även om det inte finns något vCore-tjänstmål med 42 kärnor är BC_Gen5_40 servicemålet nästan likvärdigt när det gäller processor- och minneskapacitet och är en bra matchning.

Migrera en elastisk Basic 200 eDTU-pool

Mappningsfrågan returnerar följande resultat (vissa kolumner visas inte för korthet):

Vi ser att den elastiska DTU-poolen har 4 logiska processorer (virtuella kärnor), med 5,4 GB minne per virtuell kärna. Standard-seriens maskinvara kräver 4 virtuella kärnor, men det här tjänstmålet stöder högst 200 databaser per pool, medan den elastiska eDTU-poolen Basic 200 stöder upp till 500 databaser. Om den elastiska pool som ska migreras har fler än 200 databaser måste det matchande tjänstmålet för virtuell kärna vara GP_Gen5_6, som stöder upp till 500 databaser.

Migrera geo-replikerade databaser

Att migrera från den DTU-baserade modellen till den VCore-baserade köpmodellen liknar uppgradering eller nedgradering av geo-replikeringsrelationerna mellan databaser på standard- och Premium-tjänstnivåerna. Under migreringen behöver du inte stoppa geo-replikering för nivåerna Generell användning och Affärskritisk tjänst, men du måste följa dessa sekvenseringsregler:

• När du uppgraderar måste du först uppgradera den sekundära databasen och sedan uppgradera den primära databasen.
• När du nedgraderar ändrar du ordningen: du måste nedgradera den primära databasen först och sedan nedgradera den sekundära.

Om du vill konvertera en databas till tjänstnivån Hyperskala bör geo-replikering tillfälligt tas bort. Mer information finns i Konvertera en befintlig databas till Hyperskala.

När du använder geo-replikering mellan två elastiska pooler rekommenderar vi att du anger en pool som primär och den andra som sekundär. I så fall bör du använda samma sekvenseringsvägledning när du migrerar elastiska pooler. Men om du har elastiska pooler som innehåller både primära och sekundära databaser behandlar du poolen med den högre användningen som primär och följer sekvenseringsreglerna i enlighet med detta.

Följande tabell innehåller vägledning för specifika migreringsscenarier:

Migrera failover-grupper

Migrering av redundansgrupper med flera databaser kräver individuell migrering av de primära och sekundära databaserna. Under den processen gäller samma överväganden och sekvenseringsregler. När databaserna har konverterats till den vCore-baserade inköpsmodellen förblir redundansgruppen i kraft med samma principinställningar.

Skapa en sekundär databas för geo-replikering

Du kan bara skapa en sekundär geo-replikeringsdatabas (en geo-sekundär) med samma tjänstnivå som du använde för den primära databasen. För databaser med hög logggenereringshastighet rekommenderar vi att du skapar den geo-sekundära med samma beräkningsstorlek som den primära.

Om du skapar en geo-sekundär i den elastiska poolen för en enskild primär databas kontrollerar du att inställningen maxVCore för poolen matchar den primära databasens beräkningsstorlek. Om du skapar en geo-sekundär för en primär i en annan elastisk pool rekommenderar vi att poolerna har samma maxVCore inställningar.

Använda databaskopiering för att migrera från DTU till vCore

Databasens kopia skapar en transaktionsmässigt konsekvent ögonblicksbild av data vid en tidpunkt efter att kopieringsåtgärden har startat. Den synkroniserar inte data mellan källan och målet efter den tidpunkten.

Du kan kopiera valfri databas med en DTU-baserad beräkningsstorlek till en databas med en vCore-baserad beräkningsstorlek med hjälp av PowerShell, Azure CLI eller Transact-SQL utan begränsningar eller särskild sekvensering, så länge målberäkningsstorleken stöder den maximala databasstorleken för källdatabasen. Det går inte att kopiera en databas till en annan tjänstnivå i Azure-portalen.

Relaterat innehåll

• Resursgränser för enskilda databaser med köpmodellen för virtuella kärnor
• Resursgränser för elastiska pooler med köpmodellen för virtuella kärnor