Pausa automatica e ripresa automatica nel livello di calcolo serverless per database SQL di Azure

Si applica a:Database SQL di Azure

Questo articolo spiega il comportamento di auto-pausa e ripresa automatica per il livello di calcolo serverless in database SQL di Azure, e come interagisce con varie funzionalità di database SQL di Azure.

  • La pausa automatica e l'auto-ripresa senza server sono disponibili nel livello di servizio a uso generale.
  • La sospensione automatica e la riattivazione automatica serverless sono una funzionalità in anteprima di database SQL di Azure Hyperscale.

Per monitorare lo stato di un database serverless, vedi Monitorare pausa e riprendere lo stato.

Sospensione automatica

L'auto-pausa inizia se tutte le seguenti condizioni sono verificate durante il ritardo di auto-pausa:

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

Per ulteriori informazioni, consulta la configurazione delle prestazioni serverless.

  • Nel livello di servizio General Purpose, il ritardo predefinito di auto-pausa è di 60 minuti, mentre il minimo è di 15 minuti.
  • Per l'auto-pausa di Hyperscale (anteprima), il ritardo di auto-pausa predefinito è di 60 minuti e il minimo è di 60 minuti.

Funzionalità che impediscono la pausa automatica

Se usi una delle seguenti funzionalità, disabilita la pausa automatica. Il database rimane online indipendentemente da quanto tempo rimane inattivo. Le seguenti funzionalità impediscono la pausa automatica, ma supportano l'auto-scaling:

I seguenti scenari di funzionalità impediscono anche l'auto-pausa:

  • Il database di sincronizzazione utilizzato in SQL sincronizzazione dati. A differenza dei database di sincronizzazione, i database hub e i database membri supportano la sospensione automatica.
  • Nei lavori elastici, un database serverless con auto-pausa abilitata non è supportato come database di lavoro. I database serverless selezionati da Elastic Jobs supportano l'auto-pausa. 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.

Ripresa automatica

L'auto-ripresa inizia se una qualsiasi delle seguenti condizioni è valida in qualsiasi momento:

Feature Grilletto di ripresa automatica
Autenticazione e autorizzazione Tentativo di accesso
Rilevamento di minacce Abilitazione o 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.
Mascheramento dei dati Aggiunta, modifica, eliminazione o visualizzazione delle regole di mascheramento dei dati
Cifratura dati trasparente 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 suggerimenti di ottimizzazione automatica, quali 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 Aggiungere o modificare tag Azure nel database.
Modifica del numero massimo di vCore, del numero minimo di vCore o del ritardo della sospensione automatica.
SQL Server Management Studio (SSMS) Nelle versioni di SSMS precedenti alla 18.1, quando si apre una nuova finestra di query per qualsiasi database del server, qualsiasi database nello stesso server in pausa automatica viene riattivato. Questo comportamento non si verifica se usi SSMS versione 18.1 o successiva.

Il monitoraggio, la gestione o altre soluzioni che eseguono una qualsiasi di queste operazioni attivano l'auto-ripresa. La ripresa automatica inizia anche durante la distribuzione di alcuni aggiornamenti del servizio che richiedono che il database sia in linea.

Identificazione del trigger di ripresa automatica

Il registro attività di Monitoraggio di Azure mostra i trigger di ripresa automatica per le operazioni Resume Databases nella proprietà Caller del JSON degli eventi Started e Succeeded. Per ulteriori informazioni, vedi Monitora il livello di calcolo serverless.

Latenza

La latenza è generalmente di circa un minuto per la ripresa automatica e da 1 a 10 minuti per la pausa automatica dopo aver soddisfatti i criteri per la ripresa o la pausa. La latenza per entrambe le operazioni può essere bassa di circa un secondo.

Crittografia trasparente dei dati gestita dal cliente

Eliminazione o revoca della chiave

Se usi una crittografia trasparente dei dati gestita dal cliente (porta la tua chiave o BYOK) e il database serverless viene messo in pausa quando avviene la cancellazione o la revoca della chiave, il database rimane in stato di pausa automatica. In questo caso, dopo che il database riprende, 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 avviene la cancellazione o la revoca della chiave, il database diventa anche inaccessibile entro circa 10 minuti, allo stesso modo dei database di calcolo provisionati.

Rotazione delle chiavi

Se usi la crittografia trasparente dei dati gestita dal cliente (BYOK) e abiliti la sospensione automatica serverless, il database si riattiva automaticamente ogni volta che le chiavi vengono ruotate. Il database poi si mette in pausa automaticamente quando sono soddisfatte le condizioni di auto-pausa.

Risoluzione dei problemi di sospensione automatica

Risoluzione dei problemi con la connettività con ripresa automatica

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. Una volta che il database riprende, riprova la connessione. I database generalmente riprendono in meno di un minuto.

Tutte le applicazioni connesse al cloud dovrebbero utilizzare raccomandazioni di logica di ritentazione di connessione. Le applicazioni richiedono la logica di ritentativi per avere successo dopo errori di connettività transitoria. La logica di ritentativi è particolarmente importante per i database serverless, dove errori temporanei di connettività dovuti all'auto-ripresa sono prevedibili.

Per le opzioni e i consigli relativi alla logica di ripetizione dei tentativi di connessione, vedere:

Risoluzione dei problemi relativi alla pausa automatica

Se abiliti l'auto-pausa e non usi funzionalità che bloccano la pausa automatica, ma il database non si mette in pausa automaticamente dopo il periodo di ritardo, le sessioni di applicazioni o utente potrebbero impedire la pausa automatica.

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.

Rilevare connessioni che impediscono l'auto-pausa

Per verificare se qualche applicazione o sessione utente è attualmente collegata al database, esegui la seguente interrogazione:

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'
      );
  • Se il set di risultati non è vuoto, indica che le sessioni attualmente impediscono l'auto-pausa.
  • Se il set di risultati è vuoto, è comunque possibile che le sessioni siano rimaste aperte, magari per un breve periodo, in un momento precedente del periodo di ritardo della sospensione automatica. Per verificare l'attività durante il periodo di ritardo, utilizza Audit ed esamina i dati di audit relativi al periodo rilevante.

Tip

Dopo aver eseguito la query, disconnettiti dal database. Altrimenti, la sessione aperta utilizzata dalla query impedisce la pausa automatica.

Limitations

  • Nell'attuale anteprima della funzionalità serverless di sospensione automatica e riattivazione automatica per database SQL di Azure Hyperscale, le repliche denominate non supportano la sospensione automatica e la riattivazione automatica.
  • Nell'attuale versione di anteprima della sospensione automatica e della ripresa automatica serverless per database SQL di Azure Hyperscale, il tempo minimo prima della sospensione automatica è di 60 minuti. I database serverless generici con pausa automatica di meno di 60 minuti aggiornati a Hyperscale serverless avranno la pausa automatica disabilitata dopo l'aggiornamento. L'autopausa deve essere riabilitata manualmente dopo l'aggiornamento a database SQL di Azure Hyperscale.

Contenuti correlati

  • Last updated on