Informazioni generali sul modello di acquisto basato su DTU

Si applica a: database SQL di Azure

Questo articolo illustra il modello di acquisto basato su DTU per database SQL di Azure.

Per altre informazioni, vedi il modello di acquisto basato su vCore e confronta i modelli di acquisto.

Unità di transazione di database (DTU)

L'unità di transazione di database (Data Transmission Unit, DTU) rappresenta una misura combinata di CPU, memoria e operazioni di lettura e scrittura. I livelli di servizio nel modello di acquisto basato su DTU si differenziano in base a diverse dimensioni di calcolo con una quantità fissa di risorse di archiviazione, un periodo di conservazione fisso per i backup e un prezzo fisso inclusi. Tutti i livelli di servizio nel modello di acquisto basato su DTU offrono flessibilità di modifica delle dimensioni di calcolo con tempo inattivo minimo. Tuttavia, esiste un passaggio nel periodo in cui la connettività al database viene persa per un breve periodo di tempo, il che può essere mitigato usando la logica di ripetizione dei tentativi. La fatturazione per i database singoli e i pool elastici viene effettuata con frequenza oraria in base al livello di servizio e alle dimensioni di calcolo.

Per un database singolo con dimensioni di calcolo specifiche all'interno di un livello di servizio, il database SQL di Azure garantisce un certo livello di risorse per il database (a prescindere da qualsiasi altro database). Questa garanzia garantisce un livello prevedibile di prestazioni. Il numero di risorse assegnate a un database viene calcolato come numero di DTU ed è una misura aggregata delle risorse di calcolo, archiviazione e I/O.

Il rapporto tra queste risorse è stato originariamente stabilito da un carico di lavoro di benchmark di elaborazione di transazioni online (OLTP) progettato per essere rappresentativo dei carichi di lavoro OLTP reali. Quando il carico di lavoro supera la quantità di una di queste risorse, la produttività viene limitata, generando timeout e prestazioni più lente.

Per i database singoli, le risorse usate dal carico di lavoro non influiscono sulle risorse disponibili per altri database nel cloud di Azure. Analogamente, le risorse usate da altri carichi di lavoro non influiscono sulle risorse disponibili per il database.

Le DTU sono particolarmente utili per comprendere la quantità relativa di risorse assegnate ai database con diverse dimensioni di calcolo e livelli di servizio. Ad esempio:

• Ad esempio, raddoppiare le DTU aumentando le dimensioni di calcolo di un database equivale a raddoppiare il set di risorse disponibili per quel database.
• Un database di livello di servizio Premium P11 con 1750 DTU fornisce 350 volte più potenza di calcolo DTU di un database di livello di servizio Basic con 5 DTU.

Per ottenere maggiori dettagli sul consumo di risorse (DTU) del carico di lavoro, usa le informazioni dettagliate sulle prestazioni delle query per:

• Identificare le query principali a livello di CPU/durata/conteggio delle esecuzioni, che possono essere potenzialmente ottimizzate per migliorare le prestazioni. Una query con uso intensivo dell'I/O, ad esempio, può trarre vantaggio dall'uso di tecniche di ottimizzazione in memoria per usare in modo più efficiente la memoria disponibile per un livello di servizio e dimensioni di calcolo specifici.
• Eseguire il drill-down dei dettagli di una query, visualizzarne il testo e la cronologia di uso della risorsa.
• Visualizzare i consigli relativi all'ottimizzazione delle prestazioni che descrivono le azioni eseguite da Advisor per database SQL.

Unità di transazione di database elastico (eDTU)

Anziché fornire un set dedicato di risorse (DTU) che potrebbero non essere sempre necessarie, puoi inserire questi database in un pool elastico. I database in un pool elastico usano una singola istanza del motore di database e condividono lo stesso pool di risorse.

Le risorse condivise in un pool elastico sono misurate dalle unità di transazione di database elastiche (eDTU). I pool elastici offrono una soluzione semplice e conveniente per gestire gli obiettivi di prestazioni per più database con modelli di utilizzo estremamente mutevoli e imprevedibili. Un pool elastico garantisce che le risorse non possano essere consumate da un solo database nel pool, assicurando allo stesso tempo che per ogni database del pool sia sempre disponibile una quantità minima di risorse necessaria.

A un pool viene assegnato un numero definito di eDTU per un prezzo prestabilito. Nel pool elastico, i singoli database possono assicurare la scalabilità automatica nell'ambito di limiti configurati. Un database con un carico di lavoro più importante utilizzerà più eDTU per soddisfare la domanda. I database con carichi più leggeri consumeranno meno eDTU. I database senza alcun carico di lavoro non consumeranno eDTU. Effettuando il provisioning delle risorse per l'intero pool e non per i singoli database, i pool elastici semplificano i task di gestione e forniscono un budget prevedibile per il pool.

Puoi aggiungere altre eDTU a un pool esistente con tempo inattivo minimo del database. Analogamente, se le eDTU aggiuntive non sono più necessarie, puoi rimuoverle da un pool esistente in qualsiasi momento. Puoi aggiungere o rimuovere database in un pool in qualsiasi momento. Per riservare eDTU per altri database, limitare il numero di database eDTU che possono essere usati con un carico elevato. Se un database ha un utilizzo delle risorse costantemente elevato che influisce su altri database nel pool, spostarlo all'esterno del pool e configurarlo come database singolo con una quantità prevedibile di risorse necessarie.

Carichi di lavoro che traggono vantaggio da un pool elastico di risorse

I pool sono particolarmente adatti per i database con una media di utilizzo delle risorse ridotta e picchi di utilizzo relativamente poco frequenti. Per ulteriori informazioni, vedi quando considerare un pool elastico del database SQL?.

Determinare il numero di DTU necessarie per un carico di lavoro

Se si intende eseguire la migrazione di un carico di lavoro di macchine virtuali locali esistenti o di SQL Server a un database SQL di Azure, vedi consigli SKU per simulare il numero di DTU necessarie. Per un carico di lavoro esistente del database SQL, usa le informazioni dettagliate sulle prestazioni delle query per conoscere il consumo di risorse di database (DTU) e ottenere dati analitici più approfonditi per l'ottimizzazione del carico di lavoro. È anche possibile usare la DMV sys.dm_db_ resource_stats per visualizzare il consumo di risorse per l'ultima ora. La vista del catalogo sys.resource_stats visualizza il consumo di risorse per gli ultimi 14 giorni, ma a una fedeltà inferiore di medie di cinque minuti.

Determinare l'utilizzo di DTU

Per determinare la percentuale media di utilizzo di DTU/eDTU rispetto al limite DTU/eDTU di un database o di un pool elastico, usare la formula seguente:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

I valori di input per questa formula possono essere ottenuti dalle DMV sys.dm_db_resource_stats, sys.resource_stats e sys.elastic_pool_resource_stats. In altre parole, per determinare la percentuale di utilizzo di DTU/eDTU per il limite DTU/eDTU di un database o di un pool elastico, prelevare il valore percentuale più grande dal seguente: avg_cpu_percent, avg_data_io_percent e avg_log_write_percent in un determinato momento.

Nota

Il limite DTU di un database è determinato da CPU, letture, scritture e memoria disponibili per il database. Tuttavia, poiché il motore di database SQL usa in genere tutta la memoria disponibile per la cache dei dati per migliorare le prestazioni, il valore avg_memory_usage_percent in genere sarà vicino al 100%, indipendentemente dal carico corrente del database. Pertanto, anche se la memoria influisce indirettamente sul limite DTU, non viene usata nella formula di utilizzo di DTU.

Configurazione hardware

Nel modello di acquisto basato su DTU, i clienti non possono scegliere la configurazione hardware usata per i database. Anche se un determinato database rimane in genere su un tipo specifico di hardware per molto tempo (in genere per più mesi), esistono alcuni eventi che possono causare lo spostamento di un database in hardware diverso.

Ad esempio, un database può essere spostato in hardware diverso se viene aumentato o ridimensionato fino a un oggetto assistenza diverso o se l'infrastruttura corrente in un data center sta raggiungendo i limiti di capacità o se l'hardware attualmente usato viene rimosso a causa della fine del ciclo di vita.

Se un database viene spostato in hardware diverso, le prestazioni del carico di lavoro possono cambiare. Il modello DTU garantisce che la produttività e il tempo di risposta del carico di lavoro del benchmark DTU rimangano sostanzialmente identici quando il database passa a un tipo di hardware diverso, purché l'oggetto assistenza (il numero di DTU) rimanga invariato.

Tuttavia, nell'ampio spettro dei carichi di lavoro della società in esecuzione nel database SQL di Azure, l'impatto dell'uso di hardware diverso per lo stesso oggetto assistenza può essere più pronunciato. Diversi carichi di lavoro possono trarre vantaggio da diverse configurazioni hardware e caratteristiche. Pertanto, per i carichi di lavoro diversi dal benchmark DTU, è possibile visualizzare le differenze di prestazioni se il database passa da un tipo di hardware a un altro.

Le società possono usare il modello vCore per scegliere la configurazione hardware preferita durante la creazione e il ridimensionamento del database. Nel modello vCore i limiti dettagliati delle risorse di ogni oggetto assistenza in ogni configurazione hardware sono documentati per database singoli e pool elastici. Per altre informazioni sull'hardware nel modello vCore, vedi Configurazione hardware per database SQL o Configurazione hardware per Istanza gestita di SQL.

Confrontare i livelli di servizio

La scelta di un livello di servizio dipende soprattutto dai requisiti in termini di continuità aziendale, archiviazione e prestazioni.

	Di base	Standard	Premium
Carico di lavoro obiettivo	Sviluppo e produzione	Sviluppo e produzione	Sviluppo e produzione
Tempo di attività del contratto di servizio	99,99%	99,99%	99,99%
Backup	Una scelta di archivio di backup con ridondanza geografica, con ridondanza della zona o con ridondanza locale, conservazione di 1-7 giorni (impostazione predefinita 7 giorni) Conservazione a lungo termine disponibile fino a 10 anni	Una scelta di archivio di backup con ridondanza geografica, con ridondanza della zona o con ridondanza locale, conservazione di 1-35 giorni (impostazione predefinita 7 giorni) Conservazione a lungo termine disponibile fino a 10 anni	Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS) Conservazione da 1 a 35 giorni (7 giorni per impostazione predefinita), con un massimo di 10 anni di conservazione a lungo termine disponibile
CPU	Basso	Basso, medio, elevato	Medio, Alto
Operazioni di I/O al secondo (circa)*	1-4 operazioni di I/O al secondo per DTU	1-4 operazioni di I/O al secondo per DTU	>25 operazioni di I/O al secondo per DTU
Latenza di I/O (approssimativa)	5 ms (lettura), 10 ms (scrittura)	5 ms (lettura), 10 ms (scrittura)	2 ms (lettura/scrittura)
Indice ColumnStore	N/D	Standard S3 e versioni successive	Supportata
OLTP in memoria	N/D	N/D	Supportata

* Tutte le operazioni di I/O di lettura e scrittura su file di dati, incluse operazioni di I/O sullo sfondo (checkpoint e Lazywriter).

Importante

Gli oggetti assistenza Basic, S0, S1 e S2 offrono meno di un vCore (CPU). Per i carichi di lavoro a elevato utilizzo di CPU, è consigliabile usare un oggetto assistenza S3 o superiore.

Negli oggetti assistenza Basic, S0 e S1, i file di database vengono archiviati in Archiviazione Standard di Azure, che usa supporti di archiviazione basati su unità disco rigido (HDD). Questi oggetti assistenza sono più adatti per lo sviluppo, il test e altri carichi di lavoro con accesso non frequente e meno sensibili alla variabilità delle prestazioni.

Suggerimento

Per visualizzare i limiti effettivi di governance delle risorse per un database o un pool elastico, eseguire una query sulla visualizzazione sys.dm_user_db_resource_governance . Per un database singolo, viene restituita una riga. Per un database in un pool elastico, viene restituita una riga per ogni database nel pool.

Nota

Puoi ottenere un database gratuito nel database SQL di Azure al livello di servizio Basic con un account Azure gratuito. Per informazioni, vedere Crea un database cloud gestito con il tuo account Azure gratuito.

Limiti delle risorse

I limiti delle risorse differiscono per database singoli e in pool.

Limiti di archiviazione di database singolo

Nel database SQL di Azure, le dimensioni di calcolo per i database singoli sono espresse in unità di transazione di database (DTU), quelle per i pool elastici sono espresse in unità di transazione di database elastico (eDTU). Per altre informazioni, vedi Limiti delle risorse per database singoli.

	Di base	Standard	Premium
Dimensioni di archiviazione massime	2 GB	1 TB	4 TB
DTU massime	5	3000	4000

Importante

In alcune circostanze, può essere necessario compattare un database per recuperare spazio inutilizzato. Per altre informazioni, vedere Gestire lo spazio file nel database SQL di Azure.

Limiti del pool elastico

Per altre informazioni, vedi Limiti delle risorse per i database in pool.

	Base	Standard	Premium
Dimensioni di archiviazione massime per database	2 GB	1 TB	1 TB
Dimensioni di archiviazione massime per pool	156 GB	4 TB	4 TB
eDTU massime per database	5	3000	4000
eDTU massime per pool	1600	3000	4000
Numero massimo di database per pool	500	500	100

Importante

Nel livello Premium è attualmente disponibile più di 1 TB di spazio di archiviazione in tutte le aree ad eccezione delle seguenti: Cina orientale, Cina settentrionale, Germania centrale, Germania nord-orientale. In queste aree la quantità massima di spazio di archiviazione nel livello Premium è limitata a 1 TB. Per altre informazioni, vedere le limitazioni correnti di P11 e P15.

Importante

In alcune circostanze, può essere necessario compattare un database per recuperare spazio inutilizzato. Per altre informazioni, vedere Gestire lo spazio file nel database SQL di Azure.

Benchmark DTU

Le caratteristiche fisiche (CPU, memoria, IO) associate a ciascuna misura DTU vengono calibrate usando un benchmark che simula il carico di lavoro di database reali.

Informazioni sullo schema, i tipi di transazione utilizzati, la combinazione di carichi di lavoro, gli utenti e il passo, le regole di ridimensionamento e le metriche associate al benchmark DTU.

Confrontare i modelli di acquisto basati su vCore e DTU

Anche se il modello di acquisto basato su DTU si basa su una misura in bundle di risorse di calcolo, archiviazione e I/O, confrontando il modello di acquisto vCore per database SQL di Azure consente di scegliere e ridimensionare in modo indipendente le risorse di calcolo e archiviazione.

Il modello di acquisto basato su vCore consente anche di usare Vantaggio Azure Hybrid per SQL Server per risparmiare sui costi e offre opzioni serverless e Hyperscale per database SQL di Azure non disponibili nel modello di acquisto basato su DTU.

Altre informazioni in Confronta modelli di acquisto basati su vCore e DTU del database SQL di Azure.

Passaggi successivi

Altre informazioni sui modelli di acquisto e sui concetti correlati sono disponibili nei seguenti articoli:

• Per informazioni dettagliate sulle dimensioni di calcolo specifiche e sulle opzioni relative alle dimensioni di archiviazione disponibili per database singoli, vedere Limiti delle risorse basate su DTU del database SQL per database singoli.
• Per informazioni dettagliate sulle dimensioni di calcolo specifiche e sulle opzioni relative alle dimensioni di archiviazione disponibili per i pool elastici, vedere Limiti delle risorse basate su DTU del database SQL.
• Per informazioni sul benchmark associato al modello di acquisto basato su DTU, vedi benchmark DTU.
• Confrontare i modelli di acquisto basati su vCore e DTU del database SQL di Azure.