Livello di servizio Hyperscale

database SQL di Azure Hyperscale è un database cloud a prestazioni elevate e conveniente.

database SQL di Azure si basa sul motore di database SQL. Hyperscale differisce da altri livelli di servizio database SQL di Azure:

A differenza di altri livelli di servizio, Hyperscale non prevede alcuna tariffa di licenza software SQL, che offre un notevole vantaggio sui prezzi rispetto ad altri livelli di servizio database SQL di Azure per i database ad alte prestazioni.
L'architettura Hyperscale è distinta: offre backup quasi istantanei, ripristini rapidi e velocità effettiva elevata per letture e scritture.
Hyperscale offre scalabilità di calcolo veloce su richiesta senza spostamento dei dati.
Le strategie di scalabilità orizzontale in lettura sono semplici, con un massimo di 30 repliche denominate con calcolo configurabile indipendente, oltre a repliche a disponibilità elevata predefinite e repliche geografiche configurabili in tutto il mondo.

Il livello di servizio Hyperscale è adatto a tutti i tipi di carico di lavoro. Le risorse di calcolo e archiviazione in Hyperscale superano sostanzialmente le risorse disponibili nei livelli database SQL di Azure Utilizzo generico e Business Critical.

È possibile convertire facilmente un database esistente in database SQL di Azure in Hyperscale oppure eseguire la migrazione da qualsiasi database SQL Server a Hyperscale. Per eseguire la migrazione di altri database a database SQL di Azure, vedere Azure Guide alla migrazione del database.

Il livello di servizio Hyperscale è attualmente disponibile solo per database SQL di Azure e non per Istanza gestita di SQL di Azure.

Quali sono le capacità di Hyperscale

Il livello di servizio Hyperscale in database SQL di Azure offre le funzionalità aggiuntive seguenti:

Aumento rapido delle prestazioni: aumentare le risorse di calcolo per supportare carichi di lavoro pesanti quando necessario e quindi ridimensionare le risorse di calcolo quando non sono necessarie.
Scalabilità orizzontale rapida: eseguire il provisioning di una o più repliche di sola lettura per scaricare il carico di lavoro in lettura e da usare come standby a caldo.
Scalabilità automatica verso l'alto e verso il basso e fatturazione automatica per il calcolo informatico in base all'utilizzo con elaborazione serverless.
Prezzo/prestazioni ottimizzato per un gruppo di database Hyperscale con esigenze di risorse variabili con pool elastici.
Archiviazione con scalabilità automatica con supporto per un massimo di 128 TB di database o 100 TB di dimensioni del pool elastico.
Prestazioni complessive più elevate grazie alla maggiore velocità effettiva dei log e ai tempi di commit delle transazioni più veloci, indipendentemente dai volumi di dati.
Backup dei database rapidi (basati su snapshot di file) indipendentemente dalle dimensioni senza alcun impatto delle operazioni di I/O sulle risorse di calcolo.
Ripristini o copie di database (basati su snapshot di file) in pochi minuti anziché in ore o giorni.

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. Grazie all'architettura di archiviazione flessibile, lo spazio di archiviazione aumenta in base alle esigenze. I database Hyperscale, infatti, non vengono creati con una dimensione massima definita. Un database Hyperscale può espandersi in base alle esigenze e la fatturazione viene applicata solo in base alla capacità di archiviazione assegnata. Per i carichi di lavoro con intense attività di lettura, il livello di servizio Hyperscale consente un rapido scale-out fornendo repliche aggiuntive per la lettura in base alle necessità per sgravare i carichi di lavoro di lettura.

Inoltre, il tempo necessario per creare i backup dei database oppure aumentare o diminuire le prestazioni non è più associato al volume dei dati presenti nel database. Il backup dei database Hyperscale viene eseguito in maniera praticamente istantanea. È anche possibile dimensionare un database in decine di terabyte verso l'alto o verso il basso entro pochi minuti nel livello di calcolo di cui è stato effettuato il provisioning o usare serverless per dimensionare automaticamente il calcolo. Questa funzionalità consente di non essere vincolati alle scelte di configurazione iniziali.

Per altre informazioni sulle dimensioni di calcolo per il livello di servizio Hyperscale, vedere Caratteristiche del livello di servizio.

Per informazioni dettagliate sui livelli di servizio Utilizzo generico e Business critical nel modello di acquisto basato su vCore, vedere i livelli di servizio Utilizzo generico e Business critical. Per un confronto del modello di acquisto basato su vCore con il modello di acquisto basato su DTU, vedere Compare vCore e modelli di acquisto basati su DTU di database SQL di Azure.

Chi dovrebbe considerare il livello di servizio Hyperscale

Il livello di servizio Hyperscale è destinato a tutti i clienti che richiedono prestazioni e disponibilità più elevate, backup e ripristino rapidi e scalabilità di calcolo e archiviazione rapida. Hyperscale è ideale per i clienti che passano al cloud per modernizzare le applicazioni o per i clienti che usano già altri livelli di servizio in database SQL di Azure. Il livello di servizio Hyperscale supporta un'ampia gamma di carichi di lavoro di database, da OLTP pulito ad analisi pulita. È ottimizzato per carichi di lavoro OLTP e di elaborazione analitica e transazioni ibride (HTAP).

Modello di prezzi Hyperscale

Per i database ad alte prestazioni, Hyperscale offre un significativo vantaggio sui prezzi rispetto ad altri livelli di servizio database SQL di Azure. Per altre informazioni, vedi Blog: annuncio dei prezzi di database SQL di Azure Hyperscale di Ignite 2023. Per informazioni dettagliate sulla modifica dei prezzi, vedere blog: database SQL di Azure Hyperscale - prezzi più bassi e semplificati!

Il livello di servizio Hyperscale è disponibile solo nel modello vCore e include due livelli di calcolo. La fatturazione per Hyperscale si basa sul livello di calcolo provisionato o serverless:

Livello di calcolo provisionato:

Il costo di calcolo vCore riflette la capacità di calcolo totale di cui viene effettuato il provisioning continuo per l'applicazione. Il prezzo dell'unità di calcolo del livello di servizio Hyperscale è per replica.
Livello di calcolo serverless:

La fatturazione delle risorse di elaborazione serverless si basa sull'utilizzo. Per altre informazioni, vedere Livello di calcolo serverless per database SQL di Azure.

Non si specificano le dimensioni massime dei dati durante la configurazione di un database Hyperscale. Nel livello Hyperscale si paga per l'archiviazione in base all'allocazione effettiva. L'archiviazione viene allocata automaticamente tra 10 GB e 128 TB e aumenta in base alle esigenze. Per altre informazioni, vedere In quali incrementi aumentano le dimensioni del database?

Vantaggi di scalabilità e prestazioni

Hyperscale separa il motore di database principale dai componenti che offrono archiviazione e durabilità a lungo termine per i dati. Questa architettura consente di ridimensionare rapidamente le risorse di calcolo, senza lo spostamento dei dati e di ridimensionare l'archiviazione (fino a 128 TB) indipendentemente dal calcolo. Per altri dettagli, incluso un diagramma dell'architettura, vedere Architettura Hyperscale.

Con la possibilità di attivare/ridurre rapidamente nodi di calcolo aggiuntivi di sola lettura, l'architettura Hyperscale consente funzionalità di scalabilità di lettura significative e può anche liberare il nodo di calcolo primario per gestire più richieste.
È possibile eseguire il provisioning delle risorse di calcolo per i nodi secondari oppure usare serverless compute. In entrambi i casi, è possibile aumentarli o ridurre rapidamente a causa dell'architettura di archiviazione condivisa di Hyperscale.
- In Hyperscale, le repliche secondarie dei nodi di calcolo a disponibilità elevata seguono il livello di calcolo del nodo primario, il che comporta failover a basso impatto.
Quando usi il serverless, i nodi di calcolo primari o secondari si ridimensionano automaticamente in base al carico di lavoro.

Il database Primario database SQL di Azure Hyperscale gestisce sia i carichi di lavoro di lettura che di scrittura, ma è possibile creare facilmente repliche di sola lettura come parte della strategia dell'applicazione:

È possibile modificare il numero totale di repliche secondarie a disponibilità elevata da 0 a 4, a seconda dei requisiti di disponibilità e scalabilità.
È possibile creare fino a 30 repliche con nome a supporto di carichi di lavoro di lettura con scalabilità orizzontale.
È possibile ottenere la scalabilità orizzontale delle letture a livello geografico tra i data center globali di Azure utilizzando repliche geografiche.

Disponibilità elevata del database in Hyperscale

Come in tutti gli altri livelli di servizio, Hyperscale garantisce la durabilità dei dati per le transazioni di cui è stato eseguito il commit indipendentemente dalla disponibilità della replica di calcolo. L'entità del tempo inattivo dovuto alla mancata disponibilità della replica primaria dipende dal tipo di failover (pianificato o non pianificato), dall'eventuale configurazione della ridondanza della zona e dalla presenza di almeno una replica a disponibilità elevata. In un failover pianificato, ad esempio un evento di manutenzione, il sistema crea la nuova replica primaria prima di avviare un failover o usa una replica a disponibilità elevata esistente come destinazione di failover. In un failover non pianificato (ad esempio un errore hardware nella replica primaria), il sistema usa una replica a disponibilità elevata come destinazione di failover, se presente, o crea una nuova replica primaria dal pool di capacità di calcolo disponibile. In quest'ultimo caso, la durata del tempo inattivo è maggiore a causa di passaggi aggiuntivi necessari per creare la nuova replica primaria.

È possibile scegliere una finestra di manutenzione per rendere prevedibili e meno problematici gli eventi di manutenzione con impatto per il carico di lavoro.

Per il contratto di servizio hyperscale, vedere SLA per database SQL di Azure.

Pool di buffer ed estensione resiliente del pool di buffer

In Azure Database Hyperscale esiste una separazione distinta tra calcolo e archiviazione. L'archiviazione contiene tutte le pagine del database in un database e può essere allocata su più computer man mano che aumenta il database. Il nodo di calcolo, tuttavia, memorizza nella cache solo gli elementi usati di recente. Le pagine più calde nel calcolo vengono mantenute in memoria in una struttura denominata pool di buffer (BP). Viene archiviato anche nell'unità SSD locale, l'estensione del pool di buffer resiliente (RBPEX), in modo che i dati possano essere recuperati più velocemente nel caso in cui il processo di calcolo venga riavviato.

In un sistema cloud, il calcolo può passare a computer diversi in base alle esigenze. Il livello di calcolo può avere più repliche. Una replica è primaria e riceve tutti gli aggiornamenti, mentre le altre sono repliche secondarie. Se il database primario ha esito negativo, il sistema promuove una delle repliche secondarie a disponibilità elevata nel database primario in un processo denominato failover. La replica secondaria potrebbe non avere una cache nel relativo BP e RBPEX ottimizzata per il carico di lavoro primario.

Priming continuo

Il priming continuo è un processo che raccoglie informazioni su quali pagine vengono consultate più frequentemente (le più utilizzate) in tutte le repliche di elaborazione. Il processo aggrega queste informazioni e le repliche secondarie a disponibilità elevata usano l'elenco di pagine più calde che corrispondono al carico di lavoro tipico del cliente. Questo processo riempie continuamente sia il BP sia l'RBPEX con le pagine più utilizzate, per stare al passo con i cambiamenti nel carico di lavoro del cliente.

Senza un priming continuo, sia BP che RBPEX non vengono ereditati dalle nuove repliche ad alta disponibilità e vengono ricostruiti solo durante il carico di lavoro dell'utente. Il priming continuo consente di risparmiare tempo e impedisce prestazioni incoerenti, poiché non vi è alcuna attesa prima che le cache vengano nuovamente completamente idratate. Con il priming continuo, le nuove repliche secondarie ad alta disponibilità inizieranno immediatamente il processo di priming di BP e RBPEX. Ciò consentirà di mantenere le prestazioni in modo più coerente man mano che si verificano i failover.

Il priming continuo funziona in entrambi i modi: le repliche secondarie a disponibilità elevata memorizzano nella cache le pagine usate nella replica primaria e la replica primaria memorizza nella cache le pagine con il carico di lavoro dalle repliche secondarie.

Il priming continuo è attualmente disponibile nel livello di calcolo con provisioning Hyperscale.

Backup e ripristino

Le operazioni di backup e ripristino per i database Hyperscale sono basate su snapshot di file. Questo approccio rende queste operazioni quasi istantanee. Poiché l'architettura Hyperscale usa il livello di archiviazione per il backup e il ripristino, riduce il carico di elaborazione e l'impatto sulle prestazioni sulle repliche di calcolo. Per altre informazioni, vedi backup Hyperscale e ridondanza di archiviazione.

Ripristino di emergenza per i database Hyperscale

Per ripristinare un database Hyperscale in database SQL di Azure in un'area diversa da quella attualmente ospitata in, eseguire un ripristino geografico. Questo metodo è adatto alle operazioni di disaster recovery, alle esercitazioni, al trasferimento o a qualsiasi altro motivo. Il ripristino geografico è disponibile solo quando si sceglie l'archiviazione con ridondanza geografica (RA-GRS) per la ridondanza dell'archiviazione.

Per altre informazioni, vedere Ripristino di un database Hyperscale in un'area diversa.

Confrontare i limiti delle risorse

I livelli di servizio basati su vCore differiscono in base alla disponibilità del database, al tipo di archiviazione, alle prestazioni e alle dimensioni massime di archiviazione. Nella tabella seguente vengono descritte le differenze seguenti:

ㅤ	Uso Generale	Business Critical	Hyperscale
migliore per	Opzioni di calcolo e archiviazione bilanciate orientate al budget.	Applicazioni OLTP con frequenza di transazioni elevata e bassi livelli di latenza di I/O. Elevata resilienza ai guasti e failover rapidi grazie all’uso di repliche hot standby multiple.	Livello di servizio consigliato e predefinito per tutti i carichi di lavoro OLTP e HTAP nuovi e moderni. Ideale per l'ampia gamma di carichi di lavoro, inclusi i carichi di lavoro con archiviazione altamente scalabile e requisiti di scalabilità in lettura. Offre maggiore resilienza agli errori consentendo la configurazione di più repliche secondarie a disponibilità elevata.
Dimensioni di calcolo	Da 2 a 128 vCore	Da 2 a 128 vCore	Da 2 a 192 vCore³
Tipo di archiviazione	Archiviazione remota Premium (per istanza)	Archiviazione SSD locale estremamente veloce (per istanza)	Archiviazione disaccoppiata con cache SSD locale (per replica di calcolo)
Dimensioni di archiviazione	1 GB - 4 TB	1 GB - 4 TB	10 GB - 128 TB
Numero massimo di operazioni di I/O al secondo	320 operazioni di I/O al secondo per vCore fino a un massimo di 16.000	4.000 IOPS per vCore con massimo di 327.680 IOPS	5.500 operazioni di I/O al secondo per vCore con 544.000 operazioni di I/O al secondo di unità SSD locali massime. Hyperscale è un'architettura multilivello con memorizzazione nella cache a più livelli. Le operazioni di ingresso/uscita al secondo (IOPS) effettive dipendono dal carico di lavoro.
Memoria/vCore	5,1 GB	5,1 GB	5.1 GB o 10.2 GB
Backups	Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS) Conservazione di 1-35 giorni (7 giorni per impostazione predefinita), con fino a 10 anni di conservazione a lungo termine disponibile	Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS) Conservazione di 1-35 giorni (7 giorni per impostazione predefinita), con fino a 10 anni di conservazione a lungo termine disponibile	Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS) Conservazione di 1-35 giorni (7 giorni per impostazione predefinita), con fino a 10 anni di conservazione a lungo termine disponibile
Disponibilità	Una replica, nessuna replica di lettura con scalabilità orizzontale. Disponibilità elevata con ridondanza della zona	Tre repliche, una replica di lettura con scalabilità orizzontale. Disponibilità elevata con ridondanza della zona	Repliche multiple, fino a 4 repliche di lettura con scalabilità orizzontale. Disponibilità elevata con ridondanza della zona
Prezzi e fatturazione	Vengono addebitati i costi per vCore, spazio di archiviazione e archivio di backup. Le operazioni di I/O al secondo non vengono addebitate.	Vengono addebitati i costi per vCore, spazio di archiviazione e archivio di backup. Le operazioni di I/O al secondo non vengono addebitate.	Vengono addebitati i costi vCore per ogni replica, archiviazione dei dati assegnata e archivio di backup. Le operazioni di I/O al secondo non vengono addebitate.
Modelli di sconto¹	Prenotazioni di Azure Vantaggio Azure Hybrid² Sottoscrizioni Enterprise e Offerte di Sviluppo/Test con pagamento in base al consumo	Prenotazioni di Azure Vantaggio Azure Hybrid² Sottoscrizioni Enterprise e Offerte di Sviluppo/Test con pagamento in base al consumo	Poiché Hyperscale non ha alcun costo di licenza software SQL¹, Vantaggio Azure Hybrid non è disponibile per i nuovi database Hyperscale².
Tabelle in memoria	NO	Sì	No

¹ A dicembre 2023 sono arrivati i prezzi semplificati per SQL Database Hyperscale. Per informazioni dettagliate, consultare il blog sui prezzi di Hyperscale.

² A partire da dicembre 2023, Vantaggio Azure Hybrid non è disponibile per i nuovi database Hyperscale o nelle sottoscrizioni di sviluppo/test. I database singoli Hyperscale esistenti con calcolo con risorse predefinite sono in grado di continuare a usare Vantaggio Azure Hybrid per risparmiare sui costi di calcolo fino a dicembre 2026. Per ulteriori informazioni, vedi il blog sui prezzi di Hyperscale.

³ Attualmente, le opzioni vCore 160 e 192 sono una funzionalità di anteprima.

Risorse di calcolo

La tabella seguente confronta le risorse di calcolo in diverse configurazioni hardware e livelli di calcolo per Il database SQL di Azure Hyperscale. Per il database SQL di Azure non Hyperscale, vedere modello di acquisto vCore - Database SQL di Azure.

Configurazione hardware	CPU (unità centrale di elaborazione)	Memoria
Serie standard (Gen5)	Calcolo provisionato - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milano), AMD EPYC 9004 (Genova), Intel® Xeon®® Platinum 8573C (Emerald Rapids) processori - Fornisci fino a 128 vcore (con hyper-threading) Calcolo senza server (serverless) - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milano), AMD EPYC 9004 (Genova), Intel® Xeon®® Platinum 8573C (Emerald Rapids) processori - Scalabilità automatica fino a 80 vCore (con tecnologia hyper-threading) - Il rapporto da memoria a vCore si adatta dinamicamente all'utilizzo della memoria e della CPU in base alla domanda del carico di lavoro e può essere pari a 24 GB per vCore. Ad esempio, in un determinato momento un carico di lavoro può usare ed essere fatturato per 240 GB di memoria e solo 10 vCores.	Calcolo provisionato - 5,1 GB per vCore - Fornitura fino a 625 GB Calcolo senza server (serverless) - Scalabilità automatica fino a 24 GB per vCore - Scalabilità automatica fino a 240 GB
Serie Premium	Calcolo provisionato - Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milano), AMD EPYC 9004 (Genova), Processori Intel® Xeon® Platinum 8573C (Emerald Rapids) - Effettuare il provisioning di un massimo di 192 vCore (con hyperthreading).	5,2 GB per vCore
Serie Premium ottimizzata per memoria	Calcolo provisionato - Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milano), AMD EPYC 9004 (Genova), Processori Intel® Xeon® Platinum 8573C (Emerald Rapids) - Effettuare il provisioning di un massimo di 80 vCore (con hyperthreading).	10,2 GB per vCore

* Per una determinata configurazione hardware e dimensioni di calcolo, i limiti delle risorse sono uguali indipendentemente dal tipo di CPU (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Emerald Rapid o AMD Milano). Nella vista di gestione dinamica sys.dm_user_db_resource_governance, la generazione hardware per i database utilizza:

I processori Intel® SP-8160 (Skylake) sono visualizzati come Gen6
Intel® 8272CL (Cascade Lake) viene visualizzato come Gen7
Intel® Xeon® Platinum 8370C (Ice Lake) o AMD EPYC™ 7763v (Milano) appaiono come Gen8
AMD EPYC™ 9004 (Genova) appare come Gen9 o Intel® Xeon® Platinum 8573C (Emerald Rapids) appare come Gen10

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

Creare e gestire database Hyperscale

È possibile creare e gestire database Hyperscale usando il portale di Azure, Transact-SQL, PowerShell e il interfaccia della riga di comando di Azure. Per ulteriori informazioni, vedi Guida introduttiva: Creare un database Hyperscale.

Operazione	dettagli	Ulteriori informazioni
Creare un database Hyperscale	I database Hyperscale sono disponibili solo usando il modello di acquisto basato su vCore.	Trovare esempi per creare un database Hyperscale in Quickstart: Creare un database Hyperscale in database SQL di Azure.
Convertire un database esistente in Hyperscale	È possibile convertire un database esistente nel livello hyperscale database SQL di Azure. La durata della conversione dipende dalle dimensioni dei dati.	Per altre informazioni, vedere Convertire un database esistente in Hyperscale.
Eseguire la migrazione inversa di un database Hyperscale al livello di servizio Generale	Se in precedenza è stata eseguita la migrazione di un database SQL di Azure esistente a Hyperscale, è possibile invertire la migrazione del database 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, eseguire prima la migrazione inversa al livello di servizio per utilizzo generico, quindi modificare il livello di servizio.	Informazioni su come invertire la migrazione da Hyperscale e limitazioni per l'inversione della migrazione.

Limitazioni

Queste limitazioni si applicano attualmente al livello di servizio Hyperscale. Il team del prodotto sta lavorando attivamente per rimuovere il maggior numero possibile di queste limitazioni.

Problema	Descrizione
La compattazione viene bloccata quando TDE è disabilitato	Attualmente, database SQL di Azure Hyperscale non supporta le operazioni di compattazione dei file e del database quando Transparent Data Encryption (TDE) è disabilitato.
Ripristinare il database da altri piani di servizio	Non è possibile ripristinare un database non Hyperscale come database Hyperscale. Non è anche possibile ripristinare un database Hyperscale come database non Hyperscale. Per i database migrati a Hyperscale da altri livelli di servizio database SQL di Azure, i backup di pre-migrazione vengono conservati per la durata del periodo di conservazione dei backup del database di origine, inclusi i criteri di conservazione a lungo termine. È possibile ripristinare un backup di pre-migrazione entro il periodo di conservazione dei backup del database tramite la riga di comando. È possibile ripristinare questi backup in qualsiasi livello di servizio non Hyperscale.
Migrazione di database con oggetti OLTP in memoria	Hyperscale supporta un sottoinsieme di oggetti OLTP in memoria, inclusi i tipi di tabella ottimizzata per la memoria, le variabili di tabella e i moduli compilati in modo nativo. Tuttavia, quando tutti gli oggetti OLTP in memoria sono presenti nel database di cui viene eseguita la migrazione, la migrazione dai livelli di servizio Premium e Business Critical a Hyperscale non è supportata. Per eseguire la migrazione di un database di questo tipo a Hyperscale, è necessario eliminare tutti gli oggetti OLTP In-Memory e le relative dipendenze. Dopo la migrazione del database, è possibile ricreare questi oggetti. Le tabelle ottimizzate per la memoria, durevoli e non durevoli, non sono attualmente supportate in Hyperscale e devono essere convertite in tabelle su disco.
Controllo integrità del database	DBCC CHECKDB non è attualmente supportato per i database Hyperscale. Come soluzione alternativa, usare `DBCC CHECKTABLE ('TableName') WITH TABLOCK` e `DBCC CHECKFILEGROUP WITH TABLOCK`. Per informazioni dettagliate sulla gestione dell'integrità dei dati in database SQL di Azure, vedere Integrità dei dati in database SQL di Azure.
Lavori Elastici	L'uso di un database Hyperscale come database di lavoro non è supportato. Tuttavia, i processi elastici possono essere destinati ai database Hyperscale nello stesso modo di qualsiasi altro database in database SQL di Azure.
Sincronizzazione dei dati	L'uso di un database Hyperscale come database dei metadati di sincronizzazione o dell'hub non è supportato. Tuttavia, un database Hyperscale può essere un database membro in una topologia sincronizzazione dati.
Hardware della serie Premium del livello di servizio Hyperscale	L'hardware della serie Premium e quello ottimizzato per la memoria della stessa serie attualmente non supportano il livello di elaborazione serverless. Serverless è supportato solo nell'hardware della serie Standard (Gen5).
Disponibilità regionale	L'hardware ottimizzato per la memoria della serie Premium e della serie Premium hyperscale è disponibile in aree limitate Azure. Per un elenco, vedi Disponibilità della serie Premium Hyperscale.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-06-23