Välj mellan köpmodellerna vCore och DTU – Azure SQL Database och SQL Managed Instance

  • Artikel
  • 11 minuter för att läsa

GÄLLER FÖR: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database och Azure SQL Managed Instance kan du enkelt köpa en helt hanterad PaaS-databasmotor (plattform som en tjänst) som passar dina prestanda- och kostnadsbehov. Beroende på vilken distributionsmodell du har valt för Azure SQL Database kan du välja den inköpsmodell som passar dig:

  • Köpmodell baserad på virtuell kärna (vCore) (rekommenderas). Den här köpmodellen ger ett val mellan en etablerad beräkningsnivå och en serverlös beräkningsnivå. Med den etablerade beräkningsnivån väljer du den exakta mängden beräkningsresurser som alltid är etablerade för din arbetsbelastning. Med den serverlösa beräkningsnivån anger du autoskalning av beräkningsresurserna över ett konfigurerbart beräkningsintervall. Med den här beräkningsnivån kan du också automatiskt pausa och återuppta databasen baserat på arbetsbelastningsaktivitet. Enhetspriset för virtuella kärnor per tid är lägre på den etablerade beräkningsnivån än på den serverlösa beräkningsnivån.
  • Köpmodell baserad på databastransaktionsenhet (DTU). Den här köpmodellen tillhandahåller paketerade beräknings- och lagringspaket som balanseras för vanliga arbetsbelastningar.

Undersökning för att förbättra Azure SQL!

Det finns två köpmodeller:

I följande tabell och diagram jämförs de vCore-baserade och DTU-baserade köpmodellerna:

Köpmodell Beskrivning Bäst för
DTU-baserad Den här modellen baseras på ett paketerat mått på beräknings-, lagrings- och I/O-resurser. Beräkningsstorlekarna anges i DTU:er för enstaka databaser och i elastiska databastransaktioner (eDTU:er) för elastiska pooler. Du kan läsa mer om DTU:er och eDTU:er i Vad är DTU:er och eDTU:er?. Kunder som vill ha enkla, förkonfigurerade resursalternativ
vCore-baserad Med den här modellen kan du välja beräknings- och lagringsresurser oberoende av varandra. Med den vCore-baserade inköpsmodellen kan du också spara in på kostnaderna med Azure Hybrid-förmånen för SQL Server. Kunder som värdesätter flexibilitet, kontroll och transparens

Jämförelse av prismodell

Vill du optimera och spara på dina molnutgifter?

Azure-tjänster kostar pengar. Azure Cost Management hjälper dig att ange budgetar och konfigurera aviseringar för att hålla koll på utgifterna. Analysera, hantera och optimera dina Azure-kostnader med Cost Management. Mer information finns i snabbstarten om att analysera kostnader.

Beräkningskostnader

Etablerade beräkningskostnader

På den etablerade beräkningsnivån återspeglar beräkningskostnaden den totala beräkningskapaciteten som har etablerats för programmet.

På Affärskritisk-tjänstnivån allokerar vi automatiskt minst tre repliker. För att återspegla denna ytterligare allokering av beräkningsresurser är priset i köpmodellen baserad på vCore cirka 2,7 gånger högre på Affärskritisk-tjänstnivån än på Generell användning-tjänstnivån. På samma sätt återspeglar det högre lagringspriset per GB Affärskritisk på tjänstnivån de högre I/O-gränserna och den lägre svarstiden för SSD-lagringen.

Kostnaden för lagring av säkerhetskopior är densamma för Affärskritisk och tjänstnivån Generell användning eftersom båda nivåerna använder standardlagring för säkerhetskopieringar.

Kostnader för serverlös beräkning

En beskrivning av hur beräkningskapacitet definieras och kostnader beräknas för den serverlösa beräkningsnivån finns i SQL Database serverlös nivå.

Lagringskostnader

Olika typer av lagring debiteras på olika sätt. För datalagring debiteras du för det etablerade lagringsutrymmet baserat på den maximala databas- eller poolstorlek som du väljer. Kostnaden ändras inte om du inte minskar eller ökar den högsta kostnaden. Lagring av säkerhetskopior associeras med automatiska säkerhetskopieringar av din instans och allokeras dynamiskt. Om du ökar kvarhållningsperioden för säkerhetskopior ökar lagringen för säkerhetskopior som används av din instans.

Som standard kopieras sju dagars automatiserade säkerhetskopior av dina databaser till ett read-access geo-redundant storage-standard-bloblagringskonto (RA-GRS). Den här lagringen används av veckovisa fullständiga säkerhetskopior, dagliga differentiella säkerhetskopior och säkerhetskopieringar av transaktionsloggar som kopieras var femte minut. Storleken på transaktionsloggarna beror på ändringsfrekvensen för databasen. En minsta lagringssumma som är lika med 100 procent av databasstorleken tillhandahålls utan extra kostnad. Ytterligare förbrukning av lagringsutrymme för säkerhetskopior debiteras i GB per månad.

Mer information om lagringspriser finns på prissättningssidan.

Köpmodell baserad på virtuell kärna

En virtuell kärna (vCore) representerar en logisk processor och ger dig möjlighet att välja mellan generationer av maskinvara och maskinvarans fysiska egenskaper (till exempel antalet kärnor, minnet och lagringsstorleken). Köpmodellen baserad på virtuella kärnor ger dig flexibilitet, kontroll, transparens för enskild resursförbrukning och ett enkelt sätt att översätta lokala arbetsbelastningskrav till molnet. Med den här modellen kan du välja beräknings-, minnes- och lagringsresurser baserat på dina arbetsbelastningsbehov.

I köpmodellen baserad på virtuella kärnor kan du välja mellan tjänstnivåer Generell användning och Affärskritisk för SQL Database och SQL Managed Instance. För enkla databaser kan du också välja tjänstnivån Hyperskala.

Med köpmodellen baserad på virtuella kärnor kan du välja beräknings- och lagringsresurser oberoende av varandra, matcha lokala prestanda och optimera priset. I köpmodellen baserad på virtuella kärnor betalar du för:

  • Beräkningsresurser (tjänstnivå + antal virtuella kärnor samt mängden minne + maskinvarans generation).
  • Typ av och mängd vid data- och logglagring.
  • Lagring av säkerhetskopior (RA-GRS).

Viktigt

Beräkningsresurser, I/O samt data- och logglagring debiteras per databas eller elastisk pool. Lagring av säkerhetskopior debiteras per databas. Mer information om hur SQL för hanterad instans finns i SQL Managed Instance. Regionbegränsningar: Den aktuella listan över regioner som stöds finns i produkt tillgänglig per region. Om du vill skapa en hanterad instans i en region som för närvarande inte stöds skickar du en supportbegäran via Azure Portal.

Om databasen förbrukar mer än 300 DPU:er kan du minska kostnaderna genom att konvertera till köpmodellen baserad på virtuella kärnor. Du kan konvertera med val av API eller med hjälp av Azure Portal, utan avbrottstid. Konvertering krävs dock inte och görs inte automatiskt. Om köpmodellen baserad på DTU uppfyller dina prestanda- och affärskrav bör du fortsätta att använda den.

Om du vill konvertera från köpmodellen baserad på DTU till köpmodellen baserad på virtuella kärnor kan du se Migrera från DTU till vCore.

Köpmodell baserad på DTU

En databastransaktionsenhet (DTU) representerar ett sammantaget mått på CPU, minne, läsningar och skrivningar. Köpmodellen baserad på DTU erbjuder en uppsättning förkonfigurerade paket med beräkningsresurser och inkluderad lagring för att driva olika nivåer av programprestanda. Om du föredrar enkelheten i ett förkonfigurerat paket och fasta betalningar varje månad kan den DTU-baserade modellen vara mer lämplig för dina behov.

I köpmodellen baserad på DTU kan du välja mellan tjänstnivån Basic, Standard och Premium för Azure SQL Database. Köpmodellen baserad på DTU är inte tillgänglig för Azure SQL Managed Instance.

Databastransaktionsenheter (DPU:er)

För en enskild databas med en viss beräkningsstorlek inom en tjänstnivå garanterarAzure en viss resursnivå för databasen (oberoende av andra databaser i Azure-molnet). Den här garanti ger en förutsägbar prestandanivå. Mängden resurser som allokeras för en databas beräknas som ett antal DPU:er och är ett paketerat mått på beräknings-, lagrings- och I/O-resurser.

Förhållandet mellan dessa resurser bestäms ursprungligen av en benchmark-arbetsbelastning för onlinetransaktion (OLTP) som utformats för att vara typisk för verkliga OLTP-arbetsbelastningar. När din arbetsbelastning överskrider mängden av dessa resurser begränsas dataflödet, vilket resulterar i långsammare prestanda och time out.

De resurser som används av din arbetsbelastning påverkar inte de resurser som är tillgängliga för andra databaser i Azure-molnet. På samma sätt påverkar inte de resurser som används av andra arbetsbelastningar de resurser som är tillgängliga för din databas.

Markeringsramen

DPU:er är mest användbara för att förstå de relativa resurser som allokeras för databaser med olika beräkningsstorlekar och tjänstnivåer. Till exempel:

  • En fördubbling av DDU:erna genom att öka beräkningsstorleken för en databas motsvarar en fördubbling av uppsättningen resurser som är tillgängliga för databasen.
  • En P11-databas på Premium-tjänstnivå med 1 750 DTU:er ger 350 gånger mer DTU-beräkningskraft än en databas på basic-tjänstnivå med 5 DTU:er.

Om du vill få djupare insikter om arbetsbelastningens resursförbrukning (DTU) kan du använda query-performance insights för att:

  • Identifiera de viktigaste frågorna efter CPU/varaktighet/antal körningar som potentiellt kan justeras för bättre prestanda. Till exempel kan en I/O-intensiv fråga dra nytta av minnesinterna optimeringstekniker för att bättre utnyttja det tillgängliga minnet på en viss tjänstnivå och beräkningsstorlek.
  • Öka detaljgranska informationen om en fråga för att visa dess text och dess historik för resursanvändning.
  • Få åtkomst till rekommendationer för prestandajustering som visar åtgärder som vidtas av SQL Database Advisor.

Elastiska databastransaktionsenheter (eDPU:er)

För databaser som alltid är tillgängliga, i stället för att tillhandahålla en dedikerad uppsättning resurser (DPU:er) som kanske inte alltid behövs, kan du placera dessa databaser i en elastisk pool. Databaserna i en elastisk pool finns på en enda server och delar en pool med resurser.

De delade resurserna i en elastisk pool mäts av elastiska databastransaktionsenheter (eDPU:er). Elastiska pooler ger en enkel, kostnadseffektiv lösning för att hantera prestandamål för flera databaser som har mycket varierande och oförutsägbara användningsmönster. En elastisk pool garanterar att alla resurser inte kan användas av en databas i poolen, samtidigt som varje databas i poolen alltid har en minsta tillgängliga mängd nödvändiga resurser.

En pool får ett fast antal eDPU:er för ett fast pris. I den elastiska poolen kan enskilda databaser skalas automatiskt inom de konfigurerade gränserna. En databas under en tyngre belastning förbrukar fler eDPU:er för att möta efterfrågan. Databaser med lättare belastning förbrukar färre eDPU:er. Databaser utan belastning förbrukar inga eDPU:er. Eftersom resurser etableras för hela poolen i stället för per databas, förenklar elastiska pooler dina hanteringsuppgifter och ger en förutsägbar budget för poolen.

Du kan lägga till ytterligare eDPU:er till en befintlig pool utan avbrott i databasen och utan att databaserna i poolen påverkas. Om du inte längre behöver extra eDPU:er kan du när som helst ta bort dem från en befintlig pool. Du kan också lägga till databaser till eller subtrahera databaser från en pool när som helst. Om du vill reservera eDPU:er för andra databaser begränsar du antalet eDPU:er som en databas kan använda vid hög belastning. Om en databas konsekvent underanvänder resurser flyttar du den från poolen och konfigurerar den som en enkel databas med en förutsägbar mängd nödvändiga resurser.

Fastställa antalet DTO:er som behövs av en arbetsbelastning

Om du vill migrera en befintlig lokal eller virtuell SQL Server-arbetsbelastning till SQL Database använder du DTU-kalkylatorn för att göra en ungefärlig uppskattning av antalet DTU:er som behövs. För en SQL Database arbetsbelastning kan du använda insikter om frågeprestanda för att förstå din databas-resursförbrukning (DPU:er) och få djupare insikter för att optimera din arbetsbelastning. Med sys.dm_db_resource_stats dynamisk hanteringsvy (DMV) kan du visa resursförbrukning för den senaste timmen. I sys.resource_stats katalogvy visas resursförbrukning för de senaste 14 dagarna, men med en lägre återgivning på femminutersgenomsnitt.

Fastställa DTU-användning

Om du vill fastställa den genomsnittliga procentandelen av DTU/eDTU-användningen i förhållande till DTU/eDTU-gränsen för en databas eller en elastisk pool använder du följande formel:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

Indatavärdena för den här formeln kan hämtas från sys.dm_db_resource_stats, sys.resource_statsoch sys.elastic_pool_resource_stats DMV:er. Om du vill fastställa procentandelen av DTU/eDTU-användningen mot DTU/eDTU-gränsen för en databas eller en elastisk pool väljer du med andra ord det största procentvärdet från följande: , och vid en viss avg_cpu_percent avg_data_io_percent avg_log_write_percent tidpunkt.

Anteckning

DTU-gränsen för en databas bestäms av cpu, läsningar, skrivningar och tillgängligt minne för databasen. Men eftersom SQL Database-motorn vanligtvis använder allt tillgängligt minne för sin datacache för att förbättra prestandan, kommer värdet vanligtvis att vara nära avg_memory_usage_percent 100 procent, oavsett aktuell databasbelastning. Även om minnet indirekt påverkar DTU-gränsen används det därför inte i formeln för DTU-användning.

Arbetsbelastningar som drar nytta av en elastisk pool med resurser

Pooler passar bra för databaser med ett lågt resursutnyttjandegenomsnitt och relativt ovanliga användningstoppar. Mer information finns i När bör du överväga en elastisk SQL Database pool?.

Maskinvarugenerationer i köpmodellen baserad på DTU

I köpmodellen baserad på DTU kan kunderna inte välja vilken maskinvarugeneration som ska användas för databaserna. Även om en viss databas vanligtvis finns kvar på en specifik maskinvarugeneration under en längre tid (vanligtvis i flera månader), finns det vissa händelser som kan göra att en databas flyttas till en annan maskinvarugeneration.

En databas kan till exempel flyttas till en annan maskinvarugeneration om den skalas upp eller ned till ett annat tjänstmål, eller om den aktuella infrastrukturen i ett datacenter närmar sig sina kapacitetsgränser, eller om den maskinvara som används för närvarande inaktiveras på grund av dess livslängd.

Om en databas flyttas till annan maskinvara kan arbetsbelastningens prestanda ändras. DTU-modellen garanterar att dataflödet och svarstiden för DTU-benchmark-arbetsbelastningen förblir avsevärt identiska när databasen flyttas till en annan maskinvarugeneration, så länge dess tjänstmål (antalet DTU:er) förblir detsamma.

Men i det breda spektrumet av kundarbetsbelastningar som körs i Azure SQL Database kan effekten av att använda olika maskinvara för samma tjänstmål vara mer uttalad. Olika arbetsbelastningar kan dra nytta av olika maskinvarukonfigurationer och funktioner. För andra arbetsbelastningar än DTU-benchmark är det därför möjligt att se prestandaskillnader om databasen flyttas från en maskinvarugeneration till en annan.

Ett program som är känsligt för nätverksfördröjning kan till exempel få bättre prestanda på Gen5-maskinvara jämfört med Gen4 på grund av användningen av accelererat nätverk i Gen5, men ett program som använder intensiv läs-I/O kan se bättre prestanda på Gen4-maskinvara jämfört med Gen5 på grund av ett högre förhållande minne per kärna på Gen4.

Kunder med arbetsbelastningar som är känsliga för maskinvaruändringar eller kunder som vill styra valet av maskinvarugenerering för sin databas kan använda modellen med virtuella kärnor för att välja maskinvarugenerering när databasen skapas och skalas. I modellen med virtuella kärnor dokumenteras resursbegränsningar för varje tjänstmål för varje maskinvarugeneration för både enskilda databaser och elastiska pooler. Mer information om maskinvarugenerationer i vCore-modellen finns i Maskinvarugenerationer för SQL Database eller Maskinvarugenerationer för SQL Managed Instance.

Vanliga frågor och svar

Måste jag ta mitt program offline för att konvertera från en DTU-baserad tjänstnivå till en vCore-baserad tjänstnivå?

Nej. Du behöver inte ta programmet offline. De nya tjänstnivåer erbjuder en enkel metod för onlinekonvertering som liknar den befintliga processen att uppgradera databaser från standard till premiumtjänstnivån och tvärtom. Du kan starta konverteringen med hjälp av Azure Portal, PowerShell, Azure CLI, T-SQL eller REST API. Se Hantera enskilda databaser och Hantera elastiska pooler.

Kan jag konvertera en databas från en tjänstnivå i köpmodellen baserad på vCore till en tjänstnivå i köpmodellen baserad på DTU?

Ja, du kan enkelt konvertera databasen till alla prestandamål som stöds med hjälp av Azure Portal, PowerShell, Azure CLI, T-SQL eller REST API. Se Hantera enskilda databaser och Hantera elastiska pooler.

Nästa steg