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 köpmodellen.
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 minimal stilleståndstid i slutet av migreringsprocessen. En databas som migreras till den vCore-baserade inköpsmodellen kan migreras tillbaka till den DTU-baserade inköpsmodellen när som helst på samma sätt, med undantag för databaser som migreras till tjänstnivån Hyperskala .
Välj tjänstnivå och tjänstmål för virtuell kärna
För de flesta scenarier för migrering av DTU till virtuella kärnor mappas databaser och elastiska pooler på tjänstnivåerna Basic och Standard till tjänstnivån 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 tjänstnivån Hyperskala 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 med virtuella kärnor kan du använda en enkel men ungefärlig tumregel: var 100 DTU:er på nivåerna Basic eller Standard kräver minst 1 virtuell kärna och var 125:e DTU:er på Premium-nivån kräver minst 1 virtuell kärna.
Dricks
Den här regeln är ungefärlig eftersom den inte tar hänsyn till den specifika typ av maskinvara som används för DTU-databasen eller den elastiska poolen.
I DTU-modellen kan systemet välja valfri tillgänglig 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-mappning
En T-SQL-fråga nedan, när den körs i kontexten för en DTU-databas som ska migreras, returnerar ett matchande (eventuellt bråktal) antal virtuella kärnor i varje maskinvarukonfiguration i modellen för virtuell kärna. Du kan avrunda det här numret till det närmaste antalet virtuella kärnor som är tillgängliga för databaser och elastiska pooler i varje maskinvarukonfiguration i modellen för virtuell kärna. Kunderna kan välja det tjänstmål för virtuell kärna som är den närmaste matchningen för 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 tjänstmål för virtuell kärna:
- Transact-SQL-frågan för mappning matchar DTU- och vCore-tjänstens mål när det gäller deras CPU-kapacitet. Därför blir resultatet mer exakt för CPU-bundna 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änstmålet för virtuell kärna. 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å. Observera att det maximala antalet samtidiga arbetare i serverlös är 75 % av gränsen i etablerad beräkning för samma antal maximala virtuella kärnor som konfigurerats. 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 kontrollerar du maximala storlekar som stöds i modellen med virtuella kärnor för enskilda databaser och elastiska pooler.
- För elastiska pooler har DTU - och vCore-modellerna skillnader i det maximala antalet databaser per pool som stöds. Detta bör beaktas vid migrering av 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.
Viktigt!
Riktlinjerna för storleksändring av DTU till virtuella kärnor ovan tillhandahålls för att hjälpa till vid den första uppskattningen av målet för databastjänsten.
Den optimala konfigurationen av måldatabasen är arbetsbelastningsberoende. För att uppnå det optimala förhållandet mellan pris och prestanda efter migreringen kan du därför behöva utnyttja flexibiliteten i modellen med virtuella kärnor 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 parallellitet, och/eller ändra databasens kompatibilitetsnivå för att möjliggöra de senaste förbättringarna i databasmotorn.
Migreringsexempel för DTU till virtuell kärna
Kommentar
Värdena i exemplen nedan är endast i illustrationssyfte. Faktiska värden som returneras i beskrivna scenarier kan skilja sig.
Migrera en Standard S9-databas
Mappningsfrågan returnerar följande resultat (vissa kolumner visas inte för korthet):
| 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 |
Vi ser att DTU-standarddatabasen har 24 logiska processorer (virtuella kärnor), med 5,4 GB minne per virtuell kärna. Direktmatchningen till det är en generell användning 2 vCore-databas på standardseriemaskinvara (Gen5), GP_Gen5_24 vCore-tjänstmål.
Migrera en Standard S0-databas
Mappningsfrågan returnerar följande resultat (vissa kolumner visas inte för korthet):
| 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 |
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):
| 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 |
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 det 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):
| 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 |
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 vCore-tjänstmålet 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, 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.
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:
| Aktuell tjänstnivå | Måltjänstnivå | Migreringstyp | Användaråtgärder |
|---|---|---|---|
| Standard | Generell användning | Laterala | Kan migrera i valfri ordning, men måste säkerställa lämplig storlek på virtuella kärnor enligt beskrivningen ovan |
| Premium | Affärskritisk | Laterala | Kan migrera i valfri ordning, men måste säkerställa lämplig storlek på virtuella kärnor enligt beskrivningen ovan |
| Standard | Affärskritisk | Uppgradera | Måste migrera sekundär först |
| Affärskritisk | Standard | Nedgradera | Måste migrera primär först |
| Premium | Generell användning | Nedgradera | Måste migrera primär först |
| Generell användning | Premium | Uppgradera | Måste migrera sekundär först |
| Affärskritisk | Generell användning | Nedgradera | Måste migrera primär först |
| Generell användning | Affärskritisk | Uppgradera | Måste migrera sekundär först |
Migrera redundansgrupper
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 maxVCore inställningen 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 virtuell kärna
Du kan kopiera valfri databas med en DTU-baserad beräkningsstorlek till en databas med en vCore-baserad beräkningsstorlek utan begränsningar eller särskild sekvensering så länge målberäkningsstorleken stöder den maximala databasstorleken för källdatabasen. Databaskopiering skapar en transaktionsmässigt konsekvent ögonblicksbild av data från och med en tidpunkt när kopieringsåtgärden startar. Den synkroniserar inte data mellan källan och målet efter den tidpunkten.
Nästa steg
- De specifika alternativen för beräkningsstorlekar och lagringsstorlekar som är tillgängliga för enskilda databaser finns i SQL Database vCore-baserade resursgränser för enskilda databaser.
- De specifika alternativen för beräkningsstorlekar och lagringsstorlekar som är tillgängliga för elastiska pooler finns i SQL Database vCore-baserade resursgränser för elastiska pooler.