Panoramica del modello di acquisto basato su DTU

Si applica a: Database SQL di Azure

In questo articolo vengono fornite informazioni sul modello di acquisto basato su DTU per Azure SQL database.

Per altre informazioni, esaminare il modello di acquisto basato su vCore e confrontare 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 sono differenziati in base a un intervallo di dimensioni di calcolo con una quantità fissa di archiviazione inclusa, un periodo di conservazione fisso per i backup e un prezzo fisso. Tutti i livelli di servizio nel modello di acquisto basato su DTU offrono flessibilità di modifica delle dimensioni di calcolo con tempi di inattività minimi; Tuttavia, esiste un passaggio nel periodo in cui la connettività viene persa al database per un breve periodo di tempo, che può essere ridotta 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 singolo database con dimensioni di calcolo specifiche all'interno di un livello di servizio, Azure SQL Database garantisce un determinato livello di risorse per tale database (indipendentemente da qualsiasi altro database). Questa garanzia offre un livello prevedibile di prestazioni. La quantità di risorse allocata per un database viene calcolata come numero di DTU ed è una misura in bundle di risorse di calcolo, archiviazione e I/O.

Il rapporto tra queste risorse è originariamente determinato da un carico di lavoro di benchmark OLTP (Online Transaction Processing) progettato per essere tipico dei carichi di lavoro OLTP reali. Quando il carico di lavoro supera la quantità di queste risorse, la velocità effettiva viene limitata, causando prestazioni e timeout più lente.

Per i singoli database, 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.

Rettangolo di selezione

Le DTU sono più utili per comprendere le risorse relative allocate per i database in dimensioni di calcolo e livelli di servizio diversi. Ad esempio:

  • Il raddoppio delle DTU aumentando le dimensioni di calcolo di un database equivale al raddoppio del set di risorse disponibili per tale database.
  • Un database del livello di servizio Premium P11 con 1750 DTU offre 350 volte più potenza di calcolo DTU rispetto a un database di livello di servizio di base con 5 DTU.

Per ottenere informazioni dettagliate sull'utilizzo della risorsa (DTU) del carico di lavoro, usare informazioni dettagliate sulle prestazioni delle query per:

  • Identificare le query principali in base al conteggio cpu/durata/esecuzione che possono potenzialmente essere ottimizzate per migliorare le prestazioni. Ad esempio, una query con utilizzo intensivo di I/O può trarre vantaggio dalle tecniche di ottimizzazione in memoria per migliorare l'uso della memoria disponibile a un determinato livello di servizio e dimensioni di calcolo.
  • Esaminare i dettagli di una query per visualizzarne il testo e la cronologia dell'utilizzo delle risorse.
  • Accedere alle raccomandazioni di ottimizzazione delle prestazioni che mostrano le azioni eseguite da database SQL Advisor.

Unità transazioni di database elastici (eDTU)

Anziché fornire un set dedicato di risorse (DTU) che potrebbero non essere sempre necessarie, è possibile 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 vengono misurate da unità transazioni 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 ampiamente variabili e imprevedibili. Un pool elastico garantisce che tutte le risorse non possano essere usate da un database nel pool, garantendo che ogni database nel pool disponga sempre di una quantità minima di risorse necessarie.

A un pool viene assegnato un numero definito di eDTU per un prezzo prestabilito. Nel pool elastico i singoli database possono ridimensionare automaticamente entro i limiti configurati. Un database con un carico più elevato utilizzerà più eDTU per soddisfare la domanda. I database con carichi più leggeri usano meno eDTU. I database senza alcun carico di lavoro non utilizzeranno eDTU. Poiché le risorse vengono sottoposte a provisioning per l'intero pool, anziché per database, i pool elastici semplificano le attività di gestione e forniscono un budget prevedibile per il pool.

È possibile aggiungere eDTU aggiuntivi a un pool esistente con tempi di inattività minimi del database. Analogamente, se non sono più necessari eDTU aggiuntivi, rimuoverli da un pool esistente in qualsiasi momento. È anche possibile aggiungere database a o rimuovere database da un pool in qualsiasi momento. Per riservare eDTU per altri database, limitare il numero di database eDTU può essere usato in un carico elevato. Se un database ha un utilizzo di risorse costantemente elevato che influisce su altri database nel pool, spostarlo fuori dal pool e configurarlo come singolo database con una quantità prevedibile di risorse necessarie.

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

I pool sono adatti per i database con una media di utilizzo delle risorse ridotta e picchi di utilizzo relativamente frequenti. Per altre informazioni, vedere Quando prendere in considerazione un pool elastico database SQL?

Determinare il numero di DTU necessarie per un carico di lavoro

Se si vuole eseguire la migrazione di un carico di lavoro di macchina virtuale locale o SQL Server esistente in database SQL, vedere Suggerimenti per sku per approssimare il numero di DTU necessarie. Per un carico di lavoro di database SQL esistente, usare informazioni dettagliate sulle prestazioni delle query per comprendere l'utilizzo delle risorse del database e ottenere informazioni dettagliate più approfondite per ottimizzare il carico di lavoro. La sys.dm_db_resource_stats visualizzazione gestione dinamica (DMV) consente di visualizzare l'utilizzo delle risorse per l'ultima ora. La visualizzazione catalogo sys.resource_stats visualizza l'utilizzo delle risorse negli ultimi 14 giorni, ma con una fedeltà inferiore di cinque minuti.

Determinare l'utilizzo di DTU

Per determinare la percentuale media di utilizzo 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 da sys.dm_db_resource_stats, sys.resource_stats e sys.elastic_pool_resource_stats DMV. In altre parole, per determinare la percentuale di utilizzo DTU/eDTU verso il limite DTU/eDTU di un database o di un pool elastico, selezionare il valore percentuale più grande dal seguente: avg_cpu_percent, avg_data_io_percente 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 avg_memory_usage_percent valore in genere sarà vicino al 100% indipendentemente dal carico del database corrente. Pertanto, anche se la memoria influisce indirettamente sul limite DTU, non viene usata nella formula di utilizzo DTU.

Configurazione hardware

Nel modello di acquisto basato su DTU i clienti non possono scegliere la configurazione hardware usata per i propri database. Sebbene un determinato database rimanga in genere su un tipo specifico di hardware per molto tempo (comunemente 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 ridimensionato o ridotto a un obiettivo di servizio diverso oppure 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 della durata.

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

Tuttavia, nell'ampio spettro dei carichi di lavoro dei clienti in esecuzione in Azure SQL Database, l'impatto dell'uso di hardware diverso per lo stesso obiettivo di servizio può essere più pronunciato. Carichi di lavoro diversi possono trarre vantaggio da configurazioni e funzionalità hardware diverse. Pertanto, per i carichi di lavoro diversi dal benchmark DTU, è possibile vedere le differenze di prestazioni se il database passa da un tipo di hardware a un altro.

I clienti possono usare il modello vCore per scegliere la configurazione hardware preferita durante la creazione e la scalabilità del database. Nel modello vCore vengono documentati i limiti dettagliati delle risorse di ogni obiettivo di servizio in ogni configurazione hardware per i singoli database e i pool elastici. Per altre informazioni sull'hardware nel modello vCore, vedere 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.

Basic Standard Premium
Carico di lavoro di destinazione Sviluppo e produzione Sviluppo e produzione Sviluppo e produzione
Contratto di servizio relativo al tempo di attività 99,99% 99,99% 99,99%
Conservazione massima del backup 7 giorni 35 giorni 35 giorni
CPU Basso Basso, medio, elevato Medio, elevato
Operazioni di I/O al secondo (approssimative)* 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)
Indicizzazione ColumnStore N/D S3 e superiore Supportato
OLTP in memoria N/D N/D Supportato

* Tutte le operazioni di I/O in lettura e scrittura sui file di dati, inclusi i/o I/O in background (checkpoint e writer lazy)

Importante

Gli obiettivi di servizio Basic, S0, S1 e S2 forniscono meno di un vCore (CPU). Per i carichi di lavoro a elevato utilizzo della CPU, è consigliabile un obiettivo di servizio di S3 o superiore.

Negli obiettivi di servizio Basic, S0 e S1 i file di database vengono archiviati in Archiviazione Standard di Azure, che usa supporti di archiviazione basati su disco rigido (HDD). Questi obiettivi di servizio sono più adatti per lo sviluppo, il test e altri carichi di lavoro a cui si accede raramente che sono 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 .

Nota

È possibile ottenere un database gratuito in Azure SQL Database al livello di servizio basic in combinazione con un account gratuito di Azure per esplorare Azure. Per informazioni, vedere Crea un database cloud gestito con il tuo account Azure gratuito.

Limiti delle risorse

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

Limiti di archiviazione del database singolo

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, vedere Limiti delle risorse per i singoli database.

Basic Standard Premium
Dimensioni massime di archiviazione 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 in Azure SQL Database.

Limiti del pool elastico

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

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

Importante

Più di 1 TB di archiviazione nel livello Premium sono attualmente disponibili in tutte le aree, ad eccezione: Cina orientale, Cina settentrionale, Germania centrale e 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 spazio file in Azure SQL Database.

Benchmark DTU

Le caratteristiche fisiche (CPU, memoria, I/O) associate a ogni misura DTU vengono calibrate usando un benchmark che simula il carico di lavoro del database reale.

Informazioni sullo schema, sui tipi di transazione usati, sulla combinazione del carico di lavoro, sugli utenti e sulla pacing, sulle regole di ridimensionamento e sulle metriche associate al benchmark DTU.

Confrontare i modelli di acquisto basati su DTU e vCore

Anche se il modello di acquisto basato su DTU si basa su una misura combinata di risorse di calcolo, archiviazione e I/O, confrontando il modello di acquisto vCore per Azure SQL Database 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 costi e offre opzioni serverless e Hyperscale per Azure SQL database non disponibili nel modello di acquisto basato su DTU.

Altre informazioni in Confrontare i modelli di acquisto basati su VCore e DTU di Azure SQL Database.

Passaggi successivi

Altre informazioni sui modelli di acquisto e sui concetti correlati negli articoli seguenti: