Auto-pause en auto-resume in de serverless compute tier voor Azure SQL Database

Van toepassing op:Azure SQL Database

Dit artikel legt het automatische pauze- en auto-hervattingsgedrag uit voor de serverless compute-laag in Azure SQL Database, en hoe deze samenwerkt met verschillende functies van de Azure SQL Database.

Momenteel is de servicelaag General Purpose de enige servicelaag die serverless automatisch pauzeren en hervatten ondersteunt.

Om de status van een serverless database te bewaken, raadpleegt u De onderbrekings- en hervattingsstatus bewaken.

Automatisch onderbreken

Automatisch pauzeren begint als tijdens de vertraging voor automatisch pauzeren aan alle volgende voorwaarden wordt voldaan:

  • Aantal sessies = 0
  • CPU = 0 voor de gebruikerswerklast die wordt uitgevoerd in de gebruikersresourcepool

Standaard is er een automatische pauzevertraging van een uur.

Functies die automatische pauze voorkomen

Als je een van de volgende functies gebruikt, schakel dan automatisch pauzeren uit. De database blijft online, ongeacht hoe lang de database inactief is. De volgende functies voorkomen het automatisch pauzeren, maar ondersteunen wel automatisch schalen:

De volgende functiescenario’s voorkomen ook dat automatisch wordt gepauzeerd:

  • De synchronisatiedatabase die wordt gebruikt in SQL Data Sync. In tegenstelling tot synchronisatiedatabases ondersteunen hub- en liddatabases automatisch pauzeren.
  • In elastische jobs wordt een serverless database met auto-pauze ingeschakeld niet ondersteund als taakdatabase. Serverloze databases waarop elastic jobs zijn gericht, ondersteunen automatisch pauzeren. Werkverbindingen hervatten met 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.

Automatisch hervatten

Auto-resume start als een van de volgende voorwaarden op enig moment waar is:

Feature Trigger voor automatisch hervatten
Verificatie en autorisatie Aanmeldingspoging
Detectie van bedreigingen Het in- of uitschakelen van dreigingsdetectie-instellingen 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
Transparante gegevensversleuteling De staat of status van transparante gegevensversleuteling bekijken
Evaluatie van beveiligingsproblemen Handmatig geïnitieerde scans en periodieke scans indien ingeschakeld
Query (prestatie) gegevensopslag Instellingen voor Query Store wijzigen of weergeven
Aanbevelingen voor prestaties Prestatieaanaanvelingen weergeven of toepassen
Automatisch afstemmen Toepassing en validatie van aanbevelingen voor automatische afstemming, zoals autoindexering
Database kopiëren Maak een database als kopie.
Exporteren naar een BACPAC-bestand.
SQL-gegevenssynchronisatie Synchronisatie tussen hub- en liddatabases die worden uitgevoerd volgens een configureerbaar schema of handmatig worden uitgevoerd
Bepaalde databasemetagegevens wijzigen Het toevoegen of wijzigen van Azure-tags aan de database.
Wijzigen van de maximale vCores, minimale vCores, of de automatische pauzevertraging.
SQL Server Management Studio (SSMS) In SSMS-versies van vóór 18.1 en het openen van een nieuw queryvenster voor elke database op de server, wordt elke automatisch gepauzeerde database op dezelfde server hervat. Dit gedrag doet zich niet voor als je SSMS versie 18.1 of later gebruikt.

Monitoring, beheer of andere oplossingen die een van deze bewerkingen uitvoeren veroorzaken automatisch hervatting. Automatisch hervatten begint ook tijdens de implementatie van sommige service-updates die vereisen dat de database online is.

Identificatie van automatisch hervattingsmechanisme

Het Azure Monitor-activiteitenlogboek geeft triggers voor automatisch hervatten weer voor Resume Databases-bewerkingen onder de eigenschap Caller in de JSON van de gebeurtenissen Started en Succeeded. Raadpleeg Het serverloze rekentierniveau bewaken voor meer informatie.

Wachttijd

De latentie ligt doorgaans tussen één minuut om automatisch te hervatten en 1-10 minuten om automatisch te pauzeren. De latentie voor beide bewerkingen kan zo laag zijn als ongeveer één seconde.

Klantbeheerde transparante gegevensversleuteling

Sleutelverwijdering of sleutelintrekking

Als je klantbeheerde transparante data-encryptie gebruikt (neem je eigen sleutel of BYOK mee) en de serverloze database wordt automatisch gepauzeerd wanneer sleutel wordt verwijderd of ingetrokken, blijft de database in de automatisch gepauzeerde toestand. In dit geval wordt de database binnen ongeveer 10 minuten na hervatting ontoegankelijk. Zodra de database niet toegankelijk is, is het herstelproces hetzelfde als voor ingerichte rekendatabases. Als de serverloze database online is wanneer sleutelverwijdering of -intrekking plaatsvindt, wordt de database ook binnen ongeveer 10 minuten ontoegankelijk, op dezelfde manier als bij provisioned compute-databases.

Sleutelrotatie

Als u door de klant beheerde transparante gegevensversleuteling (BYOK) gebruikt en automatisch onderbreken in de serverloze modus inschakelt, wordt de database automatisch hervat wanneer sleutels worden geroteerd. De database pauzeert vervolgens automatisch wanneer aan de automatische pauzevoorwaarden is voldaan.

Problemen met automatisch pauzeren oplossen

Problemen met automatisch hervatten van de verbinding oplossen

Als een serverloze database is onderbroken, wordt de database hervat met de eerste verbindingspoging en wordt een fout geretourneerd waarin wordt aangegeven dat de database niet beschikbaar is met foutcode 40613. Zodra de database wordt hersteld, probeer je de verbinding opnieuw. Databases worden over het algemeen binnen minder dan een minuut hervat.

Alle cloud-verbonden applicaties zouden aanbevelingen voor de verbindingsherprobeerlogica moeten gebruiken. Applicaties hebben herkansingslogica nodig om te slagen na tijdelijke connectiviteitsfouten. Hertelingslogica is vooral belangrijk voor serverloze databases, waar tijdelijke connectiviteitsfouten door auto-hervatting voorspelbaar zijn.

Voor opties en aanbevelingen voor opnieuw proberen van verbindingen raadpleegt u:

Probleemoplossing voor automatische pauze

Als je automatisch pauzeren inschakelt en geen functies gebruikt die automatisch pauzeren blokkeren, maar de database na de vertragingsperiode niet automatisch pauzeert, kunnen applicatie- of gebruikerssessies automatisch pauzeren voorkomen.

Om te zien of er applicatie- of gebruikerssessies momenteel aan de database zijn gekoppeld, voer je de volgende zoekopdracht 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 het automatisch pauzeren.

  • Als de resultaatset niet leeg is, geeft dit aan dat sessies momenteel automatische pauze voorkomen.
  • Als de resultaatset leeg is, is het nog steeds mogelijk dat sessies openstonden, mogelijk voor een korte tijd, op een bepaald moment eerder tijdens de automatische pauzevertraging. Om activiteit tijdens de vertragingsperiode te controleren, gebruik Auditing for Azure SQL Database en Azure Synapse Analytics en bekijk de auditgegevens van de betreffende periode.

Important

De aanwezigheid van geopende 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.

Verwante onderwerpen

  • Last updated on