Azure SQL Database-server

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 automatische schaalaanpassing van berekeningen en een vertraging voor automatisch onderbreken. De configuratie van deze parameters vormt de prestaties van de database en de rekenkosten.

serverless billing

Prestatieconfiguratie

  • De minimale vCores en maximale vCores zijn configureerbare parameters waarmee het bereik van de rekencapaciteit wordt gedefinieerd dat beschikbaar is voor de database. Geheugen- en IO-limieten zijn proportioneel met het opgegeven vCore-bereik. 
  • De vertraging voor automatisch onderbreken is een configureerbare parameter waarmee de periode wordt gedefinieerd waarop de database inactief moet zijn voordat deze automatisch wordt onderbroken. De database wordt automatisch hervat wanneer de volgende aanmelding of andere activiteit plaatsvindt. U kunt ook automatisch onderbreken uitschakelen.

Kosten

  • De kosten voor een serverloze database zijn de som van de rekenkosten en opslagkosten.
  • Wanneer het rekengebruik ligt tussen de minimale en maximale limieten die zijn geconfigureerd, zijn de rekenkosten gebaseerd op vCore en het gebruikte geheugen.
  • Wanneer het rekengebruik lager is dan de minimale limieten die zijn geconfigureerd, zijn de rekenkosten gebaseerd op de minimale vCores en het minimale geheugen dat is geconfigureerd.
  • Wanneer de database wordt onderbroken, zijn de rekenkosten nul en worden alleen opslagkosten gemaakt.
  • De opslagkosten worden op dezelfde manier bepaald als in de ingerichte 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 berekeningen

  • Individuele databases met onregelmatige, onvoorspelbare gebruikspatronen, afgewisseld met periodes van inactiviteit en een lager gemiddeld rekengebruik na verloop van tijd.
  • Individuele databases in de ingerichte rekenlaag die regelmatig opnieuw worden geschaald en klanten die het opnieuw schalen liever aan de service overlaten.
  • Nieuwe individuele databases zonder gebruiksgeschiedenis waarbij de rekengrootte moeilijk of niet mogelijk is om te schatten vóór de implementatie in SQL Database.

Scenario's die geschikt zijn voor ingerichte berekeningen

  • Individuele databases met meer regelmatige, voorspelbare gebruikspatronen en een hoger gemiddeld rekengebruik in de loop van de tijd.
  • Databases die de prestaties niet kunnen tolereren als gevolg van frequentere geheugenbeperkingen of vertragingen bij het hervatten van een onderbroken status.
  • Meerdere databases met onregelmatige, onvoorspelbare gebruikspatronen die kunnen worden samengevoegd in elastische pools voor betere optimalisatie van prijsprestaties.

Vergelijking met ingerichte rekenlaag

De volgende tabel bevat een overzicht van onderscheid tussen de serverloze rekenlaag en de ingerichte rekenlaag:

Serverloze compute Ingerichte rekenkracht
Patroon voor databasegebruik Onregelmatig, onvoorspelbaar gebruik met een lager gemiddeld rekengebruik in de loop van de tijd. Meer reguliere gebruikspatronen met een hoger gemiddeld rekengebruik in de loop van de tijd of meerdere databases met behulp van elastische pools.
Inspanning voor prestatiebeheer Lager Hoger
Rekenschaal Automatisch Handmatig
Reactiesnelheid berekenen Lager na inactieve perioden Direct
Granulariteit van facturering Per seconde Per uur

Aankoopmodel en servicelaag

SQL Database serverloos wordt momenteel alleen ondersteund in de laag 'Algemeen gebruik' 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 voor een 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 niet binnen een paar minuten aan de vraag naar resources kan voldoen. Als de resourcevraag bijvoorbeeld 4 vCores is, maar er slechts 2 vCores beschikbaar zijn, kan het enkele minuten duren voordat er 4 vCores worden opgegeven. De database blijft online tijdens taakverdeling, met uitzondering van een korte periode aan het einde van de bewerking wanneer verbindingen worden verbroken.

Geheugenbeheer

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

Cacheherstel

In tegenstelling tot ingerichte rekendatabases wordt geheugen van de SQL cache vrijgemaakt uit een serverloze database wanneer het CPU- of actieve cachegebruik laag is.

  • Actief cachegebruik wordt beschouwd als laag wanneer de totale grootte van de meest recent gebruikte cachevermeldingen gedurende een bepaalde periode onder een drempelwaarde valt.
  • Wanneer cacheherstel wordt geactiveerd, wordt de grootte van de doelcache stapsgewijs verkleind tot een fractie van de vorige grootte en wordt het vrijmaken alleen voortgezet als het gebruik laag blijft.
  • Wanneer cacheherstel plaatsvindt, is het beleid voor het selecteren van cachevermeldingen die moeten worden verwijderd hetzelfde selectiebeleid als voor ingerichte rekendatabases wanneer de geheugendruk hoog is.
  • De cachegrootte wordt nooit lager dan de minimale geheugenlimiet zoals gedefinieerd door minimale vCores, die kunnen worden geconfigureerd.

In zowel serverloze als ingerichte rekendatabases kunnen cachevermeldingen worden verwijderd als al het beschikbare geheugen wordt gebruikt.

Wanneer het CPU-gebruik laag is, kan het actieve cachegebruik hoog blijven, afhankelijk van het gebruikspatroon en geheugenherstel voorkomen. Er kunnen ook andere vertragingen optreden nadat de gebruikersactiviteit stopt voordat geheugenherstel plaatsvindt vanwege periodieke achtergrondprocessen die reageren op eerdere gebruikersactiviteit. Verwijderbewerkingen en opschoontaken voor Query Store genereren bijvoorbeeld spookrecords die zijn gemarkeerd voor verwijdering, maar niet fysiek worden verwijderd totdat het proces voor het opschonen van geesten wordt uitgevoerd. Bij het opschonen van ghosts kunnen extra gegevenspagina's in de cache worden gelezen.

Cachehydratatie

De SQL cache groeit naarmate gegevens op dezelfde manier van schijf worden opgehaald en met dezelfde snelheid als voor ingerichte databases. Wanneer de database bezet is, mag de cache niet meer worden getraind tot de maximale geheugenlimiet.

Automatisch onderbreken en automatisch hervatten

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 gebruikersworkload die wordt uitgevoerd in de resourcegroep

Er is een optie beschikbaar om automatisch onderbreken indien gewenst uit te schakelen.

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 de 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 opnieuw toegestaan zodra de service-update is voltooid.

Problemen met automatisch onderbreken oplossen

Als automatisch onderbreken is ingeschakeld, maar een database na de vertragingsperiode niet automatisch onderbreekt en de hierboven vermelde functies niet worden gebruikt, kunnen de toepassings- of gebruikerssessies automatisch onderbreken verhinderen. 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

Nadat u de query hebt uitgevoerd, moet u de verbinding met de database verbreken. Anders voorkomt de geopende sessie die door de query wordt gebruikt, 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 controlegegevens 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.

Automatisch hervatten

Automatisch hervatten wordt geactiveerd als aan een van de volgende voorwaarden wordt voldaan:

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 Vertrouwelijkheidslabels toevoegen, wijzigen, verwijderen of weergeven
Controleren Controlerecords weergeven.
Controlebeleid bijwerken of weergeven.
Gegevensmaskering Regels voor het maskeren van gegevens 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 querystore wijzigen of weergeven
Aanbevelingen voor prestaties Prestatieaanaanvelingen weergeven of toepassen
Automatisch afstemmen Toepassing en verificatie van aanbevelingen voor automatisch afstemmen, zoals automatisch indexeren
Database kopiëren Maak de database als kopie.
Exporteren naar een BACPAC-bestand.
SQL Data Sync Synchronisatie tussen hub- en liddatabases die worden uitgevoerd volgens een configureerbaar schema of handmatig worden uitgevoerd
Bepaalde databasemetagegevens wijzigen Nieuwe databasetags toevoegen.
Max. vCores, minimale vCores of vertraging bij automatisch onderbreken wijzigen.
SQL Server Management Studio (SSMS) Als u SSMS-versies gebruikt die ouder zijn dan 18.1 en een nieuw queryvenster opent voor elke database op de server, wordt elke automatisch onderbroken database op dezelfde server hervat. Dit gedrag treedt niet op als u SSMS versie 18.1 of hoger gebruikt.

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

Automatisch hervatten wordt ook geactiveerd tijdens de implementatie van sommige 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 proberen om verbinding te maken. Database-clients met verbindingslogica voor opnieuw proberen hoeven niet te worden gewijzigd. Zie configureerbare logica voor opnieuw proberen in SqlClient voor opties voor opnieuw proberen die zijn ingebouwd in het SqlClient-stuurprogramma.

Latentie

De latentie voor automatisch hervatten en automatisch onderbreken van een serverloze database is doorgaans 1 minuut tot automatisch hervatten 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 transparent data encryption (BYOK) en de serverloze database automatisch wordt onderbroken wanneer sleutelverwijdering of intrekking plaatsvindt, blijft de database in de status automatisch onderbroken. In dit geval is de database na het volgende hervatten niet meer toegankelijk binnen ongeveer 10 minuten. Zodra de database niet toegankelijk is, is het herstelproces hetzelfde als voor ingerichte rekendatabases. Als de serverloze database online is wanneer de sleutelverwijdering of intrekking plaatsvindt, is de database binnen ongeveer 10 minuten op dezelfde manier als bij ingerichte rekendatabases ontoegankelijk.

Onboarding naar 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 ingerichte rekenlaag en omvat de volgende twee stappen.

  1. Geef de servicedoelstelling op. De servicedoelstelling schrijft de servicelaag, hardwareconfiguratie en maximale vCores voor. Zie serverloze resourcelimieten voor opties voor servicedoelstelling

  2. Geef desgewenst de minimale vCores en de vertraging voor automatisch onderbreken op om de standaardwaarden te wijzigen. De volgende tabel bevat de beschikbare waarden voor deze parameters.

    Parameter Waardekeuzen Standaardwaarde
    Minimale vCores Afhankelijk van de maximaal geconfigureerde vCores- zie resourcelimieten. 0.5 vCores
    Vertraging autopause Minimum: 60 minuten (1 uur)
    Maximum: 10080 minuten (7 dagen)
    Stappen: 10 minuten
    Automatischpause 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 gebruikt, worden standaardwaarden toegepast op de minimale vcores en de vertraging van automatisch opslaan. 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 van de ingerichte rekenlaag verplaatsen naar de serverloze rekenlaag

In de volgende voorbeelden wordt een database verplaatst van de ingerichte 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 gebruikt, worden standaardwaarden toegepast voor de minimale 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 van de serverloze rekenlaag verplaatsen naar de ingerichte rekenlaag

Een serverloze database kan op dezelfde manier worden verplaatst naar een ingerichte rekenlaag als het verplaatsen van een ingerichte rekendatabase naar een serverloze rekenlaag.

Serverloze configuratie wijzigen

PowerShell gebruiken

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

Azure CLI gebruiken

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

Bewaking

Gebruikte en gefactureerde resources

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

App-pakket

Het app-pakket is de buitenste grens voor resourcebeheer voor een database, ongeacht of de database zich in een serverloze of ingerichte rekenlaag bevindt. Het app-pakket bevat het SQL exemplaar en externe services, zoals Zoeken in volledige tekst, waarmee alle gebruikers- en systeembronnen die door een database in SQL Database worden gebruikt, worden bereikt. Het SQL exemplaar over het algemeen overheerst het totale resourcegebruik in het app-pakket.

Gebruikersresourcegroep

De gebruikersresourcegroep is een binnenste grens voor resourcebeheer voor een database, ongeacht of de database zich in een serverloze of ingerichte rekenlaag bevindt. De gebruikersresourcegroep bereikt CPU en IO voor gebruikersworkloads die worden gegenereerd door DDL-query's, zoals CREATE en ALTER, DML-query's zoals INSERT, UPDATE, DELETE en MERGE, en SELECT-query's. Deze query's vertegenwoordigen over het algemeen het grootste deel 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 Het rekenbedrag dat tijdens de rapportageperiode voor de app wordt gefactureerd. Het bedrag dat tijdens deze periode wordt betaald, is het product van deze metrische waarde en de prijs van de vCore-eenheid.

Waarden van deze metrische waarde worden bepaald door het maximum aantal gebruikte CPU's en het geheugen dat elke seconde wordt gebruikt, samen te aggregatie. Als het gebruikte bedrag kleiner is dan het minimumbedrag dat is ingericht door de minimale vCores en het minimale geheugen, wordt het minimumbedrag in rekening gebracht. 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 Percentage vCores dat wordt gebruikt door de gebruikersworkload ten opzichte van het maximum aantal vCores dat is toegestaan voor de gebruikersworkload. Percentage
Gebruikersresourcegroep data_IO_percent Percentage gegevens-IOPS dat wordt gebruikt door de gebruikersworkload ten opzichte van het maximum aantal gegevens-IOPS dat is toegestaan voor de gebruikersworkload. Percentage
Gebruikersresourcegroep log_IO_percent Percentage logboek-MB/s dat wordt gebruikt door de gebruikersworkload ten opzichte van het maximale aantal logboek-MB/s dat is toegestaan voor de gebruikersworkload. Percentage
Gebruikersresourcegroep workers_percent Percentage werkrollen dat wordt gebruikt door de gebruikersworkload ten opzichte van het maximum aantal werkrollen dat is toegestaan voor de gebruikersworkload. Percentage
Gebruikersresourcegroep sessions_percent Percentage sessies dat wordt gebruikt door de gebruikersworkload ten opzichte van het maximum aantal sessies dat is toegestaan voor de gebruikersworkload. 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 onderbreken en hervatten van een database 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 de 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 van vCore-eenheid * 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 met prijzen voor Azure SQL Database voor specifieke eenheidsprijzen in een bepaalde regio.

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

  • Metrische waarde: 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 rekenfactuur

Als een serverloze database is onderbroken, is de rekenfactuur nul. Als een serverloze database niet wordt onderbroken, is de minimale rekenfactuur niet minder dan de hoeveelheid vCores op basis van max (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 vCore die overeenkomt met 3,0 GB min geheugen. Vervolgens is de minimale rekenfactuur gebaseerd op max (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 min geheugen. Vervolgens is de minimale rekenfactuur gebaseerd op max (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 minimale geheugen te bepalen dat kan worden geconfigureerd op basis van het aantal maximaal en min vCores dat is geconfigureerd. Als de minimale vCores die zijn geconfigureerd groter is dan 0,5 vCores, is de minimale rekenfactuur onafhankelijk van het minimale geheugen dat is geconfigureerd en alleen op basis van het aantal geconfigureerde minimale vCores.

Voorbeeldscenario

Overweeg een serverloze database die is geconfigureerd met 1 min vCore en 4 max vCores. Deze configuratie 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 anders inactief.

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

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

Tijdsinterval vCores gebruikt elke seconde GB gebruikt elke seconde Rekendimensie gefactureerd vCore seconden gefactureerd gedurende een tijdsinterval
0:00-1:00 4 9 gebruikte vCores 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 Minimaal geheugen ingericht 3 GB * 1/3 * 21600 seconden = 21600 vCore seconden
8:00-24:00 0 0 Er wordt geen rekenproces gefactureerd terwijl deze is onderbroken 0 vCore seconden
Totaal aantal vCore-seconden dat meer dan 24 uur in rekening is gebracht 50400 vCore seconden

Stel dat de prijs van de rekeneenheid $ 0,000145/vCore/seconde is. Vervolgens wordt voor deze periode van 24 uur het product van de prijs van de rekeneenheid en vCore seconden 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 - centraal (Iowa).

Volgende stappen