Översikt över DTU-baserad inköpsmodell

Gäller för:Azure SQL Database

I den här artikeln får du lära dig mer om den DTU-baserade inköpsmodellen för Azure SQL Database.

Mer information finns i köpmodellen baserad på virtuell kärna och jämför köpmodeller.

Databastransaktionsenheter (DTU:er)

En databastransaktionsenhet (DTU) representerar ett sammantaget mått på CPU, minne, läsningar och skrivningar. Tjänstnivåer i den DTU-baserade inköpsmodellen särskiljs av ett antal beräkningsstorlekar med en fast mängd lagringsutrymme, fast kvarhållningsperiod för säkerhetskopior och fast pris. Alla tjänstnivåer i den DTU-baserade inköpsmodellen ger flexibilitet att ändra beräkningsstorlekar med minimal stilleståndstid. Det finns dock en växel över en period där anslutningen går förlorad till databasen under en kort tid, vilket kan minimeras med hjälp av omförsökslogik. Enskilda databaser och elastiska pooler faktureras varje timme baserat på tjänstnivå och beräkningsstorlek.

För en enskild databas med en specifik beräkningsstorlek på en tjänstnivå garanterar Azure SQL Database en viss resursnivå för databasen (oberoende av andra databaser). Den här garantin ger en förutsägbar prestandanivå. Mängden resurser som allokeras för en databas beräknas som ett antal DTU: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 arbetsbelastning för onlinetransaktionsbearbetning (OLTP) som är utformad 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 tidsgränser.

För enskilda databaser påverkar inte de resurser som används av din arbetsbelastning 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 databasen.

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

• En fördubbling av DTU:erna genom att öka beräkningsstorleken för en databas motsvarar en fördubbling av den uppsättning 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 grundläggande tjänstnivådatabas med 5 DTU:er.

Om du vill få djupare insikt i förbrukningen av resurser (DTU) för din arbetsbelastning använder du insikter om frågeprestanda för att:

• Identifiera de vanligaste frågorna efter antal processorer/varaktighet/körning som potentiellt kan justeras för bättre prestanda. Till exempel kan en I/O-intensiv fråga dra nytta av minnesintern optimeringstekniker för att bättre använda det tillgängliga minnet på en viss tjänstnivå och beräkningsstorlek.
• Öka detaljnivån för en fråga för att visa dess text och dess historik över resursanvändning.
• Visa rekommendationer för prestandajustering som visar åtgärder som vidtagits av SQL Database Advisor.

Elastiska databastransaktionsenheter (eDTU:er)

I stället för att tillhandahålla en dedikerad uppsättning resurser (DTU:er) som kanske inte alltid behövs kan du placera dessa databaser i en elastisk pool. Databaserna i en elastisk pool använder en enda instans av databasmotorn och delar samma resurspool.

De delade resurserna i en elastisk pool mäts av elastiska databastransaktionsenheter (eDTU: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 förbrukas av en databas i poolen, samtidigt som varje databas i poolen alltid har en minsta mängd tillgängliga resurser.

En pool får ett visst antal eDTU:er för ett angivet pris. I den elastiska poolen kan enskilda databaser skala automatiskt inom de konfigurerade gränserna. En databas under en tyngre belastning förbrukar fler eDTU:er för att möta efterfrågan. Databaser under lättare belastning förbrukar färre eDTU:er. Databaser utan belastning förbrukar inga eDTU: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 fler eDTU:er i en befintlig pool med minimal databasavbrott. På samma sätt tar du bort dem från en befintlig pool när som helst om du inte längre behöver extra eDTU:er. Du kan också lägga till databaser i eller ta bort databaser från en pool när som helst. Om du vill reservera eDTU:er för andra databaser begränsar du antalet eDTU:er som kan användas under hög belastning. Om en databas har konsekvent hög resursanvändning som påverkar andra databaser i poolen flyttar du den från poolen och konfigurerar den som en enkel databas med en förutsägbar mängd nödvändiga resurser.

Arbetsbelastningar som drar nytta av en elastisk pool med resurser

Pooler är väl lämpade 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?.

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

Om du vill migrera en befintlig lokal arbetsbelastning eller en virtuell SQL Server-dator till SQL Database kan du läsa SKU-rekommendationer för att beräkna det antal DTU:er som behövs. För en befintlig SQL Database-arbetsbelastning använder du insikter om frågeprestanda för att förstå din databas-resursförbrukning (DTU: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. Vyn sys.resource_stats katalog visar resursförbrukning för de senaste 14 dagarna, men med en lägre återgivning på femminutersgenomsnitt.

Fastställa DTU-användning

Använd följande formel för att fastställa den genomsnittliga procentandelen DTU/eDTU-användning i förhållande till DTU/eDTU-gränsen för en databas eller en elastisk pool:

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_stats och sys.elastic_pool_resource_stats DMV:er. För att fastställa procentandelen DTU/eDTU-användning 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: avg_cpu_percent, avg_data_io_percentoch avg_log_write_percent vid en viss tidpunkt.

Kommentar

DTU-gränsen för en databas bestäms av cpu, läsningar, skrivningar och minne som är tillgängligt 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 är avg_memory_usage_percent värdet vanligtvis nära 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.

Konfiguration av maskinvara

I den DTU-baserade inköpsmodellen kan kunderna inte välja den maskinvarukonfiguration som används för deras databaser. Även om en viss databas vanligtvis finns kvar på en viss typ av maskinvara under en lång tid (vanligtvis i flera månader), finns det vissa händelser som kan leda till att en databas flyttas till en annan maskinvara.

En databas kan till exempel flyttas till en annan maskinvara 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 en annan maskinvara kan arbetsbelastningens prestanda ändras. DTU-modellen garanterar att dataflödet och svarstiden för DTU-benchmark-arbetsbelastningen förblir väsentligt identiska när databasen flyttas till en annan maskinvarutyp, så länge dess tjänstmål (antalet DTU:er) förblir detsamma.

Men över hela 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-riktmärket är det därför möjligt att se prestandaskillnader om databasen flyttas från en typ av maskinvara till en annan.

Kunder kan använda modellen med virtuella kärnor för att välja önskad maskinvarukonfiguration när databasen skapas och skalas. I modellen med virtuella kärnor dokumenteras detaljerade resursgränser för varje tjänstmål i varje maskinvarukonfiguration för enskilda databaser och elastiska pooler. Mer information om maskinvara i modellen med virtuella kärnor finns i Maskinvarukonfiguration för SQL Database eller Maskinvarukonfiguration för SQL Managed Instance.

Jämföra tjänstnivåer

Att välja en tjänstnivå beror främst på krav på affärskontinuitet, lagring och prestanda.

	Grundläggande	Standard	Premium
Målarbetsbelastning	Utveckling och produktion	Utveckling och produktion	Utveckling och produktion
Serviceavtal för drifttid	99,99 %	99,99 %	99,99 %
Säkerhetskopiering	Ett val av geo-redundant, zonredundant eller lokalt redundant säkerhetskopieringslagring, 1–7 dagars kvarhållning (standard 7 dagar) Långsiktig kvarhållning tillgänglig upp till 10 år	Ett val av geo-redundant, zonredundant eller lokalt redundant lagring av säkerhetskopiering, 1–35 dagars kvarhållning (standard 7 dagar) Långsiktig kvarhållning tillgänglig upp till 10 år	Ett val av lokalt redundant lagring (LRS), zonredundant (ZRS) eller geo-redundant lagring (GRS) Kvarhållning på 1–35 dagar (7 dagar som standard) med upp till 10 års långsiktig kvarhållning tillgänglig
CPU	Lägst	Låg, medelhög, hög	Medel, Hög
IOPS (ungefärlig)*	1–4 IOPS per DTU	1–4 IOPS per DTU	>25 IOPS per DTU
I/O-svarstid (ungefärlig)	5 ms (läs), 10 ms (skriv)	5 ms (läs), 10 ms (skriv)	2 ms (läs/skriv)
Kolumnlagringsindexering	Inte tillgänglig	Standard S3 och högre	Stöds
Minnesintern OLTP	Inte tillgänglig	Inte tillgänglig	Stöds

* Alla läsa och skriva IOPS mot datafiler, inklusive bakgrundS-I/O (kontrollpunkt och lat skrivare).

Viktigt!

Tjänstmålen Basic, S0, S1 och S2 ger mindre än en virtuell kärna (CPU). För CPU-intensiva arbetsbelastningar rekommenderas ett tjänstmål med S3 eller senare.

I tjänstmålen Basic, S0 och S1 lagras databasfiler i Azure Standard Storage, som använder hårddiskbaserade lagringsmedier (HDD). De här tjänstmålen passar bäst för utveckling, testning och andra arbetsbelastningar som används sällan och som är mindre känsliga för prestandavariationer.

Dricks

Om du vill se faktiska resursstyrningsgränser för en databas eller elastisk pool frågar du sys.dm_user_db_resource_governance vyn. För en enskild databas returneras en rad. För en databas i en elastisk pool returneras en rad för varje databas i poolen.

Kommentar

Du kan hämta en kostnadsfri databas i Azure SQL Database på basic-tjänstnivån med ett kostnadsfritt Azure-konto. Mer information finns i Skapa en hanterad molndatabas med ditt kostnadsfria Azure-konto.

Resursbegränsningar

Resursgränserna skiljer sig åt för enskilda databaser och pooldatabaser.

Lagringsgränser för enskild databas

I Azure SQL Database uttrycks beräkningsstorlekar i termer av databastransaktionsenheter (DTU:er) för enskilda databaser och elastiska databastransaktionsenheter (eDTU:er) för elastiska pooler. Mer information finns i Resursgränser för enskilda databaser.

	Grundläggande	Standard	Premium
Maximal lagringsstorlek	2 GB	1 TB	4 TB
Maximalt antal DTU:er	5	3000	4000

Viktigt!

Under vissa omständigheter kan du behöva krympa en databas för att frigöra outnyttjat utrymme. Mer information finns i Hantera filutrymme i Azure SQL Database.

Gränser för elastisk pool

Mer information finns i Resursgränser för pooldatabaser.

	Basic	Standard	Premium
Maximal lagringsstorlek per databas	2 GB	1 TB	1 TB
Maximal lagringsstorlek per pool	156 GB	4 TB	4 TB
Maximalt antal eDTU:er per databas	5	3000	4000
Maximalt antal eDTU:er per pool	1600	3000	4000
Maximalt antal databaser per pool	500	500	100

Viktigt!

Mer än 1 TB lagringsutrymme på Premium-nivån är för närvarande tillgängligt i alla regioner utom: Kina, östra, Kina, norra, Tyskland, centrala och Tyskland, nordöstra. I dessa regioner är det maximala lagringsutrymmet på Premium-nivån begränsat till 1 TB. Mer information finns i Aktuella begränsningar för P11–P15.

Viktigt!

Under vissa omständigheter kan du behöva krympa en databas för att frigöra outnyttjat utrymme. Mer information finns i Hantera filutrymme i Azure SQL Database.

DTU-benchmark

Fysiska egenskaper (CPU, minne, I/O) som är associerade med varje DTU-mått kalibreras med hjälp av ett riktmärke som simulerar en verklig databasarbetsbelastning.

Lär dig mer om schemat, transaktionstyper som används, arbetsbelastningsmix, användare och pacing, skalningsregler och mått som är associerade med DTU-riktmärket.

Jämföra köpmodeller baserade på DTU och virtuella kärnor

Även om den DTU-baserade inköpsmodellen baseras på ett paketerat mått på beräknings-, lagrings- och I/O-resurser kan du i jämförelse med köpmodellen för virtuella kärnor för Azure SQL Database välja och skala beräknings- och lagringsresurser separat.

Med den vCore-baserade köpmodellen kan du också använda Azure Hybrid-förmånen för SQL Server för att spara kostnader och erbjuder serverlösa och Hyperskala-alternativ för Azure SQL Database som inte är tillgängliga i den DTU-baserade köpmodellen.

Läs mer i Jämför virtuella kärnor och DTU-baserade köpmodeller för Azure SQL Database.

Nästa steg

Läs mer om köpmodeller och relaterade begrepp i följande artiklar:

• Mer information om specifika beräkningsstorlekar och lagringsstorleksalternativ som är tillgängliga för enskilda databaser finns i SQL Database DTU-baserade resursgränser för enskilda databaser.
• Mer information om specifika alternativ för beräkningsstorlekar och lagringsstorlekar som är tillgängliga för elastiska pooler finns i SQL Database DTU-baserade resursgränser.
• Information om det riktmärke som är kopplat till den DTU-baserade inköpsmodellen finns i DTU-benchmark.
• Jämför virtuella kärnor och DTU-baserade köpmodeller för Azure SQL Database.