Dela via

Översikt över DTU-baserad inköpsmodell

  • Artikel

gäller för:Azure SQL Database

Den här artikeln innehåller en översikt över den DTU-baserade inköpsmodellen för Azure SQL Database. Den DTU-baserade inköpsmodellen är ett enkelt, paketerat mått på beräknings-, lagrings- och I/O-resurser. Det passar bäst för de flesta kunder med typiska arbetsbelastningar. Den DTU-baserade inköpsmodellen är tillgänglig på tjänstnivåerna Basic, Standard och Premium. Den DTU-baserade inköpsmodellen är också tillgänglig för elastiska pooler.

Den DTU-baserade inköpsmodellen skiljer sig från den vCore-baserade inköpsmodellen, så du kan jämföra inköpsmodeller.

Databastransaktionsenheter (DTU:er)

En databastransaktionsenhet (DTU) representerar ett blandat 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 övergångsperiod där anslutningen till databasen går förlorad under en kort tid, vilket kan minimeras med hjälp av logik för omförsök. 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 inom 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) utformad för att vara typisk för verkliga OLTP-arbetsbelastningar. När din arbetsbelastning överskrider mängden av någon av dessa resurser, begränsas dataflödet, vilket leder till långsammare prestanda och avbrott.

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.

Diagram över köpmodellen för DTU. De fyra sidorna i rutan är Skrivningar, CPU, Läsningar och Minne, som beskriver hur DTU-arbetsbelastningar är en blandning av processor-, minnes- och lässkrivningshastigheter.

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. Till 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 främsta frågorna baserat på CPU/varaktighet/antal körningar som kan justeras för att förbättra prestandan. En I/O-intensiv fråga kan till exempel 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 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. För mer information, se elastiska pooler i Azure SQL Database

Fastställa antalet DTU som behövs för 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 lägre återgivning av 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_statsoch 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.

Anteckning

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.

Maskinvarukonfiguration

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- arbetsbelastning förblir väsentligt identisk 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-benchmark-går det därför att se prestandaskillnader om databasen flyttas från en typ av maskinvara till en annan.

Kunder kan använda vCore-modellen för att välja sin föredragna maskinvarukonfiguration när databasen skapas och skalas upp. 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 finns i Maskinvarukonfiguration.

Jämföra tjänstnivåer

Observera

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.

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

Grundläggande Standard Premie
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 lagringstid tillgänglig upp till 10 år		 Ett val av geo-redundant, zonredundant eller lokalt redundant säkerhetskopieringslagring, 1–35 dagars bibehållning (standard 7 dagar)
Långsiktig lagring 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åg Låg, medelhög, hög Medelhög, Hög
IOPS (ungefärlig)1 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)
Columnstore-indexering2 Ej tillämpligt Standard S3 och högre Stödd
Minnesintern OLTP Ej tillämpligt Ej tillämpligt Stödd

1 Alla läs- och skrivåtgärder mot datafiler, inklusive bakgrunds-I/O (kontrollpunkt och lat skrivare).

2 Mer information finns i Ändra tjänstnivåer för databaser som innehåller kolumnlagringsindex.

Viktig

Tjänstnivåerna Basic, S0, S1 och S2 ger färre än en virtuell kärna (CPU). För CPU-intensiva arbetsbelastningar rekommenderas ett tjänstmål på S3 eller högre.

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.

Tips

Om du vill se faktiska resursstyrning grä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.

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 Premie
Maximal lagringsstorlek 2 GB 1 TB 4 TB
högsta DTU:er 5 3000 4000

Viktig

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

Gränser för elastisk pool

Mer information finns i Resursgränser för elastiska pooler med hjälp av DTU-inköpsmodellen.

Grundläggande 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

Viktig

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 lagrings maxvärdet på Premium-nivån begränsat till 1 TB. För mer information, se P11-P15 aktuella begränsningar.

Viktig

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-benchmark-.

Jämföra DTU-baserade och vCore-köpmodeller

Ä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 virtuella kärnor för Azure SQL Database välja och skala beräknings- och lagringsresurser separat.

Med den vCore-baserade inköpsmodellen kan du också använda Azure Hybrid Benefit för SQL Server för att spara kostnader och erbjuder serverlös beräkningsnivå för Azure SQL Database och Tjänstnivå för Hyperskala alternativ för Azure SQL Database som inte är tillgängliga i den DTU-baserade inköpsmodellen.

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

Relaterat innehåll