Laag berekening zonder server voor Azure SQL-database

  • Artikel

Van toepassing op: Azure SQL Database

Serverloos is een rekenlaag voor individuele databases in Azure SQL Database die automatisch rekenkracht schaalt op basis van de vraag naar werkbelasting en facturen voor 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. De serverloze rekenlaag is beschikbaar in de servicelaag Algemeen gebruik en de Hyperscale-servicelaag .

Notitie

Automatisch onderbreken en automatisch hervatten wordt momenteel alleen ondersteund in de servicelaag Algemeen gebruik.

Overzicht

Een bereik voor automatisch schalen van berekeningen en een vertraging bij automatisch onderbreken zijn belangrijke parameters voor de serverloze rekenlaag. De configuratie van deze parameters vormen de prestaties van de database en de rekenkosten.

Diagram indicating when serverless billing would stop incurring compute charges due to inactivity.

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 evenredig 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 minimum- en maximumlimieten die zijn geconfigureerd, zijn de rekenkosten gebaseerd op vCore en het gebruikte geheugen.
  • Wanneer het rekengebruik lager is dan de minimumlimieten die zijn geconfigureerd, zijn de rekenkosten gebaseerd op de minimale 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 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 voor individuele databases of meerdere databases in elastische pools met een hoger gemiddeld gebruik dat geen vertraging kan bieden bij het opwarmen 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 grootte van berekeningen moeilijk of niet mogelijk is om te schatten vóór de implementatie in een Azure SQL Database.

Scenario's die geschikt zijn voor ingerichte berekeningen

  • Individuele databases met meer reguliere, 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.

Rekenlagen vergelijken

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

Serverloze compute Ingerichte rekenkracht
Patroon 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 Lower Hoger
Rekenkracht schalen Automatisch Handmatig
Reactiesnelheid berekenen Lager na inactieve perioden Direct
Factureringsgranulariteit Per seconde Per uur

Aankoopmodel en servicelaag

In de volgende tabel wordt serverloze ondersteuning beschreven op basis van aankoopmodel, servicelagen en hardware:

Categorie Ondersteund Niet ondersteund
Aankoopmodel vCore DTU
Servicelaag Algemeen doel
Hyperscale		 Bedrijfskritiek
Hardware Standard-serie (Gen5) Alle andere hardware

Automatisch schalen

Reactiesnelheid schalen

Serverloze databases worden uitgevoerd op een machine met voldoende capaciteit om te voldoen aan de vraag naar resources zonder onderbreking voor elke hoeveelheid rekenkracht die is aangevraagd binnen de limieten die zijn ingesteld door de maximale vCores-waarde. Soms treedt taakverdeling automatisch op als de machine binnen een paar minuten niet aan de vraag van resources kan voldoen. Als de vraag naar resources bijvoorbeeld 4 vCores is, maar er slechts 2 vCores beschikbaar zijn, kan het enkele minuten duren voordat er 4 vCores worden geleverd. De database blijft online tijdens taakverdeling, met uitzondering van een korte periode aan het einde van de bewerking wanneer verbindingen worden verbroken.

Geheugenbeheer

In zowel de servicelagen Algemeen gebruik als Hyperscale wordt geheugen voor serverloze databases 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 uit de SQL-cache vrijgemaakt van een serverloze database wanneer het CPU- of actieve cachegebruik laag is.

  • Actief cachegebruik wordt beschouwd als laag wanneer de totale grootte van de laatst 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.

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 als gevolg van periodieke achtergrondprocessen die reageren op eerdere gebruikersactiviteit. Verwijderbewerkingen en opschoningstaken van Query Store genereren bijvoorbeeld ghostrecords die zijn gemarkeerd voor verwijdering, maar die niet fysiek worden verwijderd totdat het ghost-opschoonproces wordt uitgevoerd. Het opschonen van geesten kan betrekking hebben op het lezen van gegevenspagina's in de cache.

Cache-hydratatie

De SQL-geheugencache 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 onconstraind worden terwijl er geheugen beschikbaar is.

Beheer van schijfcache

In de Hyperscale-servicelaag voor zowel serverloze als ingerichte rekenlagen maakt elke rekenreplica gebruik van een RBPEX-cache (Resilient Buffer Pool Extension), waarin gegevenspagina's op lokale SSD worden opgeslagen om io-prestaties te verbeteren. In de serverloze rekenlaag voor Hyperscale groeit de RBPEX-cache voor elke rekenreplica automatisch en verkleint deze als reactie op toenemende en afnemende workloadvraag. De maximale grootte van de RBPEX-cache kan toenemen tot drie keer het maximale geheugen dat voor de database is geconfigureerd. Zie serverloze Hyperscale-resourcelimieten voor meer informatie over maximale geheugen- en RBPEX-limieten voor automatisch schalen in serverloze servers.

Automatisch onderbreken en automatisch hervatten

Op dit moment worden serverloze automatische onderbrekingen en automatisch hervatten alleen ondersteund in de laag Algemeen gebruik.

Automatisch onderbreken

Automatisch onderbreken wordt geactiveerd als aan alle volgende voorwaarden wordt voldaan tijdens 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 inactiviteit van de database:

  • Geo-replicatie (actieve geo-replicatie en failovergroepen).
  • Langetermijnretentie van back-ups (LTR).
  • De synchronisatiedatabase die wordt gebruikt in SQL Data Sync. In tegenstelling tot synchronisatiedatabases ondersteunen hub- en liddatabases automatisch onderbreken.
  • DNS-alias gemaakt voor de logische server die een serverloze database bevat.
  • Elastische taken (preview), serverloze database zonder automatisch onderbreken wordt niet ondersteund als een taakdatabase. Serverloze databases waarop elastische taken zijn gericht, ondersteunen automatisch onderbreken. Taakverbindingen hervatten een 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 en functies die automatisch onderbreken blokkeren niet worden gebruikt, maar een database na de vertragingsperiode niet automatisch onderbreekt, kunnen de toepassings- of gebruikerssessies mogelijk 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 geenmpty is, geeft dit aan dat er sessies zijn die momenteel automatisch onderbreken verhinderen.
  • 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 controleren op activiteit tijdens de vertragingsperiode, kunt u Azure SQL Auditing gebruiken en controlegegevens voor de relevante periode onderzoeken.

Belangrijk

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.
Detectie en classificatie van gegevens Vertrouwelijkheidslabels toevoegen, wijzigen, verwijderen of weergeven
Controle 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 query store 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.
Maximale vCores, minimale vCores of vertraging automatisch onderbreken wijzigen.
SQL Server Management Studio (SSMS) Wanneer u SSMS-versies eerder dan 18.1 gebruikt en een nieuw queryvenster opent voor een 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 deze bewerkingen uitvoeren, triggers die automatisch worden hervat.
  • 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 aanmeldingsactiviteit en wordt een fout geretourneerd waarin staat dat de database niet beschikbaar is met foutcode 40613. Zodra de database is hervat, kan opnieuw worden geprobeerd verbinding te maken. Databaseclients met een aanbevolen logica voor opnieuw proberen van verbindingen hoeven niet te worden gewijzigd. Raadpleeg het volgende voor aanbevolen patronen voor verbindingslogica voor opnieuw proberen:

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)

Sleutelverwijdering of intrekking

Als het gebruik van door de klant beheerde transparante gegevensversleuteling (BYOK) en de serverloze database automatisch wordt onderbroken wanneer sleutelverwijdering of intrekking plaatsvindt, blijft de database de status automatisch onderbroken. In dit geval is de database na het hervatten van de database binnen ongeveer 10 minuten ontoegankelijk. Zodra de database niet toegankelijk is, is het herstelproces hetzelfde als voor ingerichte rekendatabases. Als de serverloze database online is wanneer de sleutel wordt verwijderd of ingetrokken, is de database ook binnen ongeveer 10 minuten ontoegankelijk op dezelfde manier als bij ingerichte rekendatabases.

Sleutelroulatie

Als u door de klant beheerde transparante gegevensversleuteling (BYOK) gebruikt en de serverloze database automatisch wordt onderbroken, wordt automatische sleutelrotatie uitgesteld totdat de database automatisch wordt hervat.

Een nieuwe serverloze database maken

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. In de volgende tabel ziet u de beschikbare waarden voor deze parameters.

    Parameter Waardekeuzen Default value
    Minimum vCores Is afhankelijk van de maximaal geconfigureerde vCores: zie resourcelimieten. 0.5 vCores
    Vertraging automatisch onderbreken Minimum: 60 minuten (1 uur)
    Maximum: 10.080 minuten (7 dagen)
    Stappen: 10 minuten
    Automatisch onderbreken uitschakelen: -1    		 60 minuten

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 Azure Portal.

PowerShell gebruiken

Maak een nieuwe serverloze database voor algemeen gebruik met het volgende PowerShell-voorbeeld:

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

Azure CLI gebruiken

Maak een nieuwe serverloze database voor algemeen gebruik met het volgende Azure CLI-voorbeeld:

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

Transact-SQL (T-SQL) gebruiken

Wanneer u T-SQL gebruikt om een nieuwe serverloze database te maken, worden standaardwaarden toegepast voor de minimale vCores en vertraging bij automatisch onderbreken. Ze kunnen later worden gewijzigd vanuit Azure Portal of via andere beheer-API's (PowerShell, Azure CLI, REST API).

Zie CREATE DATABASE voor meer informatie.

Maak een nieuwe serverloze database voor algemeen gebruik met het volgende T-SQL-voorbeeld:

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

Een database verplaatsen tussen rekenlagen

Het is mogelijk om uw database te verplaatsen van de ingerichte rekenlaag naar de serverloze rekenlaag en weer terug.

Notitie

Het is ook mogelijk om uw database in de laag Algemeen gebruik te upgraden naar de Hyperscale-laag. Raadpleeg Hyperscale-databases beheren voor meer informatie.

Wanneer u uw database verplaatst tussen rekenlagen, geeft u de parameter Compute-model op als of ProvisionedServerless wanneer u PowerShell en de Azure CLI gebruikt, en de rekengrootte voor de SERVICE_OBJECTIVE wanneer u T-SQL gebruikt. Bekijk resourcelimieten om de juiste rekenkracht te identificeren.

In de voorbeelden in deze sectie ziet u hoe u uw ingerichte database verplaatst naar serverloos. Wijzig de servicedoelstelling indien nodig, omdat in deze voorbeelden het maximum aantal vCores is ingesteld op 4.

PowerShell gebruiken

Verplaats een ingerichte rekendatabase algemeen gebruik naar de serverloze rekenlaag met het volgende PowerShell-voorbeeld:

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

Azure CLI gebruiken

Verplaats een ingerichte database voor algemeen gebruik naar de serverloze rekenlaag met het volgende Azure CLI-voorbeeld:

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

Transact-SQL (T-SQL) gebruiken

Wanneer u T-SQL gebruikt om een database tussen rekenlagen te verplaatsen, worden standaardwaarden toegepast voor de minimale vCores en vertraging bij automatisch onderbreken. Ze kunnen later worden gewijzigd vanuit Azure Portal of via andere beheer-API's (PowerShell, Azure CLI, REST API). Zie ALTER DATABASE voor meer informatie.

Verplaats een ingerichte rekendatabase algemeen gebruik naar de serverloze rekenlaag met het volgende T-SQL-voorbeeld:

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

Serverloze configuratie wijzigen

PowerShell gebruiken

Gebruik Set-AzSqlDatabase om de maximale of minimale vCores te wijzigen en vertraging automatisch te onderbreken. Gebruik de MaxVcore, MinVcoreen AutoPauseDelayInMinutes argumenten. Serverloze automatische onderbreking wordt momenteel niet ondersteund in de Hyperscale-laag, dus het argument vertraging automatisch onderbreken is alleen van toepassing op de laag Algemeen gebruik.

Azure CLI gebruiken

Gebruik az sql db update om de maximale of minimale vCores te wijzigen en de vertraging automatisch te onderbreken. Gebruik de capacity, min-capacityen auto-pause-delay argumenten. Serverloze automatische onderbreking wordt momenteel niet ondersteund in de Hyperscale-laag, dus het argument vertraging automatisch onderbreken is alleen van toepassing op de laag Algemeen gebruik.

Bijhouden

Gebruikte en gefactureerde resources

De resources van een serverloze database omvatten het app-pakket, het SQL-exemplaar en de entiteiten van de gebruikersresourcegroep.

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, waarbij alle gebruikers- en systeembronnen die door een database in SQL Database worden gebruikt, worden beperkt. Het SQL-exemplaar over het algemeen overheerst het totale resourcegebruik in het app-pakket.

Gebruikersresourcegroep

De gebruikersresourcegroep is een binnenste resourcebeheergrens voor een database, ongeacht of de database zich in een serverloze of ingerichte rekenlaag bevindt. De gebruikersresourcegroep scopes CPU en IO voor gebruikersworkloads die zijn gegenereerd door DDL-query's (CREATE en ALTER) en DML (INSERT, UPDATE, DELETE en MERGE en SELECT). Deze query's vertegenwoordigen over het algemeen het grootste deel van het gebruik binnen het app-pakket.

Metrische gegevens voor

De volgende tabel bevat metrische gegevens voor het bewaken van het resourcegebruik van het app-pakket en de gebruikersresourcegroep van een serverloze database, inclusief geo-replica's:

Entity 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. Voor serverloze Hyperscale wordt deze metrische waarde weergegeven voor alle primaire replica's, benoemde replica's en geo-replica's. Percentage
App-pakket app_cpu_billed Het rekenbedrag dat tijdens de rapportageperiode wordt gefactureerd voor de app. Het bedrag dat tijdens deze periode wordt betaald, is het product van deze metrische waarde en de prijs van de vCore-eenheid.

De waarden van deze metrische waarde worden bepaald door het maximum aantal gebruikte CPU's en het geheugen dat elke seconde wordt gebruikt. Als de gebruikte hoeveelheid kleiner is dan de minimale hoeveelheid die is ingericht op basis van de minimale vCores en het minimale geheugen, wordt het ingerichte minimumbedrag 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. Voor serverloze Hyperscale wordt deze metrische waarde weergegeven voor de primaire replica en eventuele benoemde replica's.		 vCore seconden
App-pakket app_cpu_billed_HA_replicas Alleen van toepassing op serverloze Hyperscale. De som van de berekening die in rekening wordt gebracht voor alle apps voor HA-replica's tijdens de rapportageperiode. Deze som is gericht op de HA-replica's die behoren tot de primaire replica of de HA-replica's die behoren tot een bepaalde benoemde replica. Voordat u deze som over ha-replica's berekent, wordt de hoeveelheid berekend die wordt gefactureerd voor een afzonderlijke HA-replica op dezelfde manier als voor de primaire replica of een benoemde replica. Voor serverloze Hyperscale wordt deze metrische waarde weergegeven voor alle primaire replica's, benoemde replica's en geo-replica's. Het bedrag dat tijdens de rapportageperiode is betaald, is het product van deze metrische waarde en de prijs van de vCore-eenheid. 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. Voor serverloze Hyperscale wordt deze metrische waarde weergegeven voor alle primaire replica's, benoemde replica's en geo-replica's. 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 gebruikersworkload ten opzichte van de maximale gegevens-IOPS die zijn toegestaan voor de gebruikersworkload. Percentage
Gebruikersresourcegroep log_IO_percent Percentage logboek MB/s dat wordt gebruikt door gebruikersworkload ten opzichte van het maximum aantal logboek-MB/s dat is toegestaan voor de gebruikersworkload. Percentage
Gebruikersresourcegroep workers_percent Percentage werknemers dat wordt gebruikt door de gebruikersworkload ten opzichte van het maximum aantal werknemers dat is toegestaan voor de gebruikersworkload. Percentage
Gebruikersresourcegroep sessions_percent Percentage sessies dat wordt gebruikt door gebruikersworkload ten opzichte van het maximum aantal sessies dat is toegestaan voor de gebruikersworkload. Percentage

Status onderbreken en hervatten

In 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 voor een serverloze database is het maximum van de GEBRUIKTE CPU en het geheugen dat elke seconde wordt gebruikt. Als de gebruikte hoeveelheid CPU en geheugen kleiner is dan de minimale hoeveelheid die voor elke resource is ingericht, wordt het ingerichte bedrag gefactureerd. Om cpu te vergelijken met geheugen voor factureringsdoeleinden, wordt het geheugen genormaliseerd in eenheden van vCores door het aantal GB met 3 GB per vCore te vergroten.

  • Gefactureerde resource: CPU en geheugen
  • Gefactureerd bedrag: prijs van vCore-eenheid * maximum (minimum vCores, gebruikte vCores, minimumgeheugen GB * 1/3, geheugen GB gebruikt * 1/3)
  • Factureringsfrequentie: per seconde

De prijs per vCore-eenheid is de kosten per vCore per seconde. Voor Hyperscale is de prijs van de vCore-eenheid voor een HA-replica of benoemde replica lager dan voor de primaire replica.

Raadpleeg de pagina met prijzen voor Azure SQL Database voor specifieke eenheidsprijzen in een bepaalde regio.

De hoeveelheid rekenkracht die in serverloos wordt gefactureerd voor een database voor algemeen gebruik, of een primaire of benoemde Hyperscale-replica wordt weergegeven met de volgende metrische gegevens:

  • Metrische gegevens: app_cpu_billed (vCore seconden)
  • Definitie: maximum (minimaal vCores, gebruikte vCores, minimumgeheugen GB * 1/3, gebruikte geheugen-GB * 1/3)
  • Rapportagefrequentie: Per minuut op basis van metingen per seconde geaggregeerd over 1 minuut.

De hoeveelheid rekenkracht die wordt gefactureerd in serverloos voor Hyperscale HA-replica's die behoren tot de primaire replica of een benoemde replica, wordt weergegeven met de volgende metrische gegevens:

  • Metrische waarde: app_cpu_billed_HA_replicas (vCore seconden)
  • Definitie: Som van maximum (minimale vCores, gebruikte vCores, minimumgeheugen GB * 1/3, geheugen GB gebruikt * 1/3) voor alle HA-replica's die behoren tot hun bovenliggende resource.
  • Bovenliggende resource en eindpunt voor metrische gegevens: de primaire replica en elke benoemde replica maken elk afzonderlijk deze meting van deze metrische waarde, waarmee de berekening wordt berekend voor alle gekoppelde HA-replica's.
  • Rapportagefrequentie: Per minuut op basis van metingen per seconde geaggregeerd over 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 maximum (minimale vCores, minimumgeheugen GB * 1/3).

Voorbeelden:

  • Stel dat een serverloze database in de laag Algemeen gebruik niet wordt onderbroken en geconfigureerd met 8 maximale vCores en 1 minimale vCore die overeenkomt met minimaal 3,0 GB geheugen. Vervolgens is de minimale rekenfactuur gebaseerd op maximum (1 vCore, 3,0 GB * 1 vCore / 3 GB) = 1 vCore.
  • Stel dat een serverloze database in de laag Algemeen gebruik niet is onderbroken en geconfigureerd met 4 maximale vCores en 0,5 minimale vCores die overeenkomen met minimaal 2,1 GB geheugen. De minimale rekenfactuur is gebaseerd op maximum (0,5 vCores, 2,1 GB * 1 vCore / 3 GB) = 0,7 vCores.
  • Stel dat een serverloze database in de Hyperscale-laag een primaire replica heeft met één ha-replica en één benoemde replica zonder hoge beschikbaarheidsreplica's. Stel dat elke replica is geconfigureerd met 8 maximale vCores en 1 minimale vCore die overeenkomt met minimaal 3 GB geheugen. Vervolgens zijn de minimale rekenfactuur voor de primaire replica, HA-replica en benoemde replica elk gebaseerd op maximum (1 vCore, 3 GB * 1 vCore / 3 GB) = 1 vCore.

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

Scenariovoorbeelden

Overweeg een serverloze database in de laag Algemeen gebruik die is geconfigureerd met minimaal 1 vCore en 4 maximale vCores. Deze configuratie komt overeen met ongeveer 3 GB minimumgeheugen en 12 GB maximumgeheugen. 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 is.

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 6 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 is onderbroken.

Meer precies wordt de rekenfactuur in dit voorbeeld als volgt berekend:

Tijdsinterval vCores die elke seconde worden gebruikt GB gebruikt elke seconde Gefactureerde rekendimensie vCore seconden gefactureerd na verloop van 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 worden geen berekeningen gefactureerd terwijl deze zijn onderbroken 0 vCore seconden
Totaal aantal vCore-seconden dat meer dan 24 uur in rekening is gebracht 50.400 vCore seconden

Stel dat de prijs van de rekeneenheid $ 0,000145/vCore/seconde is. De berekening die voor deze periode van 24 uur wordt gefactureerd, is het product van de prijs van de rekeneenheid en 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

Serverloos voor de lagen Algemeen gebruik en Hyperscale met ondersteuning voor maximaal 40 maximaal 40 vCores is wereldwijd beschikbaar, met uitzondering van de volgende regio's:

  • China - oost
  • China - noord
  • Duitsland - centraal
  • Duitsland - noordoost
  • US Gov - centraal (Iowa)

Regio's die maximaal 80 vCores ondersteunen zonder beschikbaarheidszones voor Algemeen gebruik en Hyperscale

Momenteel worden maximaal 80 vCores in serverloze lagen voor algemeen gebruik en Hyperscale momenteel ondersteund in de volgende regio's:

  • Australië - oost
  • Australië - zuidoost
  • Brazilië - zuid
  • Canada - midden
  • Central US
  • Azië - oost
  • VS - oost
  • VS - oost 2
  • Frankrijk - centraal
  • Frankrijk - zuid
  • Duitsland - west-centraal
  • India - centraal
  • India - zuid
  • Japan - oost
  • Japan - west
  • VS - noord-centraal
  • Europa - noord
  • Noorwegen - oost
  • Qatar - centraal
  • Zuid-Afrika - noord
  • VS - zuid-centraal
  • Zwitserland - noord
  • Verenigd Koninkrijk Zuid
  • Verenigd Koninkrijk West
  • Europa -west
  • VS - west-centraal
  • VS - west
  • VS - west 2
  • US - west 3

Regio's die maximaal 80 vCores ondersteunen met beschikbaarheidszones voor algemeen gebruik

Momenteel worden maximaal 80 vCores met ondersteuning voor beschikbaarheidszones in serverloos voor de laag Algemeen gebruik geboden in de volgende regio's met geplande meer regio's:

  • VS - oost
  • Europa - noord
  • Europa -west
  • VS - west 2

Regio's die maximaal 80 vCores ondersteunen met beschikbaarheidszones voor Hyperscale

Op dit moment worden maximaal 80 vCores met ondersteuning voor beschikbaarheidszones in serverloos geboden voor de Hyperscale-laag in de volgende regio's waarvoor meer regio's zijn gepland:

  • Central US
  • VS - oost
  • Europa - noord
  • Europa -west
  • VS - west 2
  • US - west 3

Gerelateerde inhoud