Condividi tramite

Livello di calcolo serverless per il database SQL di Azure

  • Articolo

Si applica a:Azure SQL Database

Il livello serverless è un livello di calcolo per database singoli in Database SQL di Azure che ridimensiona automaticamente il calcolo basato sulla domanda del carico di lavoro, addebitando la quantità di calcolo usata al secondo. Il livello di calcolo serverless inoltre sospende automaticamente i database durante i periodi di inattività, in cui viene addebitata solo l'archiviazione, e li riprende automaticamente quando necessario. Il livello di calcolo serverless è disponibile nel livello di servizio General Purpose e nel livello di servizio Hyperscale.

Nota

La sospensione automatica e la ripresa automatica sono attualmente supportate solo nel livello di servizio Utilizzo generico.

Panoramica

Un intervallo di scalabilità di calcolo automatica e un ritardo di sospensione automatica sono parametri importanti per il livello di elaborazione serverless. La configurazione di questi parametri determina l'esperienza a livello di prestazioni e i costi di calcolo del database.

Quando la fatturazione serverless smette di generare costi di calcolo a causa dell'inattività.

Configurazione delle prestazioni

  • Il numero minimo di vCore e il numero massimo di vCore sono i parametri configurabili che definiscono l'intervallo della capacità di calcolo disponibile per il database. I limiti di memoria e I/O sono proporzionali all'intervallo vCore specificato. 
  • Il ritardo di sospensione automatica è un parametro configurabile che definisce il periodo di tempo per cui il database deve rimanere inattivo prima che venga sospeso automaticamente. Il database viene ripreso automaticamente quando si verifica l'accesso successivo o un'altra attività. In alternativa, è possibile disabilitare la sospensione automatica.

Costo

Il costo di un database serverless corrisponde alla somma del costo per le risorse di calcolo e del costo per le risorse di archiviazione. Il costo di archiviazione è determinato nello stesso modo del livello di calcolo provisionato.

  • Quando l'uso delle risorse di calcolo è compreso tra i limiti minimo e massimo configurati, il costo di calcolo è basato sui vCore e sulla memoria usati.
  • Quando l'uso delle risorse di calcolo è inferiore ai limiti minimi configurati, il costo per le risorse di calcolo è basato sul numero minimo di vCore e sulla memoria minima configurata.
  • Quando il database è sospeso, il costo per le risorse di calcolo è pari a zero e vengono addebitati solo i costi per le risorse di archiviazione.

Per maggiori dettagli sui costi, vedere Fatturazione.

Scenari

Il modello serverless è caratterizzato da un rapporto qualità-prezzo ottimizzato per database singoli con modelli di utilizzo intermittenti e imprevedibili che possono permettersi qualche ritardo all'avvio del calcolo dopo periodi di inattività. Al contrario, il livello di calcolo con provisioning è ottimizzato per il rapporto prezzo-prestazioni per database singoli o per più database in pool elastici con un utilizzo medio più elevato che non possono permettersi alcun ritardo nell'attivazione del calcolo.

Scenari ottimali per la computazione serverless

  • Database singoli con modelli di utilizzo intermittenti e imprevedibili intercalati con periodi di inattività e minore utilizzo medio del calcolo nel corso del tempo.
  • Database singoli nel livello di calcolo fornito che vengono spesso ridimensionati e clienti che preferiscono delegare al servizio il ridimensionamento del calcolo.
  • Nuovi database singoli senza cronologia di utilizzo in cui il dimensionamento di calcolo è difficile o impossibile da stimare prima della distribuzione nel database SQL di Azure.

Scenari particolarmente adatti per il calcolo provisionato

  • Database singoli con modelli d'uso più regolari e prevedibili e un superiore utilizzo medio del calcolo nel corso del tempo.
  • Database che non possono tollerare compromessi delle prestazioni dovuti a riduzioni di memoria più frequenti o ritardi nel riprendere da uno stato di pausa.
  • Più database con modelli d'uso intermittenti e imprevedibili che possono essere consolidati in pool elastici per una migliore ottimizzazione del rapporto prezzo-prestazioni.

Confrontare i livelli di calcolo

La tabella seguente riepiloga le differenze tra il livello di calcolo serverless e il livello di calcolo provisionato:

Calcolo serverless Calcolo provisionato
Modello d'uso del database Uso intermittente e imprevedibile, con un minore utilizzo medio del calcolo nel corso del tempo. Modelli d'uso più regolari, con un superiore utilizzo medio del calcolo nel corso del tempo o più database con pool elastici.
Impegno per la gestione delle prestazioni Inferiore Maggiore
Ridimensionamento delle risorse di calcolo Automatico Manuale
Reattività computazionale Inferiore dopo periodi di inattività Immediato
Granularità della fatturazione Al secondo all'ora

Modello di acquisto e livello di servizio

La tabella seguente descrive il supporto serverless in base al modello di acquisto, ai livelli di servizio e all'hardware:

Categoria Supportata Non supportato
Modello di acquisto vCore DTU
Livello di servizio Scopo Generale
Hyperscale		 Essenziale per l'azienda
Hardware Serie standard (Gen5) Tutto l’hardware restante

Scalabilità automatica

Reattività al ridimensionamento

I database serverless vengono eseguiti in un computer con capacità sufficiente per soddisfare la domanda di risorse senza interruzioni per qualsiasi quantità di calcolo richiesta, entro i limiti impostati dal valore massimo di vCore. Di tanto in tanto, viene eseguito automaticamente il bilanciamento del carico se il computer non è in grado di soddisfare la richiesta di risorse entro pochi minuti. Se ad esempio la richiesta di risorse è di 4 vCore, ma sono disponibili solo 2 vCore, potrebbero essere necessari alcuni minuti per il bilanciamento del carico prima che vengano forniti 4 vCore. Durante il bilanciamento del carico il database rimane online ad eccezione di un breve periodo al termine dell'operazione, quando vengono rilasciate le connessioni.

Gestione della memoria

Nei livelli di servizio Generico e Hyperscale, la memoria per i database serverless viene rilasciata più frequentemente rispetto ai database a calcolo fornito. Questo comportamento è importante per controllare i costi nei database serverless e può influire sulle prestazioni.

Recupero della cache

A differenza dei database di calcolo con provisioning, la memoria della cache SQL viene recuperata da un database serverless quando l'uso della CPU o della cache attiva è basso.

  • L'uso della cache attiva è considerato basso quando la dimensione totale delle voci della cache usate di recente scende al di sotto di una soglia per un periodo di tempo.
  • Quando viene attivato il recupero della cache, le dimensioni della cache di destinazione vengono ridotte in modo incrementale a una frazione della dimensione precedente e il recupero continua solo se l'uso rimane basso.
  • Quando viene eseguito il recupero della cache, i criteri per la selezione delle voci della cache da rimuovere sono gli stessi criteri di selezione applicati per i database di calcolo con provisioning quando l'uso della memoria è elevato.
  • Le dimensioni della cache non vengono mai ridotte al di sotto del limite di memoria minimo, definito dal numero minimo di vCore.

Sia nei database di calcolo serverless che in quelli con provisioning, le voci della cache possono essere rimosse se viene usata tutta la memoria disponibile.

Quando l'utilizzo della CPU è basso, l'utilizzo della cache attiva può rimanere elevato a seconda del criterio di utilizzo e impedire il recupero della memoria. Inoltre, possono verificarsi altri ritardi dopo che l'attività dell'utente si arresta prima che si verifichi il recupero della memoria a causa di processi in background periodici che rispondono alle attività precedenti dell'utente. Ad esempio, le operazioni di eliminazione e i task di pulizia di Query Store generano record fantasma contrassegnati per l'eliminazione, ma non vengono eliminati fisicamente fino all'esecuzione del processo di pulizia fantasma. La pulizia fantasma potrebbe comportare la lettura delle pagine di dati nella cache.

Idratazione della cache

La cache di memoria SQL aumenta via via che i dati vengono recuperati dal disco nello stesso modo e con la stessa velocità dei database provisioned. Quando il database è occupato, la cache può aumentare senza vincoli fino al limite massimo di memoria disponibile.

Gestione della cache del disco

Nel livello di servizio Hyperscale, sia per i livelli di elaborazione serverless che con provisioning, ogni replica di calcolo utilizza una cache RBPEX (Resilient Buffer Pool Extension) che memorizza le pagine di dati su SSD locali per migliorare le prestazioni di I/O. Tuttavia, nel livello di elaborazione serverless per Hyperscale, la cache RBPEX per ogni replica di calcolo aumenta e si compatta automaticamente in risposta all'aumento e alla riduzione della domanda del carico di lavoro. Le dimensioni massime della cache RBPEX possono aumentare fino a tre volte la memoria massima configurata per il database. Per dettagli sui limiti massimi di memoria e ridimensionamento automatico di RBPEX in serverless, vedi Limiti delle risorse Hyperscale serverless.

Sospensione automatica e ripresa automatica

Attualmente, la sospensione automatica serverless e la ripresa automatica sono supportate solo nel livello per utilizzo generico.

Sospensione automatica

La sospensione automatica viene attivata se tutte le seguenti condizioni sono vere durante il ritardo della sospensione automatica.

  • Numero di sessioni = 0
  • CPU = 0 per il carico di lavoro utente in esecuzione nel pool di risorse

Se lo si desidera, è disponibile un'opzione per disabilitare la sospensione automatica.

Le seguenti caratteristiche non supportano la sospensione automatica, ma supportano il ridimensionamento automatico. Se quindi si usa una delle caratteristiche seguenti, la sospesione automatica deve essere disabilitata e il database rimane online indipendentemente dall'intervallo di inattività del database:

  • Replica geografica (replica geografica attiva e gruppi di failover).
  • Conservazione a lungo termine dei backup (LTR).
  • Il database di sincronizzazione utilizzato in SQL Data Sync. A differenza dei database di sincronizzazione, i database hub e i database membri supportano la sospensione automatica.
  • Alias DNS creato per il server logico contenente un database serverless.
  • Elastic Jobs, il database serverless abilitato per la sospensione automatica non è supportato come Job Database. I database serverless destinati ai lavori elastici supportano la sospensione automatica. Le connessioni di lavoro riprendono un database.

La sospensione automatica viene temporaneamente impedita durante la distribuzione di alcuni aggiornamenti dei servizi che richiedono che il database sia online. In questi casi, la sospensione automatica diventa nuovamente consentita al termine dell'aggiornamento del servizio.

Risoluzione dei problemi di sospensione automatica

Se la sospensione automatica è abilitata e le funzionalità che bloccano la sospensione automatica non vengono usate, ma un database non viene sospeso automaticamente dopo il periodo di ritardo, le sessioni dell'applicazione o dell'utente potrebbero impedire la sospensione automatica.

Per verificare se sono presenti sessioni utente o applicazioni attualmente connesse al database, connettersi al database usando uno strumento client ed eseguire la query seguente:

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

Suggerimento

Dopo aver eseguito la query, accertati di disconnetterti dal database. In caso contrario, la sessione aperta usata dalla query impedisce la sospensione automatica.

  • Se il set di risultati non è vuoto, significa che sono presenti sessioni che attualmente impediscono la sospensione automatica.
  • Se il set di risultati è vuoto, è comunque possibile che le sessioni fossero aperte, forse per un breve periodo di tempo, in un momento precedente durante il periodo di ritardo della sospensione automatica. Per verificare la presenza di attività durante il periodo di ritardo, è possibile usare Controllo per il database SQL di Azure e Azure Synapse Analytics ed esaminare i dati di controllo per il periodo pertinente.

Importante

La presenza di sessioni aperte, con o senza utilizzo simultaneo della CPU nel pool di risorse utente, è il motivo più comune per cui un database serverless non viene sospeso automaticamente come previsto.

Ripresa automatica

La ripresa automatica viene attivata in presenza di una qualsiasi delle condizioni seguenti in un qualsiasi momento:

Funzionalità Grilletto di ripresa automatica
Autenticazione e autorizzazione Accedi
Rilevamento delle minacce Abilitazione/disabilitazione delle impostazioni di rilevamento delle minacce a livello di database o server.
Modifica delle impostazioni di rilevamento delle minacce a livello di database o server.
Individuazione e classificazione dei dati Aggiunta, modifica, eliminazione o visualizzazione delle etichette di sensibilità
Controllo Visualizzazione dei record di controllo
Aggiornamento o visualizzazione delle politiche di audit.
Offuscamento dei dati Aggiunta, modifica, eliminazione o visualizzazione delle regole di mascheramento dei dati
Crittografia Trasparente dei Dati Visualizzazione dello stato di Transparent Data Encryption
Valutazione della vulnerabilità Analisi avviate manualmente e analisi periodiche, se abilitate
Esecuzione di query sulle prestazioni dell'archivio dati Modifica o visualizzazione delle impostazioni di Query Store
Consigli sulle prestazioni Visualizzazione o applicazione di raccomandazioni sulle prestazioni
Ottimizzazione automatica Applicazione e verifica dei consigli per l'ottimizzazione automatica, ad esempio l'indicizzazione automatica
Copia del database Creazione del database come copia.
Esportazione in un file BACPAC.
Sincronizzazione dati SQL Sincronizzazione tra database hub e membro che viene eseguita secondo un calendario configurabile o manualmente
Modifica di alcuni metadati del database Aggiunta di nuovi tag del database.
Modifica del numero massimo di vCore, del numero minimo di vCore o del ritardo della sospensione automatica.
SQL Server Management Studio (SSMS) Se si usano le versioni di SSMS precedenti alla 18.1 e si apre un nuovo intervallo di query per un qualsiasi database nel server, verranno ripresi tutti i database sospesi automaticamente nello stesso server. Questo comportamento non si verifica se si usa SSMS 18.1 o versione successiva.

Monitoraggio, gestione o altre soluzioni che eseguono una di queste operazioni attivano la ripresa automatica. La ripresa automatica viene attivata anche durante la distribuzione di alcuni aggiornamenti dei servizi che richiedono che il database sia online.

Connettività

Se un database serverless è in pausa, verrà ripreso al primo tentativo di connessione. Verrà inoltre restituito un errore con codice errore 40613 che indica che il database non è disponibile. Dopo aver ripreso il database, provare di nuovo l'accesso per stabilire la connettività. I client del database che seguono i consigli sulla logica dei tentativi di connessione non devono essere modificati. Per le opzioni e i consigli relativi alla logica di ripetizione dei tentativi di connessione, vedere:

  • Logica di ritentare la connessione in SqlClient
  • Logica di ripetizione dei tentativi di connessione nel database SQL usando Entity Framework Core
  • Logica di ripetizione dei tentativi di connessione in database SQL con Entity Framework 6
  • Logica di ripetizione dei tentativi di connessione in database SQL tramite ADO.NET

Latenza

La latenza per riprendere e sospendere automaticamente un database serverless è in genere di circa un minuto per la ripresa automatica e di 1-10 minuti dopo la scadenza del periodo di ritardo per la sospensione automatica.

Crittografia trasparente dei dati gestita dal cliente (BYOK - Bring Your Own Key)

Eliminazione o revoca della chiave

Se si utilizza la crittografia trasparente dei dati gestita dal cliente (BYOK) e il database serverless viene sospeso automaticamente in caso di eliminazione o revoca della chiave, il database rimane nello stato di sospensione automatica. In questo caso, dopo la successiva ripresa del database, il database diventa inaccessibile entro circa 10 minuti. Quando il database diventa inaccessibile, il processo di ripristino è identico a quello per i database di calcolo con provisioning. Se il database serverless è online quando si verifica l'eliminazione o la revoca della chiave, il database diventa inaccessibile entro circa 10 minuti, proprio come accade per i database di calcolo con provisioning.

Rotazione delle chiavi

Se si utilizza la crittografia trasparente dei dati gestita dal cliente (BYOK) e la funzionalità di sospensione automatica del serverless è abilitata, il database si riprende automaticamente ogni volta che le chiavi di crittografia vengono ruotate. Il database verrà quindi sospeso automaticamente quando vengono soddisfatte le condizioni di sospensione automatica.

Creare un nuovo database senza server

La procedura di creazione di un nuovo database o di spostamento di un database esistente in un livello di calcolo serverless è analoga a quella di creazione di un nuovo database nel livello di calcolo con provisioning e prevede i due passaggi seguenti:

  1. Specificare l'obiettivo di servizio. L'obiettivo del servizio prescrive il livello di servizio, la configurazione hardware e il numero massimo di vCores. Per le opzioni degli obiettivi del servizio, vedi Limiti delle risorse serverless

  2. Facoltativamente, specifica il numero minimo di vCore e il ritardo di sospensione automatica per modificarne i valori predefiniti. La tabella seguente illustra i valori disponibili per questi parametri.

    Parametro Scelte di valori Valore predefinito
    Numero minimo di vCore Dipende dal numero massimo di vCore configurati - consultare Limiti delle risorse. 0,5 vCore
    Ritardo della pausa automatica Minimo: 15 minuti
    Massimo: 10.080 minuti (sette giorni)
    Incremento: 1 minuto
    Disabilita la sospensione automatica: -1    		 60 minuti

Negli esempi seguenti viene creato un nuovo database nel livello di calcolo serverless.

Usare il portale di Azure

Vedi Guida rapida: creare un database singolo in Azure SQL Database utilizzando il portale di Azure.

Utilizzare PowerShell

Crea un nuovo database per utilizzo generico serverless con l'esempio di PowerShell seguente:

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

Utilizzare l'interfaccia della riga di comando di Azure

Crea un nuovo database per utilizzo generico serverless con l'esempio seguente dell'interfaccia della riga di comando di Azure:

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

Usare Transact-SQL (T-SQL)

Quando si usa T-SQL per creare un nuovo database serverless, i valori predefiniti vengono applicati per il numero minimo di vCore e il ritardo di sospensione automatica. I valori possono essere modificati in un secondo momento dal portale di Azure o tramite API, tra cui PowerShell, l'interfaccia della riga di comando di Azure e REST.

Per dettagli, vedere CREATE DATABASE.

Crea un nuovo database serverless per utilizzo generico con l'esempio T-SQL seguente:

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

Spostare un database tra livelli di calcolo o i livello di servizio

È possibile spostare un database tra il livello di calcolo con provisioning e il livello di calcolo serverless.

Un database serverless può anche essere spostato dal livello di servizio Utilizzo generico al livello di servizio Hyperscale. Per altre informazioni, vedere Convertire un database esistente in Hyperscale.

Quando si sposta un database tra livelli di calcolo, specificare il parametro del modello di calcolo come Serverless o Provisioned quando si usa PowerShell o Azure CLI, o il SERVICE_OBJECTIVE quando si usa T-SQL. Esaminare limiti delle risorse per identificare l'obiettivo di servizio appropriato.

Negli esempi seguenti un database esistente viene spostato dal calcolo con risorse predefinite al serverless.

Utilizzare PowerShell

Sposta un database per calcolo per usi generici con provisioning nel livello di calcolo senza server con il seguente esempio di PowerShell:

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

Utilizzare l'interfaccia della riga di comando di Azure

Sposta un database di calcolo con provisioning per uso generico nel livello di elaborazione serverless con il seguente esempio di interfaccia riga di comando di Azure:

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

Usare Transact-SQL (T-SQL)

Quando si usa T-SQL per spostare un database tra livelli di calcolo, i valori predefiniti vengono applicati per il numero minimo di vCore e il ritardo di sospensione automatica. I valori possono essere successivamente modificati dal portale di Azure o tramite API, tra cui PowerShell, l'interfaccia della riga di comando di Azure e REST. Per ulteriori informazioni, vedere ALTER DATABASE.

Sposta un database di calcolo ad uso generico con provisioning al livello di calcolo serverless, con il seguente esempio T-SQL:

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

Modifica della configurazione serverless

Utilizzare PowerShell

Usa Set-AzSqlDatabase per modificare il numero massimo o minimo di vCore e il ritardo di sospensione automatica. Usa gli argomenti MaxVcore, MinVcore, e AutoPauseDelayInMinutes. La sospensione automatica serverless non è attualmente supportata nel livello Hyperscale, quindi il parametro di ritardo per la sospensione automatica è applicabile solo al livello Generale.

Utilizzare l'interfaccia della riga di comando di Azure

Usa az sql db update per modificare il numero massimo o minimo di vCore e il ritardo di sospensione automatica. Usa gli argomenti capacity, min-capacity, e auto-pause-delay. La sospensione automatica nella modalità serverless non è attualmente supportata nel livello Hyperscale, quindi l'argomento relativo al ritardo di sospensione automatica è applicabile solo al livello General Purpose.

Monitoraggio

Risorse usate e fatturate

Le risorse di un database serverless includono le entità per il pacchetto dell'app, l'istanza di SQL e il pool di risorse utente.

Pacchetto dell'app

Il pacchetto app rappresenta il confine più esterno nella gestione delle risorse per un database, sia che il database si trovi in un livello di calcolo senza server o con provisioning. Il pacchetto dell'app contiene l'istanza di SQL e servizi esterni, come la ricerca full-text, che insieme definiscono l'ambito di tutte le risorse utente e di sistema utilizzate da un database presente in SQL Database. L'istanza di SQL solitamente domina l'utilizzo complessivo delle risorse nel pacchetto applicativo.

Pool di risorse utente

Il pool di risorse dell'utente è un confine interno per la gestione delle risorse di un database, indipendentemente dal fatto che il database si trovi in un livello di calcolo senza server o con provisioning. Il pool di risorse utente definisce l'ambito della CPU e dell'I/O per il carico di lavoro utente generato da query DDL (CREATE e ALTER) e DML (INSERT, UPDATE, DELETE, MERGE e SELECT). Queste domande rappresentano in genere la percentuale più consistente di utilizzo all'interno del pacchetto dell'app.

Metriche

La tabella seguente include le metriche per il monitoraggio dell'uso della risorsa del pacchetto dell'app e del pool di risorse utente di un database serverless, tra cui le repliche geografiche:

Entità Metrico Descrizione Unità
Pacchetto dell'app percentuale_cpu_app Percentuale di vCore usati dall'app rispetto al numero massimo di vCore consentito per l'app. Per Hyperscale serverless, questa metrica viene esposta per tutte le repliche primarie, le repliche denominate e le repliche geografiche. Percentuale
Pacchetto dell'app cpu_app_fatturata Quantità di risorse di calcolo fatturata per l'app durante il periodo di riferimento. L'importo pagato durante questo periodo è dato dal prodotto di questa metrica per il prezzo unitario dei vCore.

I valori di questa metrica sono determinati dall'aggregazione del numero massimo di CPU usate e dalla memoria usata al secondo. Se la quantità utilizzata è inferiore all'importo minimo previsto, stabilito dal numero minimo di vCore e dalla memoria minima, viene fatturato l'importo minimo previsto. Per confrontare la quantità di CPU e di memoria ai fini della fatturazione, la memoria viene normalizzata in unità di vCore ridimensionando la quantità di memoria in GB in base a 3 GB per vCore. Per Hyperscale serverless, questa metrica viene esposta per la replica primaria e tutte le repliche denominate.		 Secondi per vCore
Pacchetto dell'app app_cpu_fatturato_HA_repliche Valido esclusivamente per Hyperscale serverless. Somma del calcolo addebitato in tutte le app per repliche di alta disponibilità nel periodo di riferimento. Questa somma è limitata alle repliche a disponibilità elevata appartenenti alla replica primaria o alle repliche a disponibilità elevata appartenenti a una determinata replica specifica. Prima di calcolare questa somma nelle repliche HA, la quantità di calcolo fatturata per una singola replica HA viene determinata allo stesso modo della replica primaria o di una replica nominata. Per Hyperscale serverless, questa metrica viene esposta per tutte le repliche primarie, le repliche denominate e le repliche geografiche. L'importo pagato durante questo periodo di riferimento è il prodotto di questa metrica per il prezzo unitario dei vCore. Secondi per vCore
Pacchetto dell'app percentuale_memoria_applicazione Percentuale di memoria usata dall'app rispetto alla memoria massima consentita per l'app. Per Hyperscale serverless, questa metrica viene esposta per tutte le repliche primarie, le repliche denominate e le repliche geografiche. Percentuale
Pool di risorse utente percentuale_cpu Percentuale di vCore usati dal carico di lavoro utente rispetto al numero massimo di vCore consentiti per il carico di lavoro utente. Percentuale
Pool di risorse utente dati_IO_percentuale Percentuale di IOPS dei dati utilizzata dal carico di lavoro dell'utente rispetto al massimo consentito per tale carico di lavoro. Percentuale
Pool di risorse utente log_IO_percent Percentuale di MB/s di log usati dal carico di lavoro utente rispetto al numero massimo di MB/s di log consentiti per il carico di lavoro utente. Percentuale
Pool di risorse utente percentuale_lavoratori Percentuale di ruoli di lavoro usati dal carico di lavoro utente rispetto al numero massimo di ruoli di lavoro consentiti per il carico di lavoro utente. Percentuale
Pool di risorse utente percentuale_sessioni Percentuale di sessioni usate dal carico di lavoro utente rispetto al numero massimo di sessioni consentite per il carico di lavoro utente. Percentuale

Stato di sospensione e ripresa

Nel caso di un database serverless con sospensione automatica abilitata, lo stato segnalato include i valori seguenti:

Stato Descrizione
Online Il database è online.
Sospensione Il database passa da online a sospeso.
Sospeso Il database è sospeso.
Ripresa Il database sta passando da sospeso a online.

Usare il portale di Azure

Nel portale di Azure lo stato del database è visualizzato nella pagina di panoramica del database e nella pagina di panoramica del relativo server. Inoltre, nel portale di Azure, la cronologia degli eventi di sospensione e ripresa di un database serverless può essere visualizzata nel Activity log.

Utilizzare PowerShell

È possibile visualizzare lo stato corrente del database utilizzando il seguente esempio PowerShell:

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

Utilizzare l'interfaccia della riga di comando di Azure

Visualizzare lo stato corrente del database usando l'esempio seguente dell'interfaccia della riga di comando di Azure:

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

Limiti delle risorse

Per i limiti delle risorse, vedere il livello di calcolo serverless.

Fatturazione

La quantità di calcolo fatturata per un database serverless è il massimo tra la CPU utilizzata e la memoria utilizzata ogni secondo. Se la quantità di CPU e di memoria usata è inferiore alla quantità minima del provisioning per ciascuna risorsa, viene fatturata la quantità del provisioning. Per confrontare la quantità di CPU e di memoria ai fini della fatturazione, la memoria viene normalizzata in unità di vCore ridimensionando il numero di GB a 3 GB per vCore.

  • Risorsa fatturata: CPU e memoria
  • Importo fatturato: prezzo unitario per vCore * massimo (minimo vCore, vCore usati, memoria minima in GB * 1/3, memoria in GB usata * 1/3)
  • Frequenza di fatturazione: al secondo

Il prezzo unitario per vCore è il costo per secondo per ciascun vCore.

Per i prezzi unitari in una determinata area, fare riferimento alla Pagina dei prezzi del database SQL di Azure.

La quantità di elaborazione fatturata in modalità serverless per un database a scopo generico, o una replica primaria o denominata di tipo Hyperscale, è esposta dalla seguente metrica:

  • Metrica: app_cpu_billed (vCore secondi)
  • Definizione: massimo (numero minimo di vCore, numero di vCore usati, quantità minima di memoria in GB * 1/3, quantità di memoria in GB usata * 1/3)
  • Frequenza di reporting: ogni minuto in base a misurazioni al secondo aggregate nell'arco di 1 minuto.

La quantità di potenza di calcolo fatturata in serverless per le repliche HA di Hyperscale appartenenti alla replica primaria o a qualsiasi replica denominata è esposta dalla metrica seguente:

  • Metrica: app_cpu_billed_HA_replicas (secondi per vCore)
  • Definizione: Somma del massimo (vCores minimi, vCores usati, quantità minima di memoria in GB * 1/3, quantità di memoria in GB usata * 1/3) per tutte le repliche HA appartenenti alla loro risorsa principale.
  • Risorsa padre ed endpoint della metrica: la replica primaria e qualsiasi replica con nome specifico espongono separatamente questa metrica, che misura le risorse di calcolo fatturate per le repliche ad alta disponibilità associate.
  • Frequenza di reporting: ogni minuto in base a misurazioni al secondo aggregate nell'arco di 1 minuto.

Costo minimo di calcolo

Se un database serverless è in pausa, il costo di calcolo è zero. Se un database serverless non è in pausa, il costo minimo di elaborazione non sarà inferiore al valore massimo tra il numero minimo di vCore e la quantità minima di memoria in GB moltiplicata per 1/3.

Esempi:

  • Si supponga che un database serverless nel livello per utilizzo generico non sia in pausa e sia configurato con 8 vCore al massimo e 1 vCore al minimo corrispondenti a 3,0 GB di memoria al minimo. La fattura minima di calcolo è quindi basata sul massimo (1 vCore, 3,0 GB * 1 vCore / 3 GB) = 1 vCore.
  • Si supponga che un database serverless nel livello per utilizzo generico non sia in pausa e configurato con 4 vCore al massimo e 0,5 vCore al minimo corrispondenti a 2,1 GB di memoria al minimo. Il costo minimo di calcolo è quindi basato sul massimo (0,5 vCore, 2,1 GB * 1 vCore / 3 GB) = 0,7 vCore.
  • Si supponga che un database serverless nel livello Hyperscale abbia una replica primaria con una replica HA e una replica denominata senza alcuna replica HA. Si supponga che ogni replica sia configurata con 8 vCore al massimo e 1 vCore al minimo corrispondenti a 3 GB di memoria al minimo. Il costo di calcolo minimo per la replica primaria, la replica ad alta disponibilità e la replica denominata è quindi ciascuna basato sul massimo (1 vCore, 3 GB * 1 vCore / 3 GB) = 1 vCore.

La calcolatrice dei prezzi del database SQL di Azure per serverless può essere usata per determinare la memoria minima configurabile in base al numero di vCore configurati, massimo e minimo. Come regola, se i vCore minimi configurati sono maggiori di 0,5 vCore, la fattura minima di calcolo è indipendente dalla memoria minima configurata ed è basata solo sul numero di vCore minimi configurati.

Scenari esemplificativi

Si consideri un database serverless nel livello per utilizzo generico configurato con 1 vCore al minimo e 4 vCore al massimo. Questa configurazione corrisponde a una quantità minima di memoria di circa 3 GB e a una quantità massima di memoria di 12 GB. Si supponga che il ritardo di sospensione automatica sia impostato su 6 ore e che il carico di lavoro del database sia attivo nelle prime 2 ore di un periodo di 24 ore e inattivo nelle ore seguenti.

In questo caso, il database viene fatturato per le risorse di calcolo e di archiviazione durante le prime 8 ore. Anche se il database è inattivo a partire dalla seconda ora, viene comunque fatturato per la potenza di calcolo nelle 6 ore successive, in base alla potenza di calcolo minima con provisioning disponibile mentre il database è online. Durante il resto del periodo di 24 ore in cui il database è sospeso, viene fatturata solo l'archiviazione.

Più precisamente, la fattura per le risorse di calcolo in questo esempio viene calcolata come segue:

Intervallo di tempo vCore utilizzati ogni secondo GB usati ogni secondo Dimensione di elaborazione fatturata Secondi di vCore fatturati nell'intervallo di tempo
0:00-1:00 4 9 vCore usati 4 vCores * 3.600 secondi = 14.400 secondi vCore
1:00-2:00 1 12 Memoria usata 12 GB * 1/3 * 3.600 secondi = 14.400 secondi vCore
2:00-8:00 0 0 Memoria minima allocata 3 GB * 1/3 * 21.600 secondi = 21.600 secondi vCore
8:00-24:00 0 0 Nessun costo di calcolo durante la pausa 0 secondi per vCore
Totale secondi per vCore fatturati nel periodo di 24 ore 50.400 secondi per vCore

Si supponga che il prezzo delle unità di calcolo sia $0,000145/vCore/secondo. Il calcolo fatturato per questo periodo di 24 ore è quindi il prodotto del prezzo unitario di calcolo e dei secondi vCore fatturati: $ 0,000145/vCore al secondo * 50,400 vCore secondi ~ $ 7,31.

Vantaggio Azure Hybrid e prenotazioni

Gli sconti dell'Azure Hybrid Benefit (AHB) e delle prenotazioni di Azure non si applicano al livello di calcolo senza server.

Aree disponibili

Per la disponibilità regionale, vedere disponibilità serverless per regione per il database SQL di Azure.

Contenuto correlato