Azure SQL Database serverlös

GÄLLER FÖR: Azure SQL Database

Serverlös är en beräkningsnivå för enskilda databaser i Azure SQL Database som automatiskt skalar beräkningen utifrån arbetsbelastningsbehovet. Kunden faktureras för den mängd databearbetning som används per sekund. På den serverlösa beräkningsnivån pausas databaser automatiskt under inaktiva perioder och då faktureras endast lagring. Databaserna startas igen automatiskt när aktiviteten återupptas.

Serverlös beräkningsnivå

Den serverlösa beräkningsnivån för enskilda databaser i Azure SQL Database är parametriserad med ett intervall för automatisk beräkningsskalning och en fördröjning vid automatisk paus. Konfigurationen av dessa parametrar formar databasens prestandaupplevelse och beräkningskostnad.

Prestandakonfiguration

• Minsta virtuella kärnor och maximalt antal virtuella kärnor är konfigurerbara parametrar som definierar intervallet för databasens tillgängliga beräkningskapacitet. Minnes- och I/O-gränser är proportionella mot det angivna vCore-intervallet. 
• Fördröjningen för automatisk paus är en konfigurerbar parameter som definierar hur lång tid databasen måste vara inaktiv innan den pausas automatiskt. Databasen återupptas automatiskt när nästa inloggning eller annan aktivitet inträffar. Du kan också inaktivera automatisk pausning.

Cost

• Kostnaden för en serverlös databas är sammanfattningen av beräkningskostnaden och lagringskostnaden.
• När beräkningsanvändningen är mellan den minsta och högsta gränsen som konfigurerats baseras beräkningskostnaden på vCore och använt minne.
• När beräkningsanvändningen understiger de min-gränser som konfigurerats baseras beräkningskostnaden på de minsta virtuella kärnorna och det minsta konfigurerade minnet.
• När databasen har pausats är beräkningskostnaden noll och endast lagringskostnaderna tillkommer.
• Lagringskostnaden bestäms på samma sätt som på den etablerade beräkningsnivån.

Mer information om kostnader finns i Fakturering.

Scenarier

Nivån med serverlös databehandling är pris/prestanda-optimerad för enstaka databaser med oförutsägbart användningsmönster som inte störs av viss fördröjning i databehandlingen efter inaktiva perioder. Nivån med etablerad databehandling är å andra sidan pris/prestanda-optimerad för enstaka eller flera databaser i elastiska pooler med högre genomsnittlig användning där det inte får förekomma en sådan fördröjning.

Scenarier som passar bra för serverlös beräkning

• Enskilda databaser med tillfälliga, oförutsägbara användningsmönster översked med perioder av inaktivitet och lägre genomsnittlig beräkningsanvändning över tid.
• Enkla databaser på den etablerade beräkningsnivån som ofta skalas om och kunder som föredrar att delegera omskalning av beräkningar till tjänsten.
• Nya enskilda databaser utan användningshistorik där det är svårt eller omöjligt att beräkna beräkningsändringen före distributionen i SQL Database.

Scenarier som passar bra för etablerade beräkningar

• Enkla databaser med mer vanliga, förutsägbara användningsmönster och högre genomsnittlig beräkningsanvändning över tid.
• Databaser som inte tolererar prestandakonflikter på grund av mer frekvent minnes trimning eller fördröjningar i återupptas från ett pausat tillstånd.
• Flera databaser med tillfälliga, oförutsägbara användningsmönster som kan konsolideras till elastiska pooler för bättre optimering av prisprestanda.

Jämförelse med den etablerade beräkningsnivån

I följande tabell sammanfattas skillnaderna mellan den serverlösa beräkningsnivån och den etablerade beräkningsnivån:

Köpmodell och tjänstnivå

SQL Database serverlös stöds för närvarande endast på Generell användning på generation 5-maskinvara i köpmodellen vCore.

Automatisk skalning

Skalning av svarstider

I allmänhet körs serverlösa databaser på en dator med tillräcklig kapacitet för att uppfylla resursbehovet utan avbrott för den mängd beräkning som begärs inom de gränser som anges av värdet för maximalt antal virtuella kärnor. Ibland inträffar belastningsutjämning automatiskt om datorn inte kan uppfylla resursbehovet inom några minuter. Om resursbehovet till exempel är 4 virtuella kärnor, men bara 2 virtuella kärnor är tillgängliga, kan det ta upp till några minuter att belastningsutjämna innan 4 virtuella kärnor har angetts. Databasen förblir online under belastningsutjämningen, förutom under en kort period i slutet av åtgärden när anslutningarna tas bort.

Minneshantering

Minne för serverlösa databaser återtas oftare än för etablerade beräkningsdatabaser. Det här beteendet är viktigt för att kontrollera kostnaderna i serverlöst och kan påverka prestandan.

Cache-återskapning

Till skillnad från etablerade beräkningsdatabaser återtas minne SQL cacheminnet från en serverlös databas när processoranvändningen eller den aktiva cacheanvändningen är låg.

• Aktiv cacheanvändning anses låg när den totala storleken på de senast använda cacheposterna understiger ett tröskelvärde under en viss tidsperiod.
• När cache-återaktivering utlöses minskas målcachestorleken stegvis till en bråkdel av den tidigare storleken och återtar bara om användningen förblir låg.
• När cache-återtagning sker är principen för att välja cacheposter som ska avlägsnas samma urvalsprincip som för etablerade beräkningsdatabaser när minnestrycket är högt.
• Cachestorleken minskas aldrig under den minsta minnesgränsen som definieras av minsta virtuella kärnor som kan konfigureras.

I både serverlösa och etablerade beräkningsdatabaser kan cacheposter avlägsnas om allt tillgängligt minne används.

När processoranvändningen är låg kan den aktiva cacheanvändningen förbli hög beroende på användningsmönstret och förhindra minnesanvändning. Det kan också finnas andra fördröjningar när användaraktiviteten stoppas innan minnesrelamering sker på grund av periodiska bakgrundsprocesser som svarar på tidigare användaraktivitet. Till exempel genererar borttagningsåtgärder och rensningsuppgifter i Query Store spökposter som är markerade för borttagning, men som inte tas bort fysiskt förrän spökrensningsprocessen körs. Spökrensning kan innebära att läsa ytterligare datasidor i cacheminnet.

Extra information om cachelagring

Den SQL cachen växer när data hämtas från disken på samma sätt och med samma hastighet som för etablerade databaser. När databasen är upptagen tillåts cacheminnet att växa obegränsade upp till den maximala minnesgränsen.

Automatisk pausning och automatisk återupptagande

Pausa automatiskt

Automatisk pausning utlöses om alla följande villkor är sanna under varaktigheten för den automatiska pausfördröjningen:

• Antal sessioner = 0
• CPU = 0 för användararbetsbelastning som körs i användarresurspoolen

Det finns ett alternativ för att inaktivera automatisk pausning om du vill.

Följande funktioner stöder inte automatisk pausning, men har stöd för automatisk skalning. Om någon av följande funktioner används måste automatisk pausning inaktiveras och databasen förblir online oavsett varaktigheten för databasens inaktivitet:

• Geo-replikering(aktiv geo-replikering och automatiska redundansgrupper).
• Långsiktig kvarhållning av säkerhetskopior (LTR).
• Synkroniseringsdatabasen som används i SQL Data Sync. Till skillnad från synkroniseringsdatabaser stöder hubb- och medlemsdatabaser automatisk pausning.
• DNS-alias som skapats för den logiska servern som innehåller en serverlös databas.
• Elastiska jobb (förhandsversion)när jobbdatabasen är en serverlös databas. Databaser som är mål för elastiska jobb stöder automatisk pausning och återupptas av jobbanslutningar.

Automatisk pausning förhindras tillfälligt under distributionen av vissa tjänstuppdateringar som kräver att databasen är online. I sådana fall tillåts automatisk pausning igen när tjänstuppdateringen har slutförts.

Pausa felsökning automatiskt

Om automatisk pausning är aktiverat, men en databas inte pausar automatiskt efter fördröjningsperioden och funktionerna som anges ovan inte används, kan programmet eller användarsessionerna förhindra automatisk pausning. Om du vill se om det finns några program- eller användarsessioner som för närvarande är anslutna till databasen ansluter du till databasen med val annat klientverktyg och kör följande fråga:

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
      (
      wg.name like 'UserPrimaryGroup.DB%'
      AND
      TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
      )
      OR
      wg.name = 'DACGroup'
      );

Om resultatuppsättningen inte är tom betyder det att det finns sessioner som för närvarande förhindrar automatisk pausning.

Om resultatuppsättningen är tom är det fortfarande möjligt att sessionerna var öppna, möjligen under en kort tid, någon gång tidigare under fördröjningsperioden för automatisk paus. Om du vill se om sådan aktivitet har inträffat under fördröjningsperioden kan du använda Azure SQL Auditing och granska granskningsdata för den aktuella perioden.

Förekomsten av öppna sessioner, med eller utan samtidig processoranvändning i användarresurspoolen, är den vanligaste orsaken till att en serverlös databas inte pausar automatiskt som förväntat.

Återuppta automatiskt

Automatisk återupptagande utlöses om något av följande villkor är sant när som helst:

Övervakning, hantering eller andra lösningar som utför någon av de åtgärder som anges ovan utlöser automatisk återupptagande.

Automatisk återupptagande utlöses också under distributionen av vissa tjänstuppdateringar som kräver att databasen är online.

Anslutning

Om en serverlös databas har pausats återupptar den första inloggningen databasen och returnerar ett fel som anger att databasen inte är tillgänglig med felkoden 40613. När databasen har återupptagits måste inloggningen försöka upprättas igen. Databasklienter med logik för anslutningsförsök bör inte behöva ändras. Information om logikalternativ för anslutningsförsök som är inbyggda i SqlClient-drivrutinen finns i konfigurerbar omprövningslogik i SqlClient.

Svarstid

Svarstiden för att återuppta automatiskt och automatiskt pausa en serverlös databas är vanligtvis i ordning 1 minut för att återuppta automatiskt och 1–10 minuter efter att fördröjningsperioden för automatisk paus har löpt ut.

Kund hanterad transparent datakryptering (BYOK)

Om användningen av kund hanterad transparent datakryptering (BYOK) och den serverlösa databasen pausas automatiskt när nyckelborttagning eller återkallning sker, förblir databasen i automatiskt pausat tillstånd. I det här fallet blir databasen otillgänglig inom cirka 10 minuter efter att databasen har återupptagits. När databasen blir otillgänglig är återställningsprocessen densamma som för etablerade beräkningsdatabaser. Om den serverlösa databasen är online när nyckelborttagning eller återkallelse inträffar blir databasen också otillgänglig inom cirka 10 minuter på samma sätt som med etablerade beräkningsdatabaser.

Registrering på serverlös beräkningsnivå

Att skapa en ny databas eller flytta en befintlig databas till en serverlös beräkningsnivå följer samma mönster som när du skapar en ny databas på den etablerade beräkningsnivån och omfattar följande två steg.

1. Ange tjänstmålet. Tjänstmålet fastställer tjänstnivå, maskinvarugenerering och maximalt antal virtuella kärnor. Information om alternativ för tjänstmål finns i gränser för serverlösa resurser

2. Du kan också ange minsta virtuella kärnor och automatisk pausa fördröjningen för att ändra standardvärdena. I följande tabell visas tillgängliga värden för dessa parametrar.

   Parameter	Värdeval	Standardvärde
   Minsta virtuella kärnor	Beror på maximalt antal konfigurerade virtuella kärnor – se resursbegränsningar.	0,5 virtuella kärnor
   Fördröjning vid automatiskpaus	Minst: 60 minuter (1 timme) Max: 1 0080 minuter (7 dagar) Steg: 10 minuter Inaktivera autopause: -1	60 minuter

Skapa en ny databas på den serverlösa beräkningsnivån

I följande exempel skapas en ny databas på den serverlösa beräkningsnivån.

Använda Azure-portalen

Se Snabbstart: Skapa en enkel databas i Azure SQL Database med hjälp av Azure Portal.

Använd PowerShell

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -ComputeModel Serverless -Edition GeneralPurpose -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720

Använda Azure CLI

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e GeneralPurpose -f Gen5 --min-capacity 0.5 -c 2 --compute-model Serverless --auto-pause-delay 720

Använda Transact-SQL (T-SQL)

När du använder T-SQL tillämpas standardvärden för minsta virtuella kärnor och automatisk fördröjning. De kan senare ändras från portalen eller via andra hanterings-API:er (PowerShell, Azure CLI, REST API).

CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;

Mer information finns i CREATE DATABASE.

Flytta en databas från den etablerade beräkningsnivån till den serverlösa beräkningsnivån

I följande exempel flyttas en databas från den etablerade beräkningsnivån till den serverlösa beräkningsnivån.

Använd PowerShell

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440

Använda Azure CLI

az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
  --edition GeneralPurpose --min-capacity 1 --capacity 4 --family Gen5 --compute-model Serverless --auto-pause-delay 1440

Använda Transact-SQL (T-SQL)

När du använder T-SQL tillämpas standardvärden för minsta virtuella kärnor och fördröjning för automatisk paus. De kan senare ändras från portalen eller via andra hanterings-API:er (PowerShell, Azure CLI, REST API).

ALTER DATABASE testdb 
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;

Mer information finns i ALTER DATABASE.

Flytta en databas från den serverlösa beräkningsnivån till den etablerade beräkningsnivån

En serverlös databas kan flyttas till en etablerad beräkningsnivå på samma sätt som en etablerad beräkningsdatabas flyttas till en serverlös beräkningsnivå.

Ändra serverlös konfiguration

Använd PowerShell

Ändring av högsta eller lägsta antal virtuella kärnor och automatisk fördröjning utförs med hjälp av kommandot Set-AzSqlDatabase i PowerShell med argumenten MaxVcore , och MinVcore AutoPauseDelayInMinutes .

Använda Azure CLI

Ändring av högsta eller lägsta antal virtuella kärnor och automatisk fördröjning utförs med hjälp av kommandot az sql db update i Azure CLI med argumenten , och capacity min-capacity auto-pause-delay .

Övervakning

Resurser som används och faktureras

Resurserna i en serverlös databas kapslas in av appaket, SQL instans och entiteter för användarresurspooler.

Appaket

App-paketet är den yttre gränsen för resurshantering för en databas, oavsett om databasen är på en serverlös eller etablerad beräkningsnivå. App-paketet innehåller SQL instansen och externa tjänster som Fulltextsökning som tillsammans omfattar alla användar- och systemresurser som används av en databas i SQL Database. Den SQL instansen allmänt den övergripande resursanvändningen i appaketet.

Användarresurspool

Användarresurspoolen är en inre resurshanteringsgräns för en databas, oavsett om databasen är på en serverlös eller etablerad beräkningsnivå. Användarresurspoolen omfattar CPU och I/O för användararbetsbelastningar som genereras av DDL-frågor som CREATE och ALTER, DML-frågor som INSERT, UPDATE, DELETE och MERGE samt SELECT-frågor. Dessa frågor representerar vanligtvis den mest betydande andelen användning i appaketet.

Mått

Mått för att övervaka resursanvändningen för appaketet och användarresurspoolen för en serverlös databas visas i följande tabell:

Pausa och återuppta status

I Azure Portal visas databasstatusen i översiktsfönstret på den server som visar de databaser som den innehåller. Databasstatusen visas också i översiktsfönstret för databasen.

Använd följande kommandon för att fråga efter paus- och återupptagningsstatus för en databas:

Använd PowerShell

Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

Använda Azure CLI

az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json

Resursgränser

Information om resursbegränsningar finns i serverlös beräkningsnivå.

Fakturering

Mängden beräkning som faktureras är den maximala processoranvändningen och det minne som används varje sekund. Om mängden processoranvändning och använt minne är mindre än den minsta mängd som har etablerats för var och en debiteras det etablerade beloppet. För att jämföra CPU med minne i faktureringssyfte normaliseras minnet till enheter med virtuella kärnor genom att mängden minne i GB omskalas med 3 GB per vCore.

• Debiterad resurs: CPU och minne
• Fakturerat belopp: enhetspris för vCore * max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
• Faktureringsfrekvens: Per sekund

Enhetspriset för virtuella kärnor är kostnaden per vCore per sekund. Se sidan Azure SQL Database specifika enhetspriser i en viss region.

Mängden beräkning som faktureras exponeras med följande mått:

• Mått: app_cpu_billed (vCore sekunder)
• Definition: max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
• Rapporteringsfrekvens: Per minut

Den här kvantiteten beräknas varje sekund och aggregeras över 1 minut.

Minsta beräkningsfaktura

Om en serverlös databas har pausats är beräkningsfakturan noll. Om en serverlös databas inte har pausats är den minsta beräkningsfakturan inte mindre än mängden virtuella kärnor baserat på max (min vCores, min memory GB * 1/3).

Exempel:

• Anta att en serverlös databas inte har pausats och konfigurerats med 8 virtuella kärnor och 1 min vCore motsvarande 3,0 GB minne. Den lägsta beräkningsfakturan baseras sedan på max (1 vCore, 3,0 GB * 1 vCore/3 GB) = 1 vCore.
• Anta att en serverlös databas inte har pausats och konfigurerats med 4 max virtuella kärnor och 0,5 min virtuella kärnor motsvarande 2,1 GB minne. Den lägsta beräkningsfakturan baseras sedan på max (0,5 virtuella kärnor, 2,1 GB * 1 vCore/3 GB) = 0,7 virtuella kärnor.

Priskalkylatorn Azure SQL Database serverlös kan användas för att fastställa det minsta minne som kan konfigureras baserat på antalet konfigurerade högsta och minsta virtuella kärnor. Om de minsta virtuella kärnorna som konfigurerats är större än 0,5 virtuella kärnor är den minsta beräkningsfakturan oberoende av det minsta minnet som konfigurerats och baseras endast på det antal virtuella kärnor som har konfigurerats.

Exempel på ett scenario

Överväg en serverlös databas som konfigurerats med 1 min vCore och 4 max virtuella kärnor. Den här konfigurationen motsvarar cirka 3 GB min minne och 12 GB max minne. Anta att fördröjningen för automatisk paus är inställd på 6 timmar och att databasarbetsbelastningen är aktiv under de första 2 timmarna under en 24-timmarsperiod och annars inaktiv.

I det här fallet debiteras databasen för beräkning och lagring under de första 8 timmarna. Även om databasen är inaktiv från och med den andra timmen debiteras den fortfarande för beräkning under de efterföljande 6 timmarna baserat på den minsta beräkning som etablerats när databasen är online. Endast lagring faktureras under återstoden av 24-timmarsperioden medan databasen pausas.

Mer exakt beräknas beräkningsfakturan i det här exemplet så här:

Anta att beräkningsenhetspriset är 0,000145 USD/vCore/sekund. Den beräkning som debiteras för den här 24-timmarsperioden är sedan produkten av beräkningsenhetens pris och antal sekunder för virtuella kärnor som debiteras: 0,000145 USD/vCore/sekund * 5 0400 vCore sekunder ~ 7,31 USD.

Azure Hybrid-förmån och reserverad kapacitet

Azure Hybrid-förmån (AHB) och rabatter för reserverad kapacitet gäller inte för den serverlösa beräkningsnivån.

Tillgängliga regioner

Den serverlösa beräkningsnivån är tillgänglig över hela världen förutom följande regioner: Kina, östra, Kina, norra, Tyskland, centrala, Tyskland, nordöstra och US Gov centrala (Iowa).

Nästa steg

• Kom igång genom att gå till Snabbstart: Skapa en enkel databas i Azure SQL Database med hjälp av Azure Portal.
• Information om resursbegränsningar finns i Resursgränser för serverlös beräkningsnivå.