Köpmodell för vCore – Azure SQL Database

Artikel
03/22/2025

Den här artikeln granskar köpmodellen för virtuella kärnor för Azure SQL Database.

Överblick

En virtuell kärna (virtuell kärna) representerar en logisk processor och ger dig möjlighet att välja maskinvarans fysiska egenskaper (till exempel antalet kärnor, minnet och lagringsstorleken). Den vCore-baserade inköpsmodellen ger dig flexibilitet, kontroll, transparens för individuell resursförbrukning och ett enkelt sätt att översätta lokala arbetsbelastningskrav till molnet. Den här modellen optimerar priset och låter dig välja beräknings-, minnes- och lagringsresurser baserat på dina arbetsbelastningsbehov.

I den vCore-baserade inköpsmodellen beror dina kostnader på valet och användningen av:

Tjänstnivå
Maskinvarukonfiguration
Beräkningsresurser (antalet virtuella kärnor och mängden minne)
Reserverad databaslagring
Faktisk lagring av säkerhetskopior

Viktig

Beräkningsresurser, I/O och data och logglagring debiteras per databas eller elastisk pool. Lagring av säkerhetskopior debiteras per databas. Prisinformation finns på prissidan Azure SQL Database.

Jämförelse av vCore- och DTU-köpmodeller

Köpmodellen för virtuell kärna som används av Azure SQL Database ger flera fördelar jämfört med den DTU-baserade inköpsmodellen:

Högre beräknings-, minnes-, I/O- och lagringsgränser.
Val av maskinvarukonfiguration för att bättre matcha beräknings- och minneskraven för arbetsbelastningen.
Prisrabatter för Azure Hybrid-förmån (AHB).
Större transparens i maskinvaruinformationen som driver beräkningen, vilket underlättar planeringen för migreringar från lokala distributioner.
Prissättning för reserverade instanser är endast tillgängligt för köpmodell för vCores.
Högre skalningskornighet med flera tillgängliga beräkningsstorlekar.

För att få hjälp med att välja mellan vCore- och DTU-köpmodellerna, se skillnaderna mellan vCore- och DTU-baserade inköpsmodeller.

Beräkna

Den vCore-baserade inköpsmodellen har en etablerad beräkningsnivå och en serverlös beräkningsnivå. På den etablerade beräkningsnivån återspeglar beräkningskostnaden den totala beräkningskapacitet som kontinuerligt etablerats för programmet oberoende av arbetsbelastningsaktivitet. Välj den resursallokering som bäst passar dina affärsbehov baserat på krav på virtuell kärna och minne och skala sedan upp och ned resurser efter behov av din arbetsbelastning. På den serverlösa beräkningsnivån för Azure SQL Database skalas beräkningsresurser automatiskt baserat på arbetsbelastningskapacitet och debiteras för den mängd beräkning som används per sekund.

Sammanfatta:

Även om den etablerade beräkningsnivån tillhandahåller en viss mängd beräkningsresurser som kontinuerligt etableras oberoende av arbetsbelastningsaktivitet, anpassar den serverlösa beräkningsnivån beräkningsresurserna automatiskt baserat på arbetsbelastningsaktivitet.
Medan den tilldelade beräkningsnivån debiterar för den mängd beräkning som har tilldelats till ett fast pris per timme, debiterar den serverlösa beräkningsnivån för den mängd beräkning som används per sekund.

Oavsett beräkningsnivå allokeras tre ytterligare sekundära repliker med hög tillgänglighet automatiskt i tjänstnivån Affärskritisk för att säkerställa hög motståndskraft mot fel och snabba felövergångar. Dessa ytterligare repliker gör kostnaden ungefär 2,7 gånger högre än den är på serviceklassen för Generell användning. På samma sätt återspeglar den högre lagringskostnaden per GB på tjänstnivån Affärskritisk de högre I/O-gränserna och den lokala SSD-lagringens kortare svarstid.

I Hyperskala kontrollerar kunderna antalet ytterligare repliker med hög tillgänglighet från 0 till 4 för att få den återhämtningsnivå som krävs av deras program samtidigt som kostnaderna kontrolleras.

Mer information om beräkning i Azure SQL Database finns i Beräkningsresurser (CPU och minne).

Resursbegränsningar

För resursbegränsningar för virtuella kärnor granskar du de tillgängliga maskinvarukonfigurationeroch granskar sedan resursgränserna för:

Data- och logglagring

Följande faktorer påverkar mängden lagringsutrymme som används för data och loggfiler och gäller för nivåerna Generell användning och Affärskritisk.

Varje beräkningsstorlek stöder en konfigurerbar maximal datastorlek med standardvärdet 32 GB.
När du konfigurerar maximal datastorlek läggs automatiskt ytterligare 30 procent av den fakturerbara lagringen till för loggfilen.
På tjänstnivån Generell användning använder tempdb lokal SSD-lagring och den här lagringskostnaden ingår i priset för virtuell kärna.
På tjänstnivån Affärskritisk delar tempdb lokal SSD-lagring med data och loggfiler, och tempdb lagringskostnad ingår i vCores pris.
På nivåerna Generell användning och Affärskritisk debiteras du för den maximala lagringsstorlek som konfigurerats för en databas eller elastisk pool.
För SQL Database kan du välja valfri maximal datastorlek mellan 1 GB och maximal lagringsstorlek som stöds i steg om 1 GB.

Följande lagringsöverväganden gäller för Hyperskala:

Den maximala datalagringsstorleken är inställd på 128 TB och kan inte konfigureras.
Du debiteras endast för allokerad datalagring, inte för maximal datalagring.
Du debiteras inte för logglagring.
tempdb använder lokal SSD-lagring och kostnaden ingår i priset för virtuella kärnor. Om du vill övervaka den aktuella allokerade och använda datalagringsstorleken i SQL Database använder du måtten allocated_data_storage och lagring Azure Monitor .

Om du vill övervaka den aktuella allokerade och använda lagringsstorleken för enskilda data och loggfiler i en databas med hjälp av T-SQL använder du sys.database_files-vyn och funktionen FILEPROPERTY(... , "SpaceUsed").

Tips

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.

Lagring av säkerhetskopior

Lagring för databassäkerhetskopior allokeras för att stödja återställning vid en viss tidpunkt (PITR) och långsiktig kvarhållning (LTR) kapaciteter i SQL Database. Den här lagringen är separat från data- och loggfillagring och faktureras separat.

PITR-: I nivåerna Generell användning och Affärskritisk kopieras enskilda databassäkerhetskopior till Azure Storage automatiskt. Lagringsstorleken ökar dynamiskt när nya säkerhetskopior skapas. Lagringen används av fullständiga säkerhetskopior, differentiella säkerhetskopior och transaktionsloggar. Lagringsförbrukningen beror på ändringshastigheten för databasen och den kvarhållningsperiod som konfigurerats för säkerhetskopior. Du kan konfigurera en separat kvarhållningsperiod för varje databas mellan 1 och 35 dagar för SQL Database. En lagringsmängd för säkerhetskopiering som är lika med den konfigurerade maximala datastorleken tillhandahålls utan extra kostnad.
LTR: Du kan också konfigurera långsiktig kvarhållning av fullständiga säkerhetskopior i upp till 10 år. Om du konfigurerar en LTR-princip lagras dessa säkerhetskopior automatiskt i Azure Blob Storage, men du kan styra hur ofta säkerhetskopiorna kopieras. För att uppfylla olika efterlevnadskrav kan du välja olika kvarhållningsperioder för veckovisa, månatliga och/eller årliga säkerhetskopieringar. Den konfiguration du väljer avgör hur mycket lagringsutrymme som används för LTR-säkerhetskopieringar. Mer information finns i Långsiktig kvarhållning av säkerhetskopior.

Information om lagring av säkerhetskopior i Hyperskala finns i Automatiserade säkerhetskopieringar för Hyperskala-databaser.

Tjänstnivåer

Alternativ på tjänstnivå i köpmodellen för virtuella kärnor inkluderar Generell användning, Affärskritisk och Hyperskala. Tjänstnivån avgör vanligtvis lagringstyp och prestanda, alternativ för hög tillgänglighet och haveriberedskap samt tillgängligheten för vissa funktioner, till exempel In-Memory OLTP.

Användningsfall	generell användning	Affärskritisk	Hyperskala
bäst för	De flesta företagsarbetsbelastningar. Erbjuder budgetorienterade, balanserade och skalbara beräknings- och lagringsalternativ.	Erbjuder affärsprogram den högsta motståndskraften mot fel med hjälp av flera sekundära repliker med hög tillgänglighet och ger högsta I/O-prestanda.	Det bredaste utbudet av arbetsbelastningar, inklusive arbetsbelastningar med mycket skalbar lagring och krav på lässkalning. Ger högre motståndskraft mot fel genom att tillåta konfiguration av mer än en sekundär replik med hög tillgänglighet.
Beräkningsstorlek	2 till 128 virtuella kärnor	2 till 128 virtuella kärnor	2 till 128 virtuella kärnor
Lagringstyp	Premium-fjärrlagring (per instans)	Supersnabb lokal SSD-lagring (per instans)	Frikopplad lagring med lokal SSD-cache (per beräkningsexemplar)
Lagringsstorlek	1 GB – 4 TB	1 GB – 4 TB	10 GB – 128 TB
IOPS	320 IOPS per virtuell kärna med maximalt 16 000 IOPS	4 000 IOPS per virtuell kärna med maximalt 327 680 IOPS	327 680 IOPS med maximal lokal SSD Hyperskala är en arkitektur med flera nivåer med cachelagring på flera nivåer. Effektiv IOPS beror på arbetsbelastningen.
minne/vCore	5,1 GB	5,1 GB	5,1 GB eller 10,2 GB
Säkerhetskopieringar	Ett val av geo-redundant, zonredundant eller lokalt redundant säkerhetskopieringslagring, 1–35 dagars kvarhållning (standard 7 dagar) Långsiktig lagring tillgänglig upp till 10 år	Ett val av geo-redundant, zonredundant eller lokalt redundant säkerhetskopieringslagring, 1–35 dagars lagringstid (standard 7 dagar) Långsiktig förvaring upp till 10 år tillgänglig	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
tillgänglighet	En replik, inga läsoptimerade repliker, zonredundant hög tillgänglighet (HA)	Tre repliker, en läseskalningsreplik, zonalredundant hög driftsäkerhet (HA)	zonredundant hög tillgänglighet (HA)
Prissättning/fakturering	vCore, reserverad lagring och lagring av säkerhetskopior debiteras. IOPS debiteras inte.	virtuella kärnor, reserverad lagring och lagring av säkerhetskopior debiteras. IOPS debiteras inte.	vCore per replik och använt lagringsutrymme debiteras. IOPS debiteras inte.
Rabattmodeller	Azure-reservationer Azure Hybrid Benefit (inte tillgängligt för dev/test-prenumerationer) Enterprise- och Betala per användningYou-Go Dev/Test-erbjudande prenumerationer	Azure-reservationer Azure Hybrid Benefit (inte tillgängligt för dev/test-prenumerationer) Enterprise- och Betala enligt användningYou-Go Dev/Test-erbjudande prenumerationer	Azure Hybrid Benefit (inte tillgängligt för dev/test-prenumerationer) ¹ Enterprise- och Betala enligt användningYou-Go utveckling/test-erbjudande prenumerationer
Minnesinterna OLTP-tabeller	Nej	Ja	Ingen

¹ Förenklad prissättning för SQL Database Hyperscale kommer snart. Läs bloggen om prissättning för Hyperskala för mer information.

Mer information finns i resursgränser för logisk server, enkla databaseroch pooldatabaser.

Not

Mer information om serviceavtalet (SLA) finns i serviceavtal för Azure SQL Database

Generell användning

Arkitekturmodellen för tjänstnivån Generell användning baseras på en uppdelning av beräkning och lagring. Den här arkitekturmodellen förlitar sig på hög tillgänglighet och tillförlitlighet för Azure Blob Storage som transparent replikerar databasfiler och garanterar ingen dataförlust om underliggande infrastrukturfel inträffar.

Följande bild visar fyra noder i standardarkitekturmodellen med de avgränsade beräknings- och lagringsskikten.

diagram som illustrerar separationen av beräkning och lagring.

I arkitekturmodellen för tjänstnivån Generell användning finns det två lager:

Ett tillståndslöst beräkningslager som kör sqlservr.exe processen och som endast innehåller tillfälliga och cachelagrade data (till exempel plancache, buffertpool, kolumnlagringspool). Den här tillståndslösa noden drivs av Azure Service Fabric som initierar processen, kontrollerar nodens hälsotillstånd och utför redundansväxling till en annan plats om det behövs.
Ett tillståndskänsligt datalager med databasfiler (.mdf/.ldf) som lagras i Azure Blob Storage. Azure Blob-lagring garanterar att det inte sker någon dataförlust för något register som placeras i en databasfil. Azure Storage har inbyggd datatillgänglighet/redundans som säkerställer att varje post i loggfilen eller sidan i datafilen bevaras även om processen kraschar.

När databasmotorn eller operativsystemet uppgraderas misslyckas en del av den underliggande infrastrukturen, eller om något kritiskt problem identifieras i sqlservr.exe processen, flyttar Azure Service Fabric den tillståndslösa processen till en annan tillståndslös beräkningsnod. Det finns en uppsättning extra noder som väntar på att köra den nya beräkningstjänsten om en redundansväxling av den primära noden sker för att minimera redundanstiden. Data i Azure Storage-lagret påverkas inte och data-/loggfiler kopplas till den nyligen initierade processen. Den här processen garanterar 99,99% tillgänglighet som standard och 99,995% tillgänglighet när zonredundans är aktiverad. Det kan finnas vissa prestandaeffekter för tunga arbetsbelastningar som är under flygning på grund av övergångstid och det faktum att den nya noden börjar med kall cache.

När du ska välja tjänstenivån Allmänt syfte

Tjänstnivån Generell användning är standardtjänstnivån i Azure SQL Database som utformats för de flesta allmänna arbetsbelastningar. Om du behöver en fullständigt hanterad databasmotor med ett standard-SLA och lagringssvarstid mellan 5 ms och 10 ms är nivån Generell användning alternativet för dig.

Affärskritisk

Tjänstnivåmodellen Business Critical baseras på ett kluster med databasmotorprocesser. Den här arkitekturmodellen förlitar sig på ett kvorum av databasmotornoder för att minimera prestandapåverkan på din arbetsbelastning, även under underhållsaktiviteter. Uppgraderingar och korrigeringar av det underliggande operativsystemet, drivrutinerna och databasmotorn sker transparent, med minimal stilleståndstid för slutanvändarna.

I den affärskritiska modellen integreras beräkning och lagring på varje nod. Replikering av data mellan databasmotorprocesser på varje nod i ett kluster med fyra noder ger hög tillgänglighet, där varje nod använder lokalt ansluten SSD som datalagring. Följande diagram visar hur tjänstnivån Affärskritisk organiserar ett kluster med databasmotornoder i tillgänglighetsgrupprepliker.

Både databasmotorprocessen och underliggande .mdf/.ldf-filer placeras på samma nod med lokalt ansluten SSD-lagring, vilket ger låg svarstid för din arbetsbelastning. Hög tillgänglighet implementeras med hjälp av teknik som liknar SQL Server AlwaysOn-tillgänglighetsgrupper. Varje databas är ett kluster med databasnoder med en primär replik som är tillgänglig för kundarbetsbelastningar och tre sekundära repliker som innehåller kopior av data. Den primära repliken skickar ständigt ändringar till de sekundära replikerna för att säkerställa att data är tillgängliga på sekundära repliker om den primära av någon anledning misslyckas. Redundans hanteras av Service Fabric och databasmotorn – en sekundär replik blir den primära och en ny sekundär replik skapas för att säkerställa att det finns tillräckligt med noder i klustret. Arbetsbelastningen omdirigeras automatiskt till den nya primära repliken.

Dessutom har det affärskritiska klustret en inbyggd Läsutvidgningsfunktion som erbjuder en kostnadsfri skrivskyddad replik för att köra skrivskyddade frågor (t.ex. rapporter) som inte påverkar prestandan hos arbetsbelastningen på din primära replik.

När du ska välja tjänstnivån Affärskritisk

Tjänstnivån Affärskritisk är utformad för program som kräver svar med låg svarstid från den underliggande SSD-lagringen (1–2 ms i genomsnitt), snabbare återställning om den underliggande infrastrukturen misslyckas eller behöver avlasta rapporter, analyser och skrivskyddade frågor till den kostnadsfria läsbara sekundära repliken av den primära databasen.

De viktigaste orsakerna till varför du bör välja Affärskritisk tjänstnivå i stället för Generell användning är:

krav på låg I/O-svarstid – arbetsbelastningar som behöver ett konsekvent snabbt svar från lagringsskiktet (1–2 millisekunder i genomsnitt) bör använda nivån Affärskritisk.
arbetsbelastning med rapporterings- och analysfrågor där en enda kostnadsfri sekundär skrivskyddad replik räcker.
Högre återhämtning och snabbare återställning från fel. Om det uppstår systemfel inaktiveras databasen för den primära instansen och en av de sekundära replikerna blir omedelbart den nya primära skriv-läs-databasen som är redo att bearbeta frågor.
Avancerat skydd mot datakorruption. Eftersom affärskritisk-nivån använder databasrepliker i det fördolda, använder tjänsten automatisk sidreparation som är tillgänglig med speglings- och tillgänglighetsgrupper för att minska risk för datakorruption. Om en replik inte kan läsa en sida på grund av ett dataintegritetsproblem hämtas en ny kopia av sidan från en annan replik och ersätter den olästa sidan utan dataförlust eller kundavbrott. Den här funktionen är tillgänglig på nivån Generell användning om databasen har geo-sekundär replik.
Högre tillgänglighet – Den affärskritiska nivån i en konfiguration med flera tillgänglighetszoner förser motståndskraft mot zonfel och ett serviceavtal med högre tillgänglighet.
Snabb geo-återställning – När aktiv geo-replikering har konfigurerats har nivån Affärskritisk ett garanterat mål för återställningspunkt (RPO) på 5 sekunder och mål för återställningstid (RTO) på 30 sekunder i 100% distribuerade timmar.

Hyperskala

Tjänstnivån Hyperskala är lämplig för alla arbetsbelastningstyper. Dess molnbaserade arkitektur ger oberoende skalbar beräkning och lagring för att stödja den bredaste variationen av traditionella och moderna program. Beräknings- och lagringsresurser i Hyperskala överskrider avsevärt de resurser som är tillgängliga på nivåerna Generell användning och Affärskritisk.

För att lära dig mer, granska tjänstnivån Hyperskala för Azure SQL Database.

När du ska välja tjänstnivån Hyperskala

Tjänstnivån Hyperskala tar bort många av de praktiska gränser som traditionellt sett setts i molndatabaser. Om de flesta andra databaser begränsas av de resurser som är tillgängliga i en enda nod har databaser på tjänstnivån Hyperskala inga sådana gränser. Med sin flexibla lagringsarkitektur växer en Hyperskala-databas efter behov – och du debiteras endast för den lagringskapacitet som du använder.

Utöver de avancerade skalningsfunktionerna är Hyperskala ett bra alternativ för alla arbetsbelastningar, inte bara för stora databaser. Med Hyperskala kan du:

Uppnå hög motståndskraft och snabb felåterhämtning samtidigt som du kontrollerar kostnaderna genom att välja antal repliker för hög tillgänglighet från 0 till 4.
Förbättra hög tillgänglighet genom att aktivera zonredundans för beräkning och lagring.
Uppnå låg I/O-svarstid (i genomsnitt 1–2 millisekunder) för den ofta använda delen av databasen. För mindre databaser kan detta gälla för hela databasen.
Implementera en mängd olika lässkalningsscenarier med namngivna repliker.
Dra nytta av snabb skalning, utan att vänta på att data ska kopieras till lokal lagring på nya noder.
Njut av kontinuerlig säkerhetskopiering som inte påverkar och snabb återställning.
Stöd krav på affärskontinuitet med hjälp av redundansgrupper och geo-replikering.

Maskinvarukonfiguration

Vanliga maskinvarukonfigurationer i vCore-modellen är standardserier (Gen5), Fsv2-serien och DC-serien. Hyperskala ger också ett alternativ för maskinvara i premium-serien och minnesoptimerad maskinvara i premium-serien. Maskinvarukonfiguration definierar beräknings- och minnesgränser och andra egenskaper som påverkar arbetsbelastningens prestanda.

Vissa maskinvarukonfigurationer som standardserier (Gen5) kan använda mer än en typ av processor (CPU), enligt beskrivningen i Beräkningsresurser (CPU och minne). Även om en viss databas eller elastisk pool tenderar att finnas kvar på maskinvaran med samma CPU-typ under en lång tid (vanligtvis i flera månader), finns det vissa händelser som kan leda till att en databas eller pool flyttas till maskinvara som använder en annan CPU-typ.

En databas eller pool kan flyttas för en mängd olika scenarier, inklusive men inte begränsat till när:

Tjänstmålet ändras
Den aktuella infrastrukturen i ett datacenter närmar sig kapacitetsbegränsningar
Den maskinvara som används för närvarande tas ur bruk eftersom den har nått slutet på sin livstid.
Zonredundant konfiguration är aktiverad och flyttas till en annan hårdvara på grund av tillgänglig kapacitet.

För vissa arbetsbelastningar kan en övergång till en annan CPU-typ ändra prestanda. SQL Database konfigurerar maskinvara med målet att tillhandahålla förutsägbara arbetsbelastningsprestanda även om CPU-typen ändras, vilket håller prestandaändringar inom ett smalt band. Men över hela spektrumet av kundarbetsbelastningar i SQL Database och när nya typer av processorer blir tillgängliga kan det ibland se mer märkbara prestandaförändringar om en databas eller pool flyttas till en annan CPU-typ.

Oavsett vilken processortyp som används förblir resursgränserna för en databas eller elastisk pool (till exempel antalet kärnor, minne, maximal data-IOPS, maximal loggfrekvens och maximalt antal samtidiga arbetare) desamma så länge databasen ligger kvar på samma tjänstmål.

Beräkningsresurser (CPU och minne)

I följande tabell jämförs beräkningsresurser i olika maskinvarukonfigurationer och beräkningsnivåer:

Maskinvarukonfiguration	CPU	Minne
Standardserie (Gen5)	Etablerad beräkning - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) processorer – Etablera upp till 128 vCPU (med hypertrådning) serverlös beräkning* - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC 7763v (Milan) processorer – Skalera automatiskt upp till 80 virtuella kärnor (med hypertrådning) – Förhållandet mellan minne och virtuell kärna anpassas dynamiskt till minnes- och CPU-användning baserat på efterfrågan på arbetsbelastningar och kan vara så högt som 24 GB per virtuell kärna. Vid en viss tidpunkt kan till exempel en arbetsbelastning använda och faktureras för 240 GB minne och endast 10 virtuella kärnor.	Tilldelad beräkningskapacitet - 5,1 GB per vCore – Tillhandahålla upp till 625 GB serverlös beräkning – Skala upp till 24 GB per virtuell kärna automatiskt – Skala upp till högst 240 GB automatiskt
Fsv2-serien	– Intel® 8168-processorer (Skylake) - Med en ihållande turbo klockfrekvens för alla kärnor på 3,4 GHz och en maximal turbo klockfrekvens för enskild kärna på 3,7 GHz. – Etablera upp till 72 virtuella kärnor (hypertrådad)	- 1,9 GB per vCore – Tilldela upp till 136 GB
DC-serien	– Intel® Xeon® E-2288G-processorer - Med Intel Software Guard-tillägget (Intel SGX) – Etablera upp till 8 virtuella kärnor (fysisk)	4,5 GB per vCPU

* I vyn sys.dm_user_db_resource_governance dynamisk hantering visas maskinvarugenerering för databaser med Intel® SP-8160-processorer (Skylake) som Gen6, maskinvarugenerering för databaser med Intel® 8272CL (Cascade Lake) visas som Gen7 och maskinvarugenerering för databaser med Intel® Xeon® Platinum 8370C (Ice Lake) eller AMD® EPYC® 7763v (Milano) visas som Gen8. För en viss beräkningsstorlek och maskinvarukonfiguration är resursgränserna desamma oavsett CPU-typ (Intel Broadwell, Skylake, Ice Lake, Cascade Lake eller AMD Milan).

Mer information finns i resursgränser för enskilda databaser och elastiska pooler.

Information om beräkningsresurser och specifikationer för hyperskaladatabaser finns i Hyperskala beräkningsresurser.

Standardserie (Gen5)

Maskinvara i Standard-serien (Gen5) tillhandahåller balanserade beräknings- och minnesresurser och är lämplig för de flesta databasarbetsbelastningar.

Standardseriemaskinvara (Gen5) är tillgänglig i alla offentliga regioner över hela världen.

Premiumserie hyperskala

Maskinvarualternativ i Premium-serien använder den senaste processor- och minnestekniken från Intel och AMD. Premium-serien ger en ökning av beräkningsprestanda i förhållande till maskinvara i standardserien.

Alternativet Premium-serien ger snabbare CPU-prestanda jämfört med Standard-serien och ett högre antal virtuella kärnor.
Det minnesoptimerade alternativet i Premium-serien erbjuder dubbelt så mycket minne i förhållande till Standard-serien.

Standardserier, premiumserier och premiumserier med optimerat minne finns tillgängliga för Hyperskala elastiska pooler.

Mer information finns i bloggmeddelandet om Hyperscale premiumserien .

Tillgängliga regioner finns i Premium-seriens tillgänglighet för Hyperskala.

Fsv2-serien

Fsv2-serien är en beräkningsoptimerad maskinvarukonfiguration som ger låg CPU-svarstid och hög klockfrekvens för de mest CPU-krävande arbetsbelastningarna. På samma sätt som Hyperskala premiumserie maskinvarukonfigurationer är Fsv2-serien utrustad med den senaste CPU- och minnestekniken från Intel och AMD, vilket gör att kunderna kan dra nytta av den senaste maskinvaran när de använder databaser och elastiska pooler på tjänstenivån Allmänt användningsområde.
Beroende på arbetsbelastningen kan Fsv2-serien leverera mer CPU-prestanda per virtuell kärna än andra typer av maskinvara. Till exempel kan beräkningsstorleken 72 virtuella kärnor Fsv2 ge mer CPU-prestanda än 80 virtuella kärnor i Standard-serien (Gen5), till lägre kostnad.
Fsv2 ger mindre minne och tempdb per virtuell kärna än annan maskinvara, så arbetsbelastningar som är känsliga för dessa gränser kan fungera bättre på standardserier (Gen5).

Fsv2-serien stöds endast i General Purpose-nivån. För regioner där Fsv2-serien är tillgänglig, se Fsv2-seriens tillgänglighet.

DC-serien

Dc-seriens maskinvara använder Intel-processorer med Software Guard-tilläggsteknik (Intel SGX).
DC-serien krävs för Always Encrypted med säkra enklaver arbetsbelastningar som kräver ett starkare säkerhetsskydd för maskinvaruenklaver, jämfört med virtualiseringsbaserade enklaver (VBS).
DC-serien är utformad för arbetsbelastningar som bearbetar känsliga data och kräver konfidentiella frågebearbetningsfunktioner, som tillhandahålls av Always Encrypted med säkra enklaver.
DC-seriens maskinvara tillhandahåller balanserade beräknings- och minnesresurser.

DC-serien stöds endast för etablerad beräkning (serverlös stöds inte) och stöder inte zonredundans. Information om regioner där DC-serien är tillgänglig finns i tillgänglighet för DC-serien.

Azure-erbjudandetyper som stöds av DC-serien

Om du vill skapa databaser eller elastiska pooler på DC-seriens maskinvara måste prenumerationen vara en typ av betalerbjudande, inklusive betala perYou-Go eller Enterprise-avtal (EA). En fullständig lista över Azure-erbjudandetyper som stöds av DC-serien finns i aktuella erbjudanden utan utgiftsgränser.

Välj maskinvarukonfiguration

Du kan välja maskinvarukonfiguration för en databas eller elastisk pool i SQL Database när den skapas. Du kan också ändra maskinvarukonfigurationen för en befintlig databas eller elastisk pool.

Om du vill välja en maskinvarukonfiguration när du skapar en SQL Database- eller pool-

Detaljerad information finns i Skapa en SQL Database-.

På fliken Grundläggande väljer du länken Konfigurera databas i avsnittet Compute + Storage och väljer sedan länken Ändra konfiguration:

Välj önskad maskinvarukonfiguration:

Så här ändrar du maskinvarukonfigurationen för en befintlig SQL Database eller pool

För en databas går du till sidan Översikt och väljer länken prisnivå:

För en pool går du till sidan Översikt och väljer Konfigurera.

Följ stegen för att ändra konfigurationen och välj maskinvarukonfiguration enligt beskrivningen i föregående steg.

Maskinvarutillgänglighet

Information om tidigare generations maskinvarutillgänglighet finns i tidigare generationens maskinvarutillgänglighet.

Information om den aktuella generationens maskinvarutillgänglighet finns i Funktionstillgänglighet per region för Azure SQL Database.

Tidigare generations maskinvara

Gen4

Gen4-maskinvaran har dragits tillbaka och är inte tillgänglig för etablering, uppskalning eller nedskalning. Migrera databasen till en maskinvarugenerering som stöds för ett bredare utbud av skalbarhet för virtuella kärnor och lagring, accelererat nätverk, bästa I/O-prestanda och minimal svarstid. Granska maskinvarualternativ för enskilda databaser och maskinvarualternativ för elastiska pooler. Mer information finns i supporten har upphört för Gen 4-maskinvara i Azure SQL Database.

Nästa steg

Snabbstart: Skapa en enkel databas – Azure SQL Database