Modello di acquisto vCore - Database SQL di Azure

Si applica a: database SQL di Azure

Questo articolo esamina il modello di acquisto vCore per il database SQL di Azure.

Panoramica

Una memoria centrale virtuale (vCore) rappresenta la CPU logica e ti offre la possibilità di scegliere le caratteristiche fisiche dell’hardware (ad esempio numero di core, memoria e spazio di archiviazione). Il modello di acquisto basato su vCore ti offre flessibilità, controllo, trasparenza nell'uso individuale delle risorse e un metodo diretto per convertire i requisiti dei carichi di lavoro locali nel cloud. Questo modello ottimizza i costi e ti consente di scegliere le risorse di calcolo, memoria e archiviazione in base ai requisiti dei carichi di lavoro.

Nel modello di acquisto basato su vCore i costi dipendono dalla scelta e dall'utilizzo di:

• Livello di servizio
• Configurazione hardware
• Risorse di calcolo (il numero di vCore e la quantità di memoria)
• Archivio di database riservato
• Archivio di backup effettivo

Confronto tra modelli di acquisto vCore e DTU

Il modello di acquisto vCore usato dal database SQL di Azure offre diversi vantaggi rispetto al modello di acquisto basato su DTU:

• Limiti di calcolo, memoria, I/O e archiviazione superiori.
• Scelta della configurazione hardware per soddisfare meglio i requisiti di calcolo e memoria del carico di lavoro.
• Sconto sui prezzi per Vantaggio Azure Hybrid (AHB).
• Maggiore trasparenza nei dettagli hardware che alimentano il calcolo, il che facilita la pianificazione delle migrazioni dalle distribuzioni locali.
• I prezzi delle istanze riservate sono disponibili solo per il modello di acquisto vCore.
• Maggiore granularità di dimensionamento con più dimensioni di calcolo disponibili.

Per informazioni sulla scelta tra i modelli di acquisto vCore e DTU, vedi le differenze tra i modelli di acquisto basati su vCore e DTU

Calcolo

Il modello di acquisto basato su vCore ha un livello di calcolo con provisioning e un livello di calcolo serverless. Nel livello di calcolo con provisioning, il costo del calcolo riflette la capacità di calcolo totale di cui viene eseguito il provisioning continuo per l'applicazione, indipendentemente dall'attività del carico di lavoro. Scegli l'allocazione delle risorse più adatta alle esigenze aziendali in base ai requisiti di vCore e memoria, quindi aumenta e riduci le risorse in base alle esigenze del carico di lavoro. Nel livello di calcolo serverless per il database SQL di Azure, le risorse di calcolo vengono dimensionate automaticamente in base alla capacità del carico di lavoro e fatturate in base alla quantità di risorse di calcolo usata, al secondo.

Per concludere:

• Mentre il livello di calcolo con provisioning fornisce una quantità specifica di risorse di calcolo di cui viene eseguito il provisioning continuo indipendentemente dall'attività del carico di lavoro, il livello di calcolo serverlessidimensiona automaticamente le risorse di calcolo in base all'attività del carico di lavoro.
• Mentre il livello di calcolo con provisioning emette fattura per la quantità di calcolo di cui viene eseguito il provisioning a un prezzo fisso all'ora, il livello di calcolo serverless emette fattura per la quantità di calcolo usata, al secondo.

Indipendentemente dal livello di calcolo, tre repliche secondarie a disponibilità elevata aggiuntive vengono allocate automaticamente nel livello di servizio Business Critical per offrire resilienza elevata agli errori e ai failover rapidi. Queste repliche aggiuntive rendono il costo di circa 2,7 volte superiore rispetto al livello di servizio Per utilizzo generico. Allo stesso modo, il costo di archiviazione per GB più alto nel livello di servizio Business Critical riflette i limiti di I/O più elevato e la latenza più bassa della risorsa di archiviazione SSD locale.

In Hyperscale, i clienti controllano il numero di repliche a disponibilità elevata aggiuntive da 0 a 4 per ottenere il livello di resilienza richiesto dalle applicazioni controllando i costi.

Per altre informazioni sul calcolo nel database SQL di Azure, vedi Risorse di calcolo (CPU e memoria).

Limiti delle risorse

Per i limiti delle risorse vCore, esamine le configurazioni hardware disponibili e quindi esamina i limiti delle risorse per:

• server logici
• database singoli
• database contenuti in pool elastici

Archiviazione di dati e log

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

• Ciascuna dimensione di calcolo supporta una dimensione massima dei dati configurabile con un valore predefinito di 32 GB.
• Quando configuri dimensioni massime dei dati, un ulteriore 30% di spazio di archiviazione fatturabile viene aggiunto automaticamente per il file di log.
• Nel livello di servizio Per utilizzo generico, tempdb usa la risorsa di archiviazione SSD locale e questo costo di archiviazione è incluso nel prezzo del vCore.
• Nel livello di servizio Business Critical, tempdb condivide la risorsa di archiviazione SSD locale con i file di dati e di log e il costo di archiviazione di tempdb è incluso nel prezzo del vCore.
• Nei livelli Per utilizzo generico e Business Critical vengono addebitate le dimensioni massime di archiviazione configurate per un database o un pool elastico.
• Per il database SQL, puoi selezionare qualsiasi dimensione massima dei dati compresa tra 1 GB e la dimensione di archiviazione massima supportata, in incrementi di 1 GB.

Le considerazioni sull'archiviazione seguenti si applicano a Hyperscale:

• La dimensione massima dell'archiviazione dei dati è impostata su 128 TB e non è configurabile.
• Vengono addebitati solo i costi per l'archiviazione dati allocata, non per l'archiviazione massima dei dati.
• Non vengono addebitati i costi per l'archiviazione dei log.
• tempdb usa la risorsa di archiviazione SSD locale e il relativo costo è incluso nel prezzo del vCore. Per monitorare le dimensioni correnti di archiviazione dei dati allocate e usate in database SQL, usa rispettivamente le metriche allocated_data_storage e storage di Monitoraggio di Azure.

Per monitorare le dimensioni correnti di archiviazione dei dati allocate e usate in un database tramite T-SQL, usa la vista sys.database_files e la funzione FILEPROPERTY(... , 'SpaceUsed').

Archivio di backup

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) del database 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 Archiviazione di Azure. 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. Puoi configurare un periodo di conservazione separato per ogni database compreso tra 1 e 35 giorni per il database SQL. La quantità di archivio di backup equivalente alle dimensioni massime configurate dei dati viene fornita senza addebiti aggiuntivi.
• Conservazione a lungo termine: puoi 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 BLOB di Azure, 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 dei backup a lungo termine.

Per l'archivio di backup in Hyperscale, vedi Backup automatizzati per i database Hyperscale.

Livelli di servizio

Le opzioni del livello di servizio nel modello di acquisto vCore includono Per utilizzo generico, Business Critical e Hyperscale. Il livello di servizio determina in genere il tipo di archiviazione e le prestazioni, le opzioni di disponibilità elevata e ripristino di emergenza e la disponibilità di determinate funzionalità, ad esempio OLTP in memoria.

¹ Prezzi semplificati per database SQL Hyperscale presto disponibili. Per informazioni dettagliate, vedere il blog sui prezzi di Hyperscale.

Per altri dettagli, esamina i limiti delle risorse per server logico, database singoli e database in pool.

Utilizzo generico

Il modello di architettura per il livello di servizio Per utilizzo generico si basa su una separazione tra calcolo e archiviazione. Questo modello di architettura si basa sull'elevata disponibilità e affidabilità di Archiviazione BLOB di Azure che replica i file di database in modo trasparente e impedisce la perdita di dati in caso di un errore dell'infrastruttura sottostante.

La figura seguente illustra quattro nodi nel modello dell'architettura standard con i livelli di calcolo e archiviazione separati.

Nel modello di architettura per il livello di servizio Per utilizzo generico esistono due livelli:

• Un livello di calcolo senza stato che esegue il processo sqlservr.exe e contiene solo i dati temporanei e memorizzati nella cache, ad esempio cache dei piani, pool di buffer, pool dell'archivio colonne. Il nodo senza stato è gestito da Azure Service Fabric che inizializza il processo, controlla il funzionamento del nodo e, se necessario, esegue il failover in un'altra posizione.
• Un livello di dati con stato con i file di database (con estensione mdf/ldf) archiviati in Archiviazione BLOB di Azure. Archiviazione BLOB di Azure garantisce che i dati dei record che si trovano in un file di database non vadano persi. Archiviazione di Azure è dotato di disponibilità/ridondanza dei dati incorporata che assicura che ogni record nel file di log o pagina nel file di dati verrà conservato anche se il processo si blocca.

Ogni volta che viene aggiornato il motore di database o il sistema operativo, una parte dell'infrastruttura sottostante non funziona oppure viene rilevato un problema critico nel processo di sqlservr.exe, Azure Service Fabric sposta il processo senza stato in un altro nodo di calcolo senza stato. È presente un set di nodi di riserva in attesa di eseguire un nuovo servizio di calcolo in caso di failover del nodo primario, per ridurre al minimo il tempo di failover. I dati nel livello di archiviazione di Azure non sono interessati e i dati e i file di log vengono associati al processo appena inizializzato. Questo processo garantisce la disponibilità del 99,99% per impostazione predefinita e la disponibilità del 99,995% quando la ridondanza della zona è abilitata. Potrebbero verificarsi alcuni impatti sulle prestazioni sui carichi di lavoro elevati in fase di esecuzione a causa del tempo di transizione e per il fatto che il nuovo nodo inizia con la cache a freddo.

Quando scegliere questo livello di servizio

Il livello di servizio Per utilizzo generico è un livello di servizio predefinito nel database SQL di Azure progettato per la maggior parte dei carichi di lavoro generici. Se necessiti di un motore di database completamente gestito con un contratto di servizio predefinito, con una latenza di archiviazione tra 5 e 10 ms, il livello Per utilizzo generico è la scelta adatta.

Business Critical

Il modello di livello di servizio Business Critical è basato su un cluster di processi del motore di database. Questo modello di architettura si basa su un quorum di nodi di motore di database per ridurre al minimo l’impatto sulle prestazioni del carico di lavoro anche durante le attività di manutenzione. Gli aggiornamenti e l’applicazione di patch al sistema operativo sottostante, ai driver e al motore di database si verificano in modo trasparente con tempi di inattività minimi per gli utenti finali.

Nel modello Business Critical il calcolo e l'archiviazione sono integrati in ogni nodo. La replica dei dati tra i processi del motore di database in ogni nodo di un cluster a quattro nodi raggiunge la disponibilità elevata, con ogni nodo che usa unità SSD collegate localmente come archiviazione dati. Il diagramma seguente mostra come il livello di servizio Business Critical organizza un cluster di nodi del motore di database nelle repliche del gruppo di disponibilità.

Sia il processo del motore di database che i file mdf/ldf sottostanti vengono posizionati nello stesso nodo con una risorsa di archiviazione SSD collegata in locale che offre bassa latenza al carico di lavoro. La disponibilità elevata è implementata mediante una tecnologia simile a Gruppi di disponibilità Always On di SQL Server. Ogni database è un cluster di nodi del database con una replica primaria accessibile per i carichi di lavoro del cliente e tre repliche secondarie contenenti le copie dei dati. La replica primaria esegue il push costante delle modifiche alle repliche secondarie per garantire che i dati siano disponibili nelle repliche secondarie se la replica primaria si arresta per un qualsiasi motivo. Il failover viene gestito da Service Fabric e dal motore di database: una replica secondaria diventa primaria e una nuova replica secondaria viene creata per garantire un numero sufficiente di nodi nel cluster. Il carico di lavoro viene reindirizzato automaticamente alla nuova replica primaria.

Inoltre, nel cluster Business Critical è integrata una funzionalità di scalabilità in lettura che fornisce una replica di sola lettura gratuita usata per l'esecuzione di query di sola lettura (ad esempio report) che non dovrebbero incidere sulle prestazioni del carico di lavoro della replica primaria.

Quando scegliere questo livello di servizio

Il livello di servizio business critical è progettato per le applicazioni che richiedono risposte a bassa latenza dalla risorsa di archiviazione SSD sottostante (in media 1-2 ms) e ripristino più rapido in caso di errore dell'infrastruttura sottostante o che devono delegare report, analisi e query di sola lettura alla replica secondaria leggibile gratuita del database primario.

I motivi principali per cui scegliere il livello di servizio Business Critical anziché il livello Per utilizzo generico sono:

• Requisiti di latenza di I/O ridotti: i carichi di lavoro che necessitano di una risposta costantemente veloce dal livello di archiviazione (in media 1-2 millisecondi) devono usare il livello Business Critical.
• Carico di lavoro con query di report e analisi in cui è sufficiente una singola replica secondaria di sola lettura gratuita.
• Maggiore resilienza e ripristino più rapido da errori. In caso di errore di sistema, il database nell'istanza primaria è disabilitato e una delle repliche secondarie diventa immediatamente il nuovo database primario di lettura/scrittura, pronto per elaborare le query.
• Protezione avanzata del danneggiamento dei dati. Poiché il livello Business Critical usa repliche di database in background, il servizio usa il ripristino automatico delle pagine disponibile con il mirroring e i gruppi di disponibilità per ridurre il danneggiamento dei dati. Se una replica non riesce a leggere una pagina a causa di un problema di integrità dei dati, una nuova copia della pagina viene recuperata da un'altra replica, sostituendo la pagina illeggibile senza perdita di dati o tempi di inattività dei clienti. Questa funzionalità è disponibile nel livello Per utilizzo generico se il database ha una replica geografica secondaria.
• Disponibilità più elevata: il livello Business Critical in una configurazione di una zona a più disponibilità offre resilienza agli errori di zona e a un contratto di servizio con disponibilità più elevata.
• Ripristino geografico rapido: quando è configurata la replica geografica attiva, il livello Business Critical ha un obiettivo del punto di ripristino (RPO) garantito di 5 secondi e un obiettivo del tempo di ripristino (RTO) di 30 secondi per il 100% delle ore distribuite.

Hyperscale

Il livello di servizio Hyperscale è adatto a tutti i tipi di carico di lavoro. L'architettura nativa del cloud offre risorse di calcolo e archiviazione scalabili in modo indipendente per supportare la più ampia gamma di applicazioni tradizionali e moderne. Le risorse di calcolo e archiviazione in Hyperscale superano sostanzialmente le risorse disponibili nei livelli Per utilizzo generico e Business Critical.

Per ulteriori informazioni. vedi Livello di servizio Hyperscale per il database SQL di Azure.

Quando scegliere questo livello di servizio

Il livello di servizio Hyperscale elimina molti dei limiti pratici che generalmente caratterizzano i database cloud. Se la maggior parte dei database sono limitati dalle risorse disponibili in un singolo nodo, i database nel livello di servizio Hyperscale non presentano limiti di questo tipo. Con l’architettura di archiviazione flessibile, un database Hyperscale può espandersi in base alle esigenze e la fatturazione viene applicata solo in base alla capacità in uso.

Oltre alle funzionalità di scalabilità avanzate, Hyperscale è un'ottima opzione per qualsiasi carico di lavoro, non solo per i database di grandi dimensioni. Con Hyperscale puoi:

• Ottenere resilienza elevata e ripristino rapido degli errori controllando i costi, scegliendo il numero di repliche a disponibilità elevata da 0 a 4.
• Migliorare la disponibilità elevata abilitando la ridondanza della zona per il calcolo e l'archiviazione.
• Ottenere una bassa latenza di I/O (1-2 millisecondi in media) per la parte del database a cui si accede di frequente. Per i database di dimensioni inferiori, ciò può essere applicato all'intero database.
• Implementare un'ampia gamma di scenari di scalabilità in lettura con repliche denominate.
• Sfruttare i vantaggi del ridimensionamento rapido, senza attendere che i dati vengano copiati nell'archiviazione locale nei nuovi nodi.
• Usufruire del backup del database continuo a impatto zero e del ripristino rapido.
• Supportare i requisiti di continuità aziendale usando i gruppi di failover e la replica geografica.

Configurazione hardware

Le configurazioni hardware comuni nel modello vCore includono serie standard (Gen5), serie Fsv2 e serie DC. Hyperscale offre anche un'opzione per l'hardware ottimizzato per la memoria della serie Premium e della serie Premium. La configurazione hardware definisce i limiti di calcolo e memoria e altre caratteristiche che influiscono sulle prestazioni del carico di lavoro.

Alcune configurazioni hardware, ad esempio la serie standard (Gen5) possono usare più di un tipo di processore (CPU), come descritto in Risorse di calcolo (CPU e memoria). Anche se un determinato database o pool elastico tende a rimanere sull'hardware con lo stesso tipo di CPU per molto tempo (in genere per più mesi), esistono alcuni eventi che possono causare lo spostamento di un database o di un pool nell'hardware che usa un tipo di CPU diverso.

È possibile spostare un database o un pool per diversi scenari, tra cui, ad esempio, quando:

• L'obiettivo del servizio viene modificato
• L'infrastruttura corrente in un data center sta raggiungendo i limiti di capacità
• L'hardware attualmente usato viene rimosso a causa della fine del ciclo di vita
• La configurazione con ridondanza della zona è abilitata, passando a un hardware diverso a causa della capacità disponibile

Per alcuni carichi di lavoro, un passaggio a un tipo di CPU diverso può modificare le prestazioni. Il database SQL configura l'hardware con l'obiettivo di offrire prestazioni prevedibili del carico di lavoro anche se il tipo di CPU cambia, mantenendo le modifiche delle prestazioni all'interno di una banda stretta. Tuttavia, nell'ampio spettro dei carichi di lavoro dei clienti nel database SQL e man mano che diventano disponibili nuovi tipi di CPU, è occasionalmente possibile visualizzare modifiche più evidenti nelle prestazioni, se un database o un pool passa a un tipo di CPU diverso.

Indipendentemente dal tipo di CPU usato, i limiti delle risorse per un database o un pool elastico, ad esempio il numero di core, memoria, operazioni di I/O al secondo massime dei dati, frequenza massima dei log e numero massimo di ruoli di lavoro simultanei, rimangono invariati a condizione che il database rimanga nello stesso obiettivo di servizio.

Risorse di calcolo (CPU e memoria)

La tabella seguente confronta le risorse di calcolo in diverse configurazioni hardware e livelli di calcolo:

* Nella DMV sys.dm_user_db_resource_governance, la generazione hardware per i database che usano processori Intel® SP-8160 (Skylake) viene visualizzata come Gen6, la generazione hardware per i database che usano Intel® 8272CL (Cascade Lake) viene visualizzata come Gen7 e la generazione hardware per i database che usano Intel® Xeon® Platinum 8370C (Ice Lake) o AMD® EPYC® 7763v (Milano) viene visualizzata come Gen8. Per una determinata configurazione hardware e determinate dimensioni di calcolo, i limiti delle risorse sono uguali indipendentemente dal tipo di CPU (Intel Broadwell, Skylake, Ice Lake, Cascade Lake o AMD Milan).

Per ulteriori informazioni, vedere i limiti delle risorse per database singoli e pool elastici.

Per le risorse di calcolo e le specifiche del database Hyperscale, vedi Risorse di calcolo Hyperscale.

Serie standard (Gen5)

• L'hardware serie standard (Gen5) offre risorse di calcolo e memoria bilanciate ed è adatto per la maggior parte dei carichi di lavoro del database.

L'hardware serie standard (Gen5) è disponibile in tutte le aree pubbliche in tutto il mondo.

Serie Premium Hyperscale

• Le opzioni hardware della serie Premium usano la tecnologia di CPU e memoria più recente di Intel e AMD. La serie Premium offre un aumento delle prestazioni di calcolo rispetto all'hardware della serie standard.
• La serie Premium offre prestazioni di CPU più veloci rispetto alla serie standard e un numero più elevato di vCore massimi.
• L'opzione ottimizzata per la memoria della serie Premium offre il doppio della quantità di memoria rispetto alla serie standard.
• La serie standard, la serie Premium e la serie Premium ottimizzate per la memoria sono disponibili per i pool elastici Hyperscale.

Per altre informazioni, vedi l'annuncio del blog della serie Premium Hyperscale.

Per le aree disponibili, vedi Disponibilità della serie Premium Hyperscale.

Serie Fsv2

• La serie Fsv2 è una configurazione hardware ottimizzata per il calcolo che offre CPU a bassa latenza e velocità di clock elevata per i carichi di lavoro più esigenti a livello di CPU. Analogamente alle configurazioni hardware della serie Premium Hyperscale, la serie Fsv2 è basata sulla tecnologia di CPU e memoria più recente di Intel e AMD, consentendo ai clienti di sfruttare i vantaggi dell'hardware più recente durante l'uso di database e pool elastici nel livello di servizio Per utilizzo generico.
• A seconda del carico di lavoro, la serie Fsv2 può offrire prestazioni della CPU maggiori per vCore rispetto ad altri tipi di hardware. Ad esempio, le dimensioni di calcolo 72 vCore Fsv2 possono offrire prestazioni della CPU superiori a 80 vCore nella serie standard (Gen5), a un costo inferiore.
• Fsv2 fornisce meno memoria e tempdb per vCore rispetto ad altri hardware, quindi i carichi di lavoro sensibili a tali limiti potrebbero offrire prestazioni migliori nelle serie standard (Gen5).

La serie Fsv2 è supportata solo nel livello Per utilizzo generico. Per le aree in cui è disponibile la serie Fsv2, vedi Disponibilità delle serie Fsv2.

Serie DC

• L’hardware della serie DC utilizza processori Intel con tecnologia Intel SGX (Software Guard Extension).
• La serie DC è necessaria per Always Encrypted con carichi di lavoro di enclave sicuri che richiedono una maggiore protezione della sicurezza delle enclave hardware, rispetto alle enclave di sicurezza basata su virtualizzazione.
• La serie DC è progettata per carichi di lavoro che elaborano dati sensibili e richiedono capacità di elaborazione di query riservate, fornita da Always Encrypted con enclave sicure.
• L'hardware della serie DC fornisce risorse di calcolo e memoria bilanciate.

La serie DC è supportata solo per il calcolo con provisioning (serverless non è supportato) e non supporta la ridondanza della zona. Per le aree in cui è disponibile la serie DC, vedi Disponibilità delle serie DC.

Tipi di offerta di Azure supportati dalla serie DC

Per creare database o pool elastici nell'hardware della serie DC, la sottoscrizione deve essere un tipo di offerta a pagamento, ad esempio, pagamento in base al consumo o Contratto Enterprise (EA). Per un elenco completo dei tipi di offerta di Azure supportati dalla serie DC, vedi Offerte correnti senza limiti di spesa.

Selezionare la configurazione hardware

Puoi selezionare la configurazione hardware per un database o un pool elastico nel database SQL al momento della creazione. Puoi anche modificare la configurazione hardware di un database o di un pool elastico esistente.

Per selezionare una configurazione hardware durante la creazione di un database SQL o di un pool

Per informazioni dettagliate, vedi Creare un database SQL.

Nella scheda Dati principali, seleziona il collegamento Configura database nella sezione Calcolo e archiviazione e quindi seleziona il collegamento Modifica configurazione:

Selezionare la configurazione hardware desiderata:

Per modificare la configurazione hardware di un database SQL o di un pool esistente

Per un database, nella pagina Panoramica seleziona il collegamento Piano tariffario:

Per un pool, nella pagina Panoramica seleziona Configura.

Segui la procedura per modificare la configurazione e seleziona la configurazione hardware come descritto nei passaggi precedenti.

Disponibilità hardware

Per informazioni sull'hardware di generazione precedente, vedi Disponibilità hardware di generazione precedente.

Serie standard (Gen5)

L'hardware serie standard (Gen5) è disponibile in tutte le aree pubbliche in tutto il mondo.

Serie Premium Hyperscale

L'hardware ottimizzato per la memoria della serie Premium e la serie Premium del livello di servizio Hyperscale è disponibile per database singoli e pool elastici nelle seguenti aree:

• Australia orientale **
• Australia sud-orientale
• Brasile meridionale **,*
• Canada centrale **
• Canada orientale
• Asia orientale
• Europa settentrionale **
• Europa occidentale **
• Francia centrale
• Germania centro-occidentale
• India centrale
• India meridionale
• Giappone orientale **
• Giappone occidentale
• Asia sud-orientale **
• Svizzera settentrionale
• Svezia centrale **,*
• Regno Unito meridionale **
• Regno Unito occidentale **
• Stati Uniti centrali **
• Stati Uniti orientali **
• Stati Uniti orientali 2 **
• Stati Uniti centro-settentrionali
• Stati Uniti centro-meridionali
• Stati Uniti centro-occidentali
• Stati Uniti occidentali 1
• Stati Uniti occidentali 2 **
• Stati Uniti occidentali 3 **

* L'hardware ottimizzato per la memoria della serie Premium non è attualmente disponibile.

** Include il supporto per la ridondanza della zona.

Serie Fsv2

La serie Fsv2 è disponibile nelle seguenti aree:

• Australia centrale
• Australia centrale 2
• Australia orientale
• Australia sud-orientale
• Brasile meridionale
• Canada centrale
• Asia orientale
• Europa settentrionale
• Europa occidentale
• Francia centrale
• India centrale
• Corea centrale
• Corea meridionale
• Sudafrica settentrionale
• Asia sud-orientale
• Regno Unito meridionale
• Regno Unito occidentale
• Stati Uniti orientali
• Stati Uniti occidentali 2

Serie DC

La serie DC è disponibile nelle seguenti aree:

• Canada centrale
• Europa occidentale
• Europa settentrionale
• Asia sud-orientale
• Regno Unito meridionale
• Stati Uniti occidentali
• Stati Uniti orientali

Se è necessaria una serie DC in un'area attualmente non supportata, invia una richiesta di supporto. Nella pagina Dati principali specifica quanto segue:

1. Per Tipo di problema, seleziona Tecnico.
2. Specifica una sottoscrizione desiderata per l’hardware. Selezionare Avanti.
3. Per Tipo di servizio, seleziona Database SQL.
4. Per Risorsa seleziona Domanda generale.
5. Per Riepilogo specifica la disponibilità e l'area hardware desiderate.
6. Per Tipo di problema, seleziona Sicurezza, privato e conformità.
7. Per Sottotipo di problem seleziona Always Encrypted.

Hardware di generazione precedente

Quarta generazione

L'hardware Gen4 è stato ritirato e non è disponibile per il provisioning, l'upscaling o il downscaling. Per una maggiore scalabilità di vCore e archiviazione, una rete accelerata, migliori prestazioni delle operazioni di I/O e una latenza minima, esegui la migrazione del database in un hardware di generazione supportata. Esamina le opzioni hardware per database singoli e le opzioni hardware per pool elastici. Per altre informazioni, vedi Supporto terminato per l'hardware Gen 4 nel database SQL di Azure.

Passaggio successivo

Contenuto correlato

• Pagina dei prezzi del database SQL di Azure
• Limiti di risorse per i database singoli usando il modello di acquisto vCore
• Limiti delle risorse per i pool elastici secondo il modello di acquisto vCore