Azure SQL Database serverloos maken

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.

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 lager is dan de geconfigureerde minimumlimieten, worden de rekenkosten gebaseerd op de min. 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 voorkeur geven aan het delegeren van herschalen van rekenkracht 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:

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:

• Geo-replicatie (actieve geo-replicatie en groepen voor automatische failover).
• 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 met een serverloze database.
• Elastische taken (preview), wanneer de taakdatabase een serverloze database is. Databases die zijn gericht op elastische taken ondersteunen automatisch onderbreken en worden hervat door taakverbindingen.

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

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 hervat

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

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. Zie Configureerbare logica voor opnieuw proberen in SqlClient voor opties voor poging tot verbinding die zijn ingebouwd in het SqlClient-stuurprogramma.

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. Het app-pakket bevat de SQL-instantie en externe services, zoals Zoeken in volledige tekst, die alle gebruikers- en systeembronnen die worden gebruikt door een database in SQL Database. Het 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. De gebruikersresourcegroep heeft een bereik voor 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:

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 te onderbreken en hervatten:

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 het maximum aantal cpu's dat wordt gebruikt en het geheugen dat elke seconde wordt gebruikt. Als de hoeveelheid CPU die wordt gebruikt en het gebruikte geheugen kleiner is dan de minimale hoeveelheid die voor elke cpu is ingericht, wordt het inrichtende bedrag gefactureerd. Als u de CPU wilt vergelijken met het 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 vCore-eenheid * max (min. vCores, gebruikte vCores, min. geheugen GB * 1/3, geheugen GB gebruikt * 1/3)
• Factureringsfrequentie: per seconde

De prijs van de 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 gedurende 1 minuut geaggregeerd.

Minimale rekenrekening

Als een serverloze database is 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 wordt 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 min. geheugen. Vervolgens is 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 te bepalen welk minimumgeheugen kan worden geconfigureerd op basis van het aantal maximaal en min. aantal geconfigureerde vCores. 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 minimale vCores dat is geconfigureerd.

Voorbeeldscenario

Overweeg een serverloze database die is geconfigureerd met 1 min. vCores en maximaal 4 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 anderszins inactief is.

In dit geval wordt de database in de eerste 8 uur gefactureerd voor reken- en opslagcapaciteit. Hoewel de database na het tweede uur inactief is, wordt deze nog steeds gefactureerd voor rekenkracht in de volgende zes uur 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:

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

• Als u aan de slag wilt gaan, raadpleegt u Quickstart: Een individuele database maken in Azure SQL Database met de Azure-portal.
• Zie voor resourcelimieten Resourcelimieten voor serverloze compute-lagen.