Panoramica dei limiti delle risorse di Istanza gestita di SQL di Azure

Si applica a:Istanza gestita di SQL di Azure SQL

Questo articolo offre una panoramica sulle caratteristiche tecniche e sui limiti delle risorse relative all’Istanza gestita di SQL di Azure e fornisce informazioni su come chiedere un aumento di questi limiti.

Caratteristiche di configurazione hardware

Istanza gestita di SQL ha caratteristiche e limiti di risorse che dipendono dall'infrastruttura e dall'architettura sottostanti. L'istanza gestita di SQL può essere implementata in due generazioni hardware.

Le generazioni hardware hanno caratteristiche diverse, descritte nella tabella seguente:

¹ L’implementazione di un'istanza 2-vCore è possibile solo all'interno di un pool di istanze.

² Dipende dal numero di vCore.

³ Solo le aree principali possono fornire 16 TB di spazio di archiviazione. Le aree più piccole limitano l'archiviazione disponibile a 5,5 TB.

Supporto a livello di area per l'hardware della serie Premium ottimizzato per la memoria e per l'hardware della serie Premium con 16-TB di memoria

Il supporto per l'hardware della serie Premium con archiviazione da 16 TB ha la stessa disponibilità del supporto per l'hardware della serie Premium ottimizzato per la memoria. I supporti per l'hardware della serie Premium ottimizzato per la memoria e l'hardware della serie Premium con archiviazione da 16 TB sono attualmente disponibili solo in queste aree specifiche:

Spazio disponibile OLTP in memoria

La quantità di spazio OLTP in memoria nel livello di servizio Business Critical dipende dal numero di vCore e dalla configurazione dell’hardware. La seguente tabella elenca i limiti di memoria che possono essere usati per gli oggetti OLTP in memoria.

Caratteristiche del livello di servizio

Istanza gestita ha due livelli di servizio: per utilizzo generico e business critical. È possibile scegliere di usare il livello di servizio per utilizzo generico di nuova generazione aggiornato (anteprima).

Numero of vCore

¹ L’implementazione di un'istanza 2-vCore è possibile solo all'interno di un pool di istanze.

Memoria massima

¹ Il rapporto tra memoria e vCore è disponibile solo fino a 80 vCore per l'hardware della serie Premium e 64 vCore per la serie Premium ottimizzata per la memoria. La memoria massima è limitata a 560 GB per vCore di serie Premium superiori a 80 e 870,4 GB per vCore della serie Premium ottimizzata per la memoria superiore a 64.

Dimensioni massime archiviazione istanze (riservate)

¹ Solo le aree principali possono fornire 16 TB di spazio di archiviazione per l'hardware della serie Premium per questi numeri di CPU vCore. Le aree più piccole limitano l'archiviazione disponibile a 5,5 TB.

² Solo le aree principali possono fornire 8 TB di spazio di archiviazione per l'hardware ottimizzato per la memoria premium per questi numeri di vCore CPU. Le aree più piccole limitano l'archiviazione disponibile a 5,5 TB.

Confronto delle funzionalità

¹ Questo è un intervallo medio. Anche se la maggior parte delle durate delle richieste di I/O rientra nella parte superiore dell'intervallo, gli outlier che superano l'intervallo sono possibili.

Considerazioni aggiuntive

• Per calcolare le dimensioni dello spazio di archiviazione delle istanze attualmente disponibile è sufficiente fare la differenza tra le dimensioni dell'istanza riservata e lo spazio di archiviazione usato.

• La dimensione di archiviazione dell'istanza, che viene confrontata con la dimensione massima di archiviazione, include la dimensione dei dati e dei file di log presenti sia nel database utenti che in quello di sistema. Usare la vista di sistema sys.master_files per determinare lo spazio totale usato dai database. I log degli errori non vengono salvati in modo permanente e non sono inclusi nella dimensione. I backup non sono inclusi nella dimensione di archiviazione.

• Nel livello Utilizzo generico, anche il numero di IOPS e la velocità effettiva dipendono dalle dimensioni del file e non sono limitati in modo esplicito da Istanza gestita di SQL.

• Il numero massimo di IOPS dell'istanza dipende dal layout del file e dalla distribuzione del carico di lavoro. Se, ad esempio, si creano 7 file da 1 TB, ciascuno con 5000 operazioni di I/O al secondo, e sette piccoli file (inferiori a 128 GB), ciascuno con 500 operazioni di I/O al secondo, è possibile ottenere 38500 operazioni di I/O al secondo per istanza (7 x 5000 + 7 x 500), se il carico di lavoro può usare tutti i file. Alcune operazioni di I/O al secondo vengono usate anche per i backup automatici.

• Usando i gruppi di failover, è possibile creare un'altra replica leggibile in un'area di Azure diversa

• I nomi dei file tempdb non possono contenere più di 16 caratteri.

Per altre informazioni sui limiti delle risorse nei pool di istanze gestite di SQL, si veda questo articolo.

IOPS

Per i livelli di servizio Utilizzo generico di seconda generazione e Business Critical, le operazioni di I/O al secondo disponibili sono dettate dal numero di vCore:

• Livello di servizio Utilizzo generico di nuova generazione: valore fisso delle operazioni di I/O al secondo in base al numero di vCore. Il prezzo dell'archiviazione include le operazioni di I/O al secondo minime. Se si supera il valore minimo, vengono addebitati i costi seguenti: 1 operazioni di I/O al secondo = prezzo di archiviazione (per area) diviso per tre. Ad esempio, se 1 GB di costi di archiviazione 0,115, al 1 operazioni di I/O al secondo = 0,115/3 = 0,038 per operazioni di I/O al secondo.
• Livello di servizio Business Critical: usa una formula (4000 IOPS/vCore) per determinare i limiti delle operazioni di I/O al secondo.

La seguente tabella elenca il numero massimo di operazioni di I/O al secondo disponibili per ogni livello di servizio in base al numero di vCore:

Caratteristiche di I/O dei file nel livello Utilizzo generico

Nel livello di servizio Utilizzo generico, ogni file di database ottiene una quantità di IOPS e di velocità effettiva dedicata in base alle dimensioni stesse del file. I file più grandi ottengono più operazioni di I/O al secondo e velocità effettiva. Nella tabella seguente sono illustrate le caratteristiche di I/O dei file di database:

Se si nota una latenza di I/O elevata per un file di database o si scopre che il rapporto IOPS/velocità effettiva sta raggiungendo il limite, è possibile migliorare le prestazioni aumentando le dimensioni del file.

Esiste anche un limite a livello di istanza per la velocità effettiva massima delle operazioni di scrittura nel log ( si veda la tabella precedente per i valori, ad esempio 22 MiB/s). È quindi possibile che non si riesca a raggiungere la velocità effettiva massima del file nel file di log perché si raggiunge il limite di velocità effettiva dell'istanza.

Archiviazione di dati e log

I seguenti fattori influiscono sulla quantità di spazio di archiviazione usato per i file di dati e di log e si applicano ai livelli General Purpose e Business Critical.

• Nel livello di servizio General Purpose tempdb usa un'unità SSD collegata e il costo di archiviazione è incluso nel prezzo di vCore.
• Nel livello di servizio Business Critical tempdb condivide l'unità SSD collegata con i file di log e il costo di archiviazione di tempdb è incluso nel prezzo di vCore.
• Le dimensioni di archiviazione massime per Istanza gestita di SQL devono essere specificate in multipli di 32 GB.

Per monitorare le dimensioni totali di archiviazione delle istanze utilizzate per Istanza gestita di SQL, usare storage_space_used_mb come metrica. Per monitorare le dimensioni di archiviazione correnti allocate e usate dei singoli file di dati e di log in un database tramite T-SQL, usare la vista sys.database_files e la funzione FILEPROPERTY(... , 'SpaceUsed').

Backup e archiviazione

Lo spazio di archiviazione per i backup di database viene allocato per supportare le funzionalità di ripristino temporizzato (PITR) e di conservazione a lungo termine (LTR) dell’ Istanza gestita di SQL. Questa risorsa di archiviazione è separata dall'archiviazione di dati e file di log e viene fatturata separatamente.

• PITR: nei livelli Per utilizzo generico e Business Critical, i backup dei singoli database vengono copiati automaticamente in un’archiviazione con ridondanza geografica con accesso in lettura (RA-GRS). Le dimensioni di archiviazione aumentano dinamicamente con la creazione di nuovi backup. Lo spazio di archiviazione viene usato da backup completi, backup differenziali e backup dei log delle transazioni. L'utilizzo dello spazio di archiviazione dipende dalla frequenza con cui vengono apportate modifiche al database e dal periodo di conservazione configurato per i backup. È possibile configurare un periodo di conservazione separato per ogni database compreso tra 1 e 35 giorni per Istanza gestita di SQL. La quantità di archiviazione di backup equivalente alle dimensioni del database viene fornita senza addebiti aggiuntivi.

• Conservazione a lungo termine: si ha l’opzione di configurare la conservazione a lungo termine dei backup completi per un massimo di 10 anni. Se configuri i criteri di conservazione a lungo termine, questi backup vengono archiviati automaticamente in Archiviazione RA-GRS, ma puoi controllare la frequenza con cui vengono copiati. A seconda dei vari requisiti di conformità, puoi selezionare periodi di conservazione diversi per i backup settimanali, mensili e/o annuali. La configurazione scelta determina la quantità di spazio di archiviazione usato per i backup con conservazione a lungo termine. Per altre informazioni, vedere conservazione a lungo termine - Database SQL di Azure e Istanza gestita di SQL di Azure.

Aree geografiche supportate

Le istanze gestite di SQL possono essere create solo in aree supportate. Per creare un'istanza gestita di SQL in un'area attualmente non supportata, è possibile inviare una richiesta di supporto tramite il portale di Azure.

Tipi di sottoscrizioni supportati

Istanza gestita di SQL supporta attualmente solo la distribuzione dei tipi di sottoscrizioni seguenti:

• Contratto Enterprise
• Pagamento in base al consumo
• Provider di servizi cloud (CSP)
• Sviluppo/test Enterprise
• Sviluppo/test con pagamento in base al consumo
• Sottoscrizioni con il credito Azure mensile per i titolari di sottoscrizioni di Visual Studio
• Versione di prova gratuita
• Azure for Students
• Azure In Open

Limiti delle risorse a livello di area

I tipi di sottoscrizioni supportati possono contenere un numero limitato di risorse per area. L'istanza gestita prevede due limiti predefiniti per ogni area di Azure, che possono essere aumentati su richiesta creando una speciale richiesta di supporto nel portale di Azure a seconda del tipo di sottoscrizione:

• Limite di subnet: numero massimo di subnet in cui vengono distribuite le istanze gestite di SQL in una singola area.
• Limite di unità vCore:il numero massimo di unità vCore che possono essere distribuite in tutte le istanze di una singola area. Un vCore di Utilizzo generico usa un'unità vCore, mentre un vCore Business Critical accetta quattro unità vCore. Il numero totale di istanze non è limitato a condizione che sia entro il limite di unità vCore.

La seguente tabella seguente illustra i limiti predefiniti a livello di area per i tipi di sottoscrizione supportati (i limiti predefiniti possono essere estesi usando una richiesta di supporto):

¹ Nella pianificazione delle distribuzioni, prendere in considerazione che il livello di servizio Business Critical (BC) richiede quattro (4) volte più capacità vCore rispetto al livello di servizio Utilizzo generico (GP). Ad esempio: 1 vCore GP = 1 unità vCore e 1 vCore BC = 4 vCore. Per semplificare l'analisi del consumo in base ai limiti predefiniti, riepilogare le unità vCore in tutte le subnet nell'area in cui vengono distribuite le istanze gestite di SQL e confrontare i risultati con i limiti di unità di istanza per il tipo di sottoscrizione. Il numero massimo di unità vCore si applica a ogni sottoscrizione presente in un'area. Non esistono limiti per singole subnet, ad eccezione del fatto che la somma di tutti i vCore distribuiti tra più subnet deve essere inferiore o uguale al numero massimo di unità vCore.

² Limiti di subnet e vCore più grandi sono disponibili nelle aree seguenti: Australia orientale, Stati Uniti orientali 2, Europa settentrionale, Stati Uniti centro-meridionali, Asia sud-orientale, Regno Unito meridionale, Europa occidentale, Stati Uniti occidentali 2.

Richiedere un aumento della quota

Se servono più istanze nelle aree correnti, è possibile inviare una richiesta di supporto per estendere la quota tramite il portale di Azure. Per altre informazioni, vedere Aumento della quota di richieste per il database SQL di Azure e Istanza gestita di SQL.

Contenuto correlato

• Che cos'è Istanza gestita di SQL di Azure?
• prezzi di Istanza gestita di SQL
• la guida introduttiva
• Contratto di servizio per Istanza gestita di SQL di Azure