Azure SQL Database serverloos

VAN TOEPASSING OP: Azure SQL Database

Serverloos is een compute-laag voor afzonderlijke databases in Azure SQL Database waarmee de compute-resources automatisch worden geschaald op basis van de eisen van de workload en er wordt gefactureerd op basis van de hoeveelheid rekenkracht die per seconde wordt gebruikt. De serverloze compute-laag pauzeert databases ook automatisch tijdens inactieve perioden, zodat er alleen opslag wordt gefactureerd, en hervat databases automatisch wanneer er weer activiteit plaatsvindt.

Serverloze compute-laag

De serverloze rekenlaag voor individuele databases in Azure SQL Database wordt geparameteriseerd door een bereik voor automatisch schalen en een vertraging voor automatisch onderbreken. De configuratie van deze parameters vormt de prestatie-ervaring van de database en de rekenkosten.

serverloze facturering

Prestatieconfiguratie

  • De minimale vCores en het maximum aantal vCores zijn configureerbare parameters die het bereik van de rekencapaciteit definiëren dat beschikbaar is voor de database. Geheugen- en I/O-limieten zijn evenredig met het opgegeven vCore-bereik. 
  • De vertraging voor automatisch onderbreken is een configureerbare parameter die de periode definieert waarin de database inactief moet zijn voordat deze automatisch wordt onderbroken. De database wordt automatisch hervat wanneer de volgende aanmelding of andere activiteit plaatsvindt. Automatische pauze kan ook worden uitgeschakeld.

Kosten

  • De kosten voor een serverloze database zijn de som van de rekenkosten en opslagkosten.
  • Wanneer het rekengebruik tussen de geconfigureerde minimum- en maximumlimiet ligt, worden de rekenkosten gebaseerd op de gebruikte vCore en het geheugen.
  • Wanneer het rekengebruik onder de geconfigureerde minimumlimieten ligt, worden de rekenkosten gebaseerd op de minimum aantal vCores en het minimumgeheugen dat is geconfigureerd.
  • Wanneer de database is onderbroken, zijn de rekenkosten nul en worden alleen opslagkosten gemaakt.
  • De opslagkosten worden op dezelfde manier bepaald als in de inrichtende rekenlaag.

Zie Facturering voor meer kostendetails.

Scenario's

Serverloos is geoptimaliseerd in prijs-prestatieverhouding voor individuele databases met periodieke, onvoorspelbare gebruikspatronen waarbij lichte vertraging bij het maken van berekeningen na een periode van weinig gebruik geen probleem is. De ingerichte rekenlaag is daarentegen geoptimaliseerd in prijs-prestatieverhouding voor individuele databases of meerdere databases in elastische pools met een hoger gemiddeld gebruik dat geen vertraging kan ondervinden bij het maken van berekeningen.

Scenario's die geschikt zijn voor serverloze computing

  • Individuele databases met onregelmatige, onvoorspelbare gebruikspatronen die worden afgewisseld met perioden van inactiviteit en een lager gemiddeld rekengebruik gedurende een bepaalde periode.
  • Individuele databases in de inrichtende rekenlaag die vaak opnieuw worden geschaald en klanten die de herschaaling van rekenkracht liever delegeren aan de service.
  • Nieuwe individuele databases zonder gebruiksgeschiedenis waarbij de rekenkracht moeilijk of niet kan worden schatten vóór de implementatie in SQL Database.

Scenario's die geschikt zijn voor inrichtende rekenkracht

  • Individuele databases met meer regelmatige, voorspelbare gebruikspatronen en een hoger gemiddeld rekengebruik gedurende een bepaalde periode.
  • Databases die geen prestatie-afwegingen kunnen tolereren die het gevolg zijn van frequentere geheugeninkorting of vertragingen bij het hervatting van een onderbroken status.
  • Meerdere databases met onregelmatige, onvoorspelbare gebruikspatronen die kunnen worden geconsolideerd in elastische pools voor een betere optimalisatie van de prijsprestaties.

Vergelijking met inrichtende rekenlaag

De volgende tabel bevat een overzicht van de verschillen tussen de serverloze rekenlaag en de inrichtende rekenlaag:

Serverloze compute Inrichten van rekenkracht
Databasegebruikspatroon Onregelmatige, onvoorspelbare gebruik met een lager gemiddeld rekengebruik gedurende een periode. Meer normale gebruikspatronen met een hoger gemiddeld rekengebruik gedurende een bepaalde periode of meerdere databases die gebruikmaken van elastische pools.
Prestatiebeheerinspanning Lager Hoger
Schaalbaarheid van rekenkracht Automatisch Handmatig
Reactiesnelheid van rekenkracht Lager na inactieve perioden Onmiddellijke
Factureringsgranulariteit Per seconde Per uur

Aankoopmodel en servicelaag

SQL Database serverloos wordt momenteel alleen ondersteund in de Algemeen-laag op hardware van de 5e generatie in het vCore-aankoopmodel.

Automatisch schalen

Reactiesnelheid schalen

In het algemeen worden serverloze databases uitgevoerd op een computer met voldoende capaciteit om te voldoen aan de vraag naar resources, zonder onderbreking van de hoeveelheid rekenkracht die is aangevraagd binnen de limieten die zijn ingesteld door de maximale vCores-waarde. Af en toe treedt taakverdeling automatisch op als de machine binnen een paar minuten niet kan voldoen aan de vraag naar resources. Als de vraag naar resources bijvoorbeeld 4 vCores is, maar er slechts 2 vCores beschikbaar zijn, kan het enkele minuten duren voordat de load balancer van vier vCores is opgegeven. De database blijft online tijdens de taakverdeling, met uitzondering van een korte periode aan het einde van de bewerking wanneer verbindingen worden verwijderd.

Geheugenbeheer

Geheugen voor serverloze databases wordt vaker vrijgevorderd dan voor inrichtende rekendatabases. Dit gedrag is belangrijk om de kosten in serverloos te beheren en kan van invloed zijn op de prestaties.

Cache-reclamatie

In tegenstelling tot inrichtende rekendatabases wordt het geheugen SQL cache vrijgevorderd van een serverloze database wanneer het CPU- of actieve cachegebruik laag is.

  • Actief cachegebruik wordt als laag beschouwd wanneer de totale grootte van de meest recent gebruikte cache-vermeldingen een bepaalde tijd onder een drempelwaarde komt.
  • Wanneer het vrijmaken van de cache wordt geactiveerd, wordt de grootte van de doelcache stapsgewijs gereduceerd tot een fractie van de vorige grootte en wordt het vrijmaken alleen voortgezet als het gebruik laag blijft.
  • Wanneer cache-vrijmaken plaatsvindt, is het beleid voor het selecteren van cache-vermeldingen die moeten worden verwijderd, hetzelfde selectiebeleid als voor inrichtende rekendatabases wanneer de geheugendruk hoog is.
  • De cachegrootte wordt nooit lager dan de minimumgeheugenlimiet, zoals gedefinieerd door min. vCores, die kunnen worden geconfigureerd.

In zowel serverloze als inrichtende rekendatabases kunnen cache-vermeldingen worden verwijderd als alle beschikbare geheugen wordt gebruikt.

Wanneer het CPU-gebruik laag is, kan het actieve cachegebruik hoog blijven, afhankelijk van het gebruikspatroon en kan geheugen niet worden vrijgediend. Er kunnen ook andere vertragingen optreden nadat de gebruikersactiviteit stopt voordat het geheugen wordt vrijgetrokken, omdat periodieke achtergrondprocessen reageren op eerdere gebruikersactiviteit. Verwijderbewerkingen en Query Store-opschoontaken genereren bijvoorbeeld ghost-records die zijn gemarkeerd voor verwijdering, maar die niet fysiek worden verwijderd totdat het ghost-opschoningsproces wordt uitgevoerd. Voor het opschonen van een ghost moeten mogelijk extra gegevenspagina's in de cache worden gelezen.

Cache-uiting

De SQL cache groeit naarmate gegevens op dezelfde manier en met dezelfde snelheid van de schijf worden opgehaald als voor inrichtende databases. Wanneer de database bezet is, mag de cache onbeperkt omhoog worden geconstraind tot de maximale geheugenlimiet.

Automatisch onderbreken en automatisch hervat

Automatisch onderbreken

Automatisch onderbreken wordt geactiveerd als aan alle volgende voorwaarden wordt voldaan voor de duur van de vertraging voor automatisch onderbreken:

  • Aantal sessies = 0
  • CPU = 0 voor de werkbelasting van de gebruiker die wordt uitgevoerd in de gebruikersresourcegroep

Er wordt een optie geboden om automatisch onderbreken uit te schakelen, indien gewenst.

De volgende functies bieden geen ondersteuning voor automatisch onderbreken, maar bieden wel ondersteuning voor automatisch schalen. Als een van de volgende functies wordt gebruikt, moet automatisch onderbreken worden uitgeschakeld en blijft de database online, ongeacht de duur van inactiviteit van de database:

Automatisch onderbreken wordt tijdelijk voorkomen tijdens de implementatie van sommige service-updates waarvoor de database online moet zijn. In dergelijke gevallen wordt automatisch onderbreken weer toegestaan zodra de service-update is voltooid.

Problemen met automatisch onderbreken oplossen

Als automatisch onderbreken is ingeschakeld, maar een database niet automatisch wordt onderbroken na de vertragingsperiode en de bovenstaande functies niet worden gebruikt, wordt automatisch onderbreken mogelijk voorkomen door de toepassing of gebruikerssessies. Als u wilt zien of er momenteel toepassings- of gebruikerssessies zijn verbonden met de database, maakt u verbinding met de database met behulp van een clienthulpprogramma en voert u de volgende query uit:

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'
      );

Tip

Zorg ervoor dat u na het uitvoeren van de query de verbinding met de database verbreekt. Anders voorkomt de open sessie die wordt gebruikt door de query automatisch onderbreken.

Als de resultatenset niet leeg is, geeft dit aan dat er sessies zijn die automatische pauzes voorkomen.

Als de resultatenset leeg is, is het nog steeds mogelijk dat sessies open waren, mogelijk voor een korte tijd, op een bepaald moment eerder tijdens de vertragingsperiode voor automatisch onderbreken. Als u wilt zien of dergelijke activiteit heeft plaatsgevonden tijdens de vertragingsperiode, kunt u Azure SQL Auditing gebruiken en auditgegevens voor de relevante periode onderzoeken.

De aanwezigheid van open sessies, met of zonder gelijktijdig CPU-gebruik in de gebruikersresourcegroep, is de meest voorkomende reden voor een serverloze database om niet automatisch te onderbreken zoals verwacht. Houd er rekening mee dat sommige functies geen ondersteuning bieden voor automatisch onderbreken, maar wel voor automatisch schalen.

Automatisch hervat

Automatisch hervat wordt geactiveerd als een van de volgende voorwaarden op elk moment waar is:

Functie Trigger voor automatisch hervatten
Verificatie en autorisatie Aanmelden
Detectie van bedreigingen Instellingen voor detectie van bedreigingen in- of uitschakelen op database- of serverniveau.
Instellingen voor detectie van bedreigingen wijzigen op database- of serverniveau.
Gegevensdetectie en -classificatie Gevoeligheidslabels toevoegen, wijzigen, verwijderen of weergeven
Controles Controlerecords weergeven.
Controlebeleid bijwerken of weergeven.
Gegevensmaskering Regels voor gegevensmaskering toevoegen, wijzigen, verwijderen of weergeven
Transparent Data Encryption Status of status van transparante gegevensversleuteling weergeven
Evaluatie van beveiligingsproblemen Ad-hocscans en periodieke scans indien ingeschakeld
Query's uitvoeren op gegevensopslag (prestaties) Instellingen voor queryopslag wijzigen of weergeven
Aanbevelingen voor prestaties Prestatieaanbevelingen weergeven of toepassen
Automatisch afstemmen Toepassing en verificatie van aanbevelingen voor automatisch afstemmen, zoals automatisch indexeren
Database kopiëren Database maken als kopie.
Exporteren naar een BACPAC-bestand.
SQL gegevenssynchronisatie Synchronisatie tussen hub- en liddatabases die volgens een configureerbare planning worden uitgevoerd of handmatig worden uitgevoerd
Bepaalde databasemetagegevens wijzigen Nieuwe databasetags toevoegen.
Het maximum aantal vCores, min. vCores of vertraging bij automatisch onderbreken wijzigen.
SQL Server Management Studio (SSMS) Het gebruik van SSMS-versies die lager zijn dan 18.1 en het openen van een nieuw queryvenster voor elke database op de server, hervat elke automatisch onderbroken database op dezelfde server. Dit gedrag treedt niet op als u SSMS versie 18.1 of hoger gebruikt.

Bewaking, beheer of andere oplossingen die een van de hierboven vermelde bewerkingen uitvoeren, activeren automatisch hervatting.

Automatisch hervatting wordt ook geactiveerd tijdens de implementatie van een aantal service-updates waarvoor de database online moet zijn.

Connectiviteit

Als een serverloze database is onderbroken, wordt de database hervat met de eerste aanmelding en wordt een foutbericht weergegeven waarin staat dat de database niet beschikbaar is met foutcode 40613. Zodra de database is hervat, moet de aanmelding opnieuw worden proberen om verbinding te maken. Database-clients met verbindingslogica voor opnieuw proberen hoeven niet te worden gewijzigd.

Latentie

De latentie voor het automatisch hervatten en automatisch onderbreken van een serverloze database is doorgaans 1 minuut om automatisch te worden hervat en 1-10 minuten na het verstrijken van de vertragingsperiode voor automatisch onderbreken.

Door de klant beheerde transparante gegevensversleuteling (BYOK)

Als het gebruik van door de klant beheerde transparante gegevensversleuteling (BYOK) en de serverloze database automatisch wordt onderbroken wanneer de sleutel wordt verwijderd of intrekken, blijft de database in de status Automatisch onderbroken. In dit geval wordt de database na de volgende hervatting binnen ongeveer tien minuten ontoegankelijk. Zodra de database niet meer toegankelijk is, is het herstelproces hetzelfde als voor inrichtende rekendatabases. Als de serverloze database online is wanneer er sleutels worden verwijderd of intrekken, is de database ook binnen ongeveer tien minuten niet toegankelijk op dezelfde manier als bij inrichtende rekendatabases.

Onboarding in serverloze rekenlaag

Het maken van een nieuwe database of het verplaatsen van een bestaande database naar een serverloze rekenlaag volgt hetzelfde patroon als het maken van een nieuwe database in de inrichtende rekenlaag en omvat de volgende twee stappen.

  1. Geef de servicedoelstelling op. De servicedoelstelling staat voor de servicelaag, het genereren van hardware en het maximum aantal vCores. Zie Serverloze resourcelimieten voor opties voor servicedoelstelling

  2. Geef desgewenst de min. vCores en vertraging voor automatisch onderbreken op om de standaardwaarden te wijzigen. In de volgende tabel ziet u de beschikbare waarden voor deze parameters.

    Parameter Waardeopties Standaardwaarde
    Minimum aantal vCores Is afhankelijk van het maximum aantal vCores dat is geconfigureerd. Zie resourcelimieten. 0,5 vCores
    Vertraging bij automatisch gebruik Minimaal: 60 minuten (1 uur)
    Maximum: 10080 minuten (7 dagen)
    Verhogingen: 10 minuten
    Automatisch gebruik uitschakelen: -1
    60 minuten

Een nieuwe database maken in de serverloze rekenlaag

In de volgende voorbeelden wordt een nieuwe database gemaakt in de serverloze rekenlaag.

Azure Portal gebruiken

Zie Quickstart: Een individuele database maken in Azure SQL Database met behulp van de Azure Portal.

PowerShell gebruiken

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

Azure CLI gebruiken

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

Transact-SQL (T-SQL) gebruiken

Wanneer u T-SQL, worden standaardwaarden toegepast voor de min. vcores en vertraging bij automatisch gebruik. Ze kunnen later worden gewijzigd vanuit de portal of via andere beheer-API's (PowerShell, Azure CLI, REST API).

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

Zie CREATE DATABASE voor meer informatie.

Een database verplaatsen van de inrichtende rekenlaag naar de serverloze rekenlaag

In de volgende voorbeelden wordt een database verplaatst van de inrichtende rekenlaag naar de serverloze rekenlaag.

PowerShell gebruiken

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

Azure CLI gebruiken

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

Transact-SQL (T-SQL) gebruiken

Wanneer u T-SQL, worden standaardwaarden toegepast voor de min. vcores en vertraging bij automatisch onderbreken. Ze kunnen later worden gewijzigd vanuit de portal of via andere beheer-API's (PowerShell, Azure CLI, REST API).

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

Zie ALTER DATABASE voor meer informatie.

Een database verplaatsen van de serverloze rekenlaag naar de inrichtende rekenlaag

Een serverloze database kan op dezelfde manier worden verplaatst naar een inrichtende rekenlaag als een inrichtende rekendatabase naar een serverloze rekenlaag.

Serverloze configuratie wijzigen

PowerShell gebruiken

Het wijzigen van de maximale of minimale vCores en de vertraging bij automatisch gebruik wordt uitgevoerd met behulp van de opdracht Set-AzSqlDatabase in PowerShell met behulp van de argumenten MaxVcore , en MinVcore AutoPauseDelayInMinutes .

Azure CLI gebruiken

Het wijzigen van de maximale of minimale vCores en de vertraging voor automatisch gebruik wordt uitgevoerd met behulp van de opdracht az sql db update in Azure CLI met behulp van de argumenten , en capacity min-capacity auto-pause-delay .

Bewaking

Gebruikte en gefactureerde resources

De resources van een serverloze database worden ingekapseld door app-pakket, SQL-exemplaar en gebruikersresourcegroepentiteiten.

App-pakket

Het app-pakket is de buitenste bronbeheergrens voor een database, ongeacht of de database zich in een serverloze of inrichtende rekenlaag heeft. Het app-pakket bevat het SQL-exemplaar en externe services, zoals Zoeken in volledige tekst, die samen het bereik hebben van alle gebruikers- en systeembronnen die worden gebruikt door een database in SQL Database. De SQL over het algemeen het algehele resourcegebruik in het app-pakket.

Gebruikersresourcegroep

De gebruikersresourcegroep is een interne resourcebeheergrens voor een database, ongeacht of de database zich in een serverloze of inrichtende rekenlaag heeft. De resourcegroep van de gebruiker scopes CPU en IO voor de werkbelasting van de gebruiker gegenereerd door DDL-query's zoals MAKEN en ALTER, DML-query's zoals INSERT, UPDATE, DELETE en MERGE, en SELECT-query's. Deze query's vertegenwoordigen over het algemeen het grootste aandeel van het gebruik binnen het app-pakket.

Metrische gegevens

Metrische gegevens voor het bewaken van het resourcegebruik van het app-pakket en de gebruikersresourcegroep van een serverloze database worden vermeld in de volgende tabel:

Entiteit Metrisch Beschrijving Eenheden
App-pakket app_cpu_percent Het percentage vCores dat door de app wordt gebruikt ten opzichte van het maximum aantal vCores dat is toegestaan voor de app. Percentage
App-pakket app_cpu_billed De hoeveelheid rekenkracht die voor de app wordt gefactureerd tijdens de rapportageperiode. Het bedrag dat tijdens deze periode wordt betaald, is het product van deze metrische gegevens en de prijs van de vCore-eenheid.

De waarden van deze metrische gegevens worden bepaald door de maximale cpu die wordt gebruikt en het geheugen dat elke seconde wordt gebruikt, in de tijd samen te stellen. Als de gebruikte hoeveelheid kleiner is dan de minimale hoeveelheid die is ingericht zoals ingesteld door de minimale vCores en het minimale geheugen, wordt de minimale hoeveelheid die is ingericht, gefactureerd.Als u CPU wilt vergelijken met geheugen voor factureringsdoeleinden, wordt het geheugen genormaliseerd in eenheden van vCores door de hoeveelheid geheugen in GB met 3 GB per vCore te schalen.
vCore-seconden
App-pakket app_memory_percent Percentage geheugen dat door de app wordt gebruikt ten opzichte van het maximale geheugen dat is toegestaan voor de app. Percentage
Gebruikersresourcegroep cpu_percent Het percentage vCores dat wordt gebruikt door de werkbelasting van de gebruiker ten opzichte van het maximum aantal vCores dat is toegestaan voor de werkbelasting van de gebruiker. Percentage
Gebruikersresourcegroep data_IO_percent Het percentage gegevens-IOPS dat wordt gebruikt door de werkbelasting van de gebruiker ten opzichte van het maximum aantal toegestane gegevens-IOPS voor gebruikersworkloads. Percentage
Gebruikersresourcegroep log_IO_percent Percentage logboek-MB/s dat wordt gebruikt door de werkbelasting van de gebruiker ten opzichte van het maximum aantal logboek-MB/s dat is toegestaan voor de werkbelasting van de gebruiker. Percentage
Gebruikersresourcegroep workers_percent Het percentage werkbelastingen dat wordt gebruikt door de werkbelasting van gebruikers ten opzichte van het maximum aantal werkbelastingen dat is toegestaan voor gebruikers. Percentage
Gebruikersresourcegroep sessions_percent Het percentage sessies dat wordt gebruikt door de werkbelasting van de gebruiker ten opzichte van het maximum aantal sessies dat is toegestaan voor de werkbelasting van de gebruiker. Percentage

Status onderbreken en hervatten

In de Azure Portal wordt de databasestatus weergegeven in het overzichtsvenster van de server met de databases die deze bevat. De databasestatus wordt ook weergegeven in het overzichtsvenster voor de database.

Gebruik de volgende opdrachten om de status van een database onderbreken en hervatten op te vragen:

PowerShell gebruiken

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

Azure CLI gebruiken

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

Bronlimieten

Zie Serverloze rekenlaag voor resourcelimieten.

Billing

De hoeveelheid rekenkracht die wordt gefactureerd, is de maximale cpu die wordt gebruikt en het geheugen dat elke seconde wordt gebruikt. Als de gebruikte hoeveelheid CPU en het gebruikte geheugen kleiner is dan de minimale hoeveelheid die voor elk cpu-gebruik is ingericht, wordt het inrichtende bedrag gefactureerd. Als u CPU wilt vergelijken met geheugen voor factureringsdoeleinden, wordt het geheugen genormaliseerd in eenheden van vCores door de hoeveelheid geheugen in GB met 3 GB per vCore te schalen.

  • Gefactureerde resource: CPU en geheugen
  • Gefactureerd bedrag: prijs per vCore * max (min. vCores, gebruikte vCores, min. geheugen GB * 1/3, geheugen GB gebruikt * 1/3)
  • Factureringsfrequentie: per seconde

De prijs per vCore-eenheid is de kosten per vCore per seconde. Raadpleeg de pagina Azure SQL Database voor specifieke eenheidsprijzen in een bepaalde regio.

De hoeveelheid gefactureerde rekenkracht wordt blootgesteld aan de volgende metrische gegevens:

  • Metrische gegevens: app_cpu_billed (vCore-seconden)
  • Definitie: max (min. vCores, gebruikte vCores, min. geheugen GB * 1/3, geheugen GB gebruikt * 1/3)
  • Rapportagefrequentie: per minuut

Deze hoeveelheid wordt elke seconde berekend en samengevoegd in meer dan 1 minuut.

Minimale rekenrekening

Als een serverloze database wordt onderbroken, is de rekenrekening nul. Als een serverloze database niet is onderbroken, is de minimale rekenrekening niet lager dan de hoeveelheid vCores op basis van het maximum (min. vCores, min. geheugen GB * 1/3).

Voorbeelden:

  • Stel dat een serverloze database niet is onderbroken en geconfigureerd met maximaal 8 vCores en 1 min. vCores die overeenkomen met 3,0 GB min. geheugen. Vervolgens is de minimale rekenrekening gebaseerd op het maximum (1 vCore, 3,0 GB * 1 vCore / 3 GB) = 1 vCore.
  • Stel dat een serverloze database niet is onderbroken en geconfigureerd met maximaal 4 vCores en 0,5 min. vCores die overeenkomen met 2,1 GB geheugen. Vervolgens wordt de minimale rekenrekening gebaseerd op het maximum (0,5 vCores, 2,1 GB * 1 vCore / 3 GB) = 0,7 vCores.

De Azure SQL Database prijscalculator voor serverloos kan worden gebruikt om het minimum aantal te configureren geheugen te bepalen op basis van het aantal maximaal en minimum aantal vCores dat is geconfigureerd. Als de geconfigureerde minimale vCores groter is dan 0,5 vCores, is de minimale rekenrekening onafhankelijk van het minimale geheugen dat is geconfigureerd en alleen gebaseerd op het aantal geconfigureerde minimale vCores.

Voorbeeldscenario

Overweeg een serverloze database die is geconfigureerd met 1 min. vCore en maximaal 4 vCores. Dit komt overeen met ongeveer 3 GB min. geheugen en maximaal 12 GB geheugen. Stel dat de vertraging voor automatisch onderbreken is ingesteld op 6 uur en dat de databaseworkload actief is gedurende de eerste 2 uur van een periode van 24 uur en anderszins inactief is.

In dit geval wordt de database in de eerste 8 uur gefactureerd voor reken- en opslagcapaciteit. Hoewel de database inactief is vanaf het tweede uur, wordt deze in de volgende zes uur nog steeds gefactureerd voor rekenkracht op basis van de minimale rekencapaciteit die is ingericht terwijl de database online is. Alleen opslag wordt gefactureerd gedurende de rest van de periode van 24 uur terwijl de database wordt onderbroken.

Om precies te zijn, wordt de rekenrekening in dit voorbeeld als volgt berekend:

Tijdsinterval vCores die elke seconde worden gebruikt GB die elke seconde wordt gebruikt Rekendimensie gefactureerd vCore-seconden gefactureerd gedurende een tijdsinterval
0:00-1:00 4 9 vCores gebruikt 4 vCores * 3600 seconden = 14400 vCore-seconden
1:00-2:00 1 12 Gebruikt geheugen 12 GB * 1/3 * 3600 seconden = 14400 vCore-seconden
2:00-8:00 0 0 Min. geheugen ingericht 3 GB * 1/3 * 21600 seconden = 21600 vCore-seconden
8:00-24:00 0 0 Er wordt geen rekenkracht gefactureerd terwijl deze is onderbroken 0 vCore-seconden
Totaal aantal vCore-seconden gefactureerd gedurende 24 uur 50400 vCore-seconden

Stel dat de prijs van de rekeneenheid $ 0,000145/vCore/seconde is. De berekening die wordt gefactureerd voor deze periode van 24 uur is het product van de prijs van de rekeneenheid en de vCore-seconden die worden gefactureerd: $ 0,000145/vCore/seconde * 50400 vCore-seconden ~ $ 7,31.

Azure Hybrid Benefit en gereserveerde capaciteit

Azure Hybrid Benefit (AHB) en kortingen voor gereserveerde capaciteit zijn niet van toepassing op de serverloze rekenlaag.

Beschikbare regio's

De serverloze rekenlaag is wereldwijd beschikbaar, met uitzondering van de volgende regio's: China - oost, China - noord, Duitsland - centraal, Duitsland - noordoost en US Gov Central (Iowa).

Volgende stappen