Dimensionare dinamicamente le risorse del database con tempi di inattività minimi – database SQL di Azure e Istanza gestita di SQL di Azure

Si applica a:database SQL di AzureIstanza gestita di SQL di Azure

database SQL di Azure e Istanza gestita di SQL di Azure consentono di aggiungere in modo dinamico altre risorse al database con tempi di inattività minimi. Vi è tuttavia un periodo di passaggio in cui la connettività viene persa al database per una breve quantità di tempo, il che può essere mitigato usando la logica di ripetizione dei tentativi.

Panoramica

Quando la domanda per la tua app cresce da qualche dispositivo e qualche cliente al milione di richieste, il database SQL di Azure e Istanza gestita di SQL vengono ridimensionati immediatamente, con tempi di inattività minimi. La scalabilità è una delle caratteristiche più importanti del modello platform-as-a-service (PaaS) che consente di aggiungere in modo dinamico altre risorse al servizio quando necessario. database SQL di Azure consente di modificare facilmente le risorse allocate per i database (potenza della CPU, memoria, velocità effettiva IO e storage).

È possibile limitare i problemi di prestazione, causati da un maggiore utilizzo dell'applicazione, che non possono essere risolti utilizzando l'indicizzazione o con i metodi di query. L'aggiunta di altre risorse consente di una reazione rapida quando il database raggiunge i limiti delle risorse correnti e richiede più energia per gestire il carico di lavoro in ingresso. database SQL di Azure consente inoltre di ridurre le risorse non necessarie all'abbassamento dei costi.

Non è necessario acquistare un hardware o modificare o l'infrastruttura di base. Il ridimensionamento di un database può essere eseguito con facilità tramite il portale di Azure usando un dispositivo di scorrimento.

Il database SQL di Azure offre il Modello di acquisto basato su DTU e il modello di acquisto basato su vCore, mentre Istanza gestita di SQL di Azure offre solo il modello di acquisto basato su vCore.

• Il modello di acquisto basato su DTU offre un insieme di risorse di calcolo, memoria e risorse I/O in tre livelli di servizio per supportare carichi di lavoro di database da leggeri a pesanti: Basic, Standard e Premium. I livelli delle prestazioni di ogni livello forniscono una diversa combinazione di queste risorse, a cui è possibile aggiungere altre risorse di archiviazione.
• Il modello di acquisto basato su vCore consente di scegliere il numero di vCore, la quantità di memoria e la quantità e la velocità della risorsa di archiviazione. Questo modello di acquisto offre tre livelli di servizio: per utilizzo generico, business critical e Hyperscale.

Il livello di servizio, il livello di calcolo e i limiti delle risorse per un database, un pool elastico o un'istanza gestita possono essere modificati in qualsiasi momento. Ad esempio, è possibile creare la prima app in un database singolo usando il livello di elaborazione serverless e quindi modificare il livello di servizio manualmente o a livello di codice in qualsiasi momento, passando al livello di servizio con clausola, per soddisfare le esigenze della soluzione.

Nota

Le eccezioni rilevanti in cui non è possibile modificare il livello di servizio di un database sono:

• I database che usano funzionalità che sono solo disponibili nei livelli di servizio Business Critical/Premium non possono essere modificati per usare il livello di servizio di Utilizzo generico/Standard. Attualmente, l'unica funzionalità di questo tipo è OLTP in memoria.
• Non è possibile eseguire la migrazione dei database creati in origine nel livello di servizio Hyperscale ad altri livelli di servizio. Se si esegue la migrazione di un database esistente in database SQL di Azure al livello di servizio Hyperscale, è possibile eseguire la migrazione inversa al livello di servizio Per utilizzo generico entro 45 giorni dalla migrazione originale a Hyperscale. Se si vuole eseguire la migrazione del database a un altro livello di servizio, ad esempio Business Critical, bisogna prima invertire la migrazione al livello di servizio Per utilizzo generico e poi eseguire un'ulteriore migrazione. Per altre informazioni, vedere Come invertire la migrazione da Hyperscale.

È possibile rettificare le risorse allocate al database modificando l'obiettivo del servizio o facendo un ridimensionamento, per soddisfare le esigenze del carico di lavoro. Ciò consente anche di pagare solo per le risorse necessarie, quando sono necessarie. Fare riferimento alla nota sul potenziale impatto che un'operazione di ridimensionamento potrebbe avere su un'applicazione.

database SQL di Azure offre la capacità di ridimensionare in modo dinamico i database:

• Con un Database singolo è possibile usare sia i modelli DTU o vCore per definire la quantità massima di risorse che verranno assegnate a ogni database.
• I pool elastici consentono di definire il limite massimo di risorse per ogni gruppo di database nel pool.

Istanza gestita di SQL di Azure consente di ridimensionare anche:

• Istanza gestita di SQL usa la modalità vCore e consente di definire il numero massimo di core CPU e la quantità massima di memoria allocata all'istanza. Tutti i database all'interno dell'istanza condivideranno le risorse allocate all'istanza.

Suggerimento

Il ridimensionamento dinamico consente ai clienti di modificare manualmente o a livello di codice l'assegnazione delle risorse. La capacità di ridimensionamento dinamico è disponibile per tutte le risorse di database SQL di Azure e Istanza gestita di SQL di Azure.

Oltre a supportare il ridimensionamento dinamico, il livello Serverless in database SQL di Azure supporta il ridimensionamento automatico. I database nel livello Serverless ridimensionano automaticamente le risorse all'interno di un intervallo specificato dal cliente, in base alle esigenze del carico di lavoro. Non è necessaria alcuna azione da parte del cliente per ridimensionare il database.

Impatto delle operazioni di aumento o riduzione delle prestazioni

L'avvio di un'azione di aumento o riduzione delle risorse, in qualsiasi delle versioni menzionate sopra, riavvia il processo del motore di database e lo sposta in una macchina virtuale diversa, se necessario. Lo spostamento del processo del motore di database in una nuova macchina virtuale è un processo online durante il quale è possibile continuare a usare il servizio del database SQL di Azure esistente. Quando il motore di database di destinazione è pronto per elaborare le query, le connessioni aperte al motore di database corrente verranno terminate e verrà eseguito il rollback delle transazioni di cui non è stato eseguito il commit. Verranno effettuate nuove connessioni al motore di database di destinazione.

Nota

Non è consigliabile ridimensionare l'istanza gestita se è in esecuzione una transazione con esecuzione prolungata, ad esempio l'importazione di dati, processi di elaborazione dati, ricompilazione dell'indice e così via, o se si dispone di una connessione attiva nell'istanza. Per evitare che il ridimensionamento richieda un tempo superiore al solito per il completamento, è consigliabile ridimensionare l'istanza al completamento di tutte le operazioni a esecuzione prolungata.

Nota

È possibile prevedere una breve interruzione della connessione al termine del processo di aumento/riduzione. Se è stata implementata la logica di ripetizione dei tentativi per gli errori temporanei standard, non si noterà il failover.

Metodi alternativi di scalabilità

Ridimensionare le risorse è il modo più semplice ed efficace per migliorare le prestazioni del database senza modificare il codice del database o dell'applicazione. In alcuni casi, anche i livelli di servizio, le dimensioni di calcolo e le ottimizzazioni delle prestazioni più elevati potrebbero non riuscire a gestire il carico di lavoro in modo corretto e conveniente. In questo caso, si dispone delle seguenti opzioni aggiuntive per ridimensionare il database:

• La Scalabilità in lettura è una funzionalità che consente di ottenere una replica di sola lettura dei dati e per la quale è possibile eseguire query di sola lettura, come ad esempio report complessi. Una replica di sola lettura gestirà il carico di lavoro di sola lettura senza influire sull'utilizzo delle risorse nel database primario.
• Il Partizionamento di database è un set di tecniche che consente di dividere i dati in diversi database e di ridimensionarli in modo indipendente.

Passaggi successivi

• Per informazioni su come migliorare le prestazioni del database tramite la modifica del codice del database, vedere Trovare e applicare raccomandazioni per le prestazioni.
• Per informazioni su come consentire alle intelligence integrate nel database di ottimizzare il database, vedere Ottimizzazione automatica.
• Per informazioni sulla Scalabilità in lettura in database SQL di Azure, vedere come usare le repliche di sola lettura per bilanciare i carichi di lavoro di query di sola lettura.
• Per informazioni sul Partizionamento del database, vedere Aumento del numero di istanze con il database SQL di Azure.
• Per un esempio di uso di script per monitorare e ridimensionare un database singolo, vedere Usare PowerShell per monitorare e ridimensionare un singolo database SQL.