Domande frequenti su Hyperscale per il database SQL di Azure

Un database Hyperscale è un database nel database SQL basato sulla tecnologia di archiviazione Hyperscale di tipo scale-out. Un database Hyperscale supporta fino a 128 TB di dati e offre velocità effettiva e prestazioni elevate, nonché un ridimensionamento rapido per adattarsi ai requisiti del carico di lavoro. Connettività, elaborazione delle query, funzionalità del motore di database e così via funzionano come in qualsiasi altro database nel database SQL di Azure.

Il livello di servizio Hyperscale è disponibile solo per i database singoli che usano il modello di acquisto basato su vCore nel database SQL di Azure. Non è disponibile nel modello di acquisto basato su DTU.

I livelli di servizio basati su vCore si distinguono per il tipo di disponibilità e di archiviazione, le prestazioni e le dimensioni di memorizzazione massime del database, come descritto nel confronto fra limiti di risorse.

Il livello di servizio Hyperscale è destinato a tutti i clienti che cercano prestazioni e disponibilità più elevate, backup e ripristino rapidi, archiviazione veloce e scalabilità di calcolo. Sono inclusi i clienti che iniziano in piccolo e crescono, quelli che gestiscono grandi database mission-critical, quelli che stanno passando al cloud per modernizzare le loro applicazioni e i clienti che usano già altri livelli di servizio nel database SQL di Azure. Il livello Hyperscale offre:

• Dimensioni del database che possono aumentare da 10 GB a 128 TB.
• Calcolare le risorse vCore da 2 vCore fino a 128 vCore
• Rapidità di backup dei database indipendentemente dalle dimensioni (i backup sono basati su snapshot di archiviazione).
• Rapidità di ripristino dei database indipendentemente dalle dimensioni (i ripristini vengono eseguiti da snapshot di archiviazione).
• Maggiore velocità effettiva del log indipendentemente dalle dimensioni del database e dal numero di vCore.
• Scalabilità in lettura tramite una o più repliche di sola lettura, usate per l'offload di carichi di lavoro di sola lettura e come database hot standby.
• Rapido aumento delle prestazioni delle risorse di calcolo, in un tempo costante, per disporre di maggiore potenza adatta a un carico di lavoro impegnativo e quindi ridurre le prestazioni in un tempo costante. Le operazioni di ridimensionamento richiedono minuti a una cifra per il calcolo con provisioning e meno di un secondo per l’elaborazione serverless, indipendentemente dalle dimensioni del database.
• L'opzione per pagare ciò che si usa con l'ambiente di calcolo serverless, in cui il calcolo viene fatturato in base all'utilizzo.

Il livello di servizio Hyperscale è disponibile in tutte le regioni in cui è disponibile il database SQL di Azure.

Sì. Per altre informazioni e per i limiti al numero di database per ogni server, vedere Limiti delle risorse del database SQL per database singoli e in pool in un server.

L'architettura Hyperscale offre livelli elevati di prestazioni e velocità effettiva e supporto per database di grandi dimensioni.

Hyperscale offre scalabilità rapida in base alle esigenze dei carichi di lavoro.

• Scalabilità verticale

  Con il livello Hyperscale, è possibile aumentare le dimensioni di calcolo primarie in termini di risorse come CPU e memoria e quindi ridurle, in un tempo costante. Poiché l'archiviazione è remota, l’aumento o la riduzione non è un'operazione di ridimensionamento dei dati.

  Il supporto per l'elaborazione serverless fornisce scalabilità verticale e orizzontale automatiche, e l'elaborazione viene addebitata in base all'utilizzo.

• Scalabilità orizzontale

  Con Hyperscale, è possibile usare tre tipi di repliche secondarie per soddisfare i requisiti di scalabilità in lettura, disponibilità elevata e replica geografica. Valuta gli ambiti seguenti:

  • Fino a quattro repliche a disponibilità elevata con le stesse dimensioni di calcolo della replica primaria. Queste fungono da repliche hot standby per effettuare il failover rapidamente dal database primario. È anche possibile usarle per eseguire l'offload dei carichi di lavoro di lettura dal database primario.
  • Fino a 30 repliche denominate con dimensioni di calcolo uguali o diverse rispetto alla replica primaria, per soddisfare diversi scenari di scalabilità in lettura.
  • Una replica geografica in un'area di Azure diversa per proteggere da interruzioni a livello di area e per abilitare la scalabilità in lettura geografica.

Si, puoi.

No, il modello di programmazione dell'applicazione rimane invariato per qualsiasi altro database MSSQL. È possibile usare come sempre la stringa di connessione e gli altri modi standard per l'interazione con il database Hyperscale. Quando l'applicazione usa il database Hyperscale, l'applicazione può sfruttare le funzionalità, ad esempio le repliche secondarie.

Nella replica primaria il livello di isolamento della transazione predefinito è RCSI (Read Committed Snapshot Isolation, isolamento dello snapshot Read Committed). Nelle repliche secondarie con scalabilità in lettura il livello di isolamento predefinito è Snapshot. Accade lo stesso in qualsiasi altro database SQL di Azure.

Con il nuovo prezzo semplificato in vigore dal 15 dicembre 2023, il prezzo del calcolo è stato ridotto per i database Hyperscale appena creati, tutti i database Hyperscale serverless e tutti i pool elastici Hyperscale. Con il nuovo prezzo semplificato, non è necessario applicare Vantaggio Azure Hybrid (AHB) per ottenere risparmi equivalenti. Vantaggio Azure Hybrid (AHB) può essere applicato solo ai database singoli hyperscale con ambiente di calcolo con provisioning creati prima del 15 dicembre 2023. Per tali database meno recenti, AHB è applicabile solo fino a dicembre 2026; dopo tale data, questi database verranno fatturati anche in base ai nuovi prezzi semplificati. Per altre informazioni, vedere il blog sui prezzi di Hyperscale e database SQL di Azure Hyperscale – prezzi più bassi e semplificati!.

Hyperscale funziona bene per tutti i tipi di carichi di lavoro, inclusi i carichi di lavoro OLTP, ibridi (HTAP) e analitici (data mart).

Se attualmente si eseguono query di analisi interattive usando SQL Server come data warehouse, Hyperscale è un'ottima opzione perché è possibile ospitare data warehouse di piccole e medie dimensioni (ad esempio alcuni TB fino a 128 TB) a un costo inferiore ed è possibile eseguire la migrazione dei carichi di lavoro di SQL Server Data Warehouse a Hyperscale con modifiche minime al codice T-SQL.

Se si eseguono analisi dei dati su larga scala con query complesse e velocità di inserimento sostenute superiori a 100 MB/s o usando Parallel Data Warehouse (PDW), Teradata o altri data warehouse MPP (Massively Parallel Processing), ad esempio Azure Synapse Analytics, Microsoft Fabric potrebbe essere la scelta migliore.

La frequenza di inserimento o generazione dei log di 150 MB/s è disponibile come funzionalità di anteprima con consenso esplicito. Per altre informazioni e per acconsentire esplicitamente a 150 MB/s, vedere Blog: Miglioramenti di Hyperscale di novembre 2024.

Non al momento. È tuttavia possibile ridimensionare le risorse di calcolo e il numero di repliche per ridurre i costi durante i tempi non di picco oppure usare l'elaborazione serverless per ridimensionare automaticamente il calcolo in base all'utilizzo.

Per i carichi di lavoro in lettura, è possibile creare una replica denominata con dimensioni di calcolo superiori (più core e memoria) rispetto alla replica primaria. Per altre informazioni sulle dimensioni di calcolo disponibili, vedere Dimensioni di calcolo e archiviazione del livello Hyperscale.

Per i carichi di lavoro di lettura, ciò si può ottenere usando repliche denominate.

È possibile dimensionare il numero di repliche secondarie a disponibilità elevata impostandolo su un valore compreso tra 0 e 4 nel portale di Azure o tramite l'API REST. È anche possibile creare fino a 30 repliche denominate per molti scenari di scalabilità in lettura.

Nei database Hyperscale la resilienza dei dati viene fornita a livello di archiviazione. È necessaria solo una replica (quella primaria) per fornire la resilienza. Quando la replica di calcolo non è attiva, viene creata automaticamente una nuova replica senza alcuna perdita di dati.

Tuttavia, se è presente solo la replica primaria, potrebbe volerci un minuto o due per creare una nuova replica dopo il failover, rispetto a secondi nel caso in cui sia disponibile una replica secondaria a disponibilità elevata. La nuova replica avrà inizialmente cache a freddo, il che può determinare una latenza di archiviazione più elevata e una riduzione delle prestazioni delle query immediatamente dopo il failover.

Per le app cruciali che richiedono disponibilità elevata con impatto minimo sul failover, è necessario effettuare il provisioning di almeno una replica secondaria a disponibilità elevata per garantire che una replica hot standby sia disponibile per fungere da destinazione del failover.

La dimensione massima di un singolo database Hyperscale è attualmente di 128 TB. La dimensione massima di un database in un pool elastico Hyperscale è attualmente di 100 TB.

In Hyperscale, il log delle transazioni è praticamente infinito, con una restrizione che la parte attiva del log non può superare 1 TB. La parte attiva del log può aumentare per via di transazioni a esecuzione prolungata o a causa dell'elaborazione di Change Data Capture senza rimanere al livello della frequenza di modifica dei dati. Evitare transazioni inutilmente lunghe e grandi per rimanere al di sotto di questo limite. Oltre a questa restrizione, non è necessario preoccuparsi di esaurire lo spazio di log in un sistema con produttività di log elevata. La frequenza di generazione dei log potrebbe tuttavia venire limitata per i carichi di lavoro di scrittura impegnativi e continui. Il picco di frequenza di generazione dei log sostenibile è di 100 MB/s.

La frequenza di generazione dei log di 150 MB/s è disponibile come funzionalità di anteprima del consenso esplicito. Per altre informazioni e per acconsentire esplicitamente a 150 MB/s, vedere Blog: Miglioramenti di Hyperscale di novembre 2024.

Il database tempdb si trova nella risorsa di archiviazione SSD locale e le sue dimensioni sono proporzionali alle dimensioni di calcolo (numero di core) di cui è stato effettuato il provisioning. Le dimensioni di tempdb non sono configurabili e vengono gestite automaticamente. Per determinare le dimensioni massime di tempdb per il database, vedere Dimensioni di archiviazione e di calcolo di Hyperscale.

Le dimensioni del database aumentano automaticamente man mano che si inseriscono dati.

10 GB. Un database Hyperscale viene creato con una dimensione iniziale di 10 GB e aumenta secondo necessità in blocchi di 10 GB.

Ogni file di dati aumenta di 10 GB. Più file di dati possono aumentare contemporaneamente.

Con il livello Hyperscale, i file di dati vengono archiviati in Archiviazione Standard di Azure. I dati vengono completamente memorizzati nella cache della risorsa di archiviazione SSD locale, nei server di pagine remoti alle repliche di calcolo. Le repliche di calcolo hanno anche cache di dati nell'unità SSD locale e in memoria, per ridurre la frequenza di recupero dei dati dai server di pagine remoti.

No. I file di dati vengono aggiunti automaticamente al filegroup PRIMARY. I motivi comuni per la creazione di filegroup aggiuntivi non si applicano all'architettura di archiviazione Hyperscale, o più ampiamente al database SQL di Azure.

No.

Sì, le operazioni di compattazione di database e file sono attualmente in anteprima. Per altre informazioni sull’anteprima, vedere Compattazione per Database SQL di Azure Hyperscale.

Sì, proprio come in qualsiasi altro database del database DB Azure SQL. Ciò include la compressione di righe, pagine e columnstore.

Sì. Le pagine di dati associate a una determinata tabella possono venire distribuite in più file di dati, che fanno tutti parte dello stesso filegroup. Il motore di database di MSSQL usa una strategia di riempimento proporzionale per distribuire i dati nei file di dati.

Sì. È possibile spostare i database esistenti nel database SQL di Azure al livello Hyperscale. Per i modelli di verifica (PoC), è consigliabile creare una copia del database ed eseguire la migrazione della copia al livello di servizio Hyperscale.

Il tempo necessario per spostare in Hyperscale un database esistente equivale a quello necessario per copiare i dati e riprodurre le modifiche apportate nel database di origine durante la copia dei dati. Il tempo necessario per copiare i dati è proporzionale alle dimensioni dei dati. Il tempo necessario per riprodurre le modifiche è minore se lo spostamento viene eseguito durante un periodo di attività di scrittura ridotta.

Ottenere il codice di esempio per eseguire la migrazione di database SQL di Azure esistenti a Hyperscale nella portale di Azure, nell'interfaccia della riga di comando di Azure, in PowerShell e transact-SQL in Eseguire la migrazione di un database esistente a Hyperscale.

È disponibile una funzionalità di anteprima, Migrazione inversa, che permette ai clienti che di recente hanno eseguito la migrazione al livello di servizio Hyperscale per un database esistente nel database SQL di Azure di tornare indietro se Hyperscale non soddisfa le loro esigenze. Anche se la migrazione inversa viene avviata da una modifica al livello di servizio, si tratta essenzialmente di un'operazione di dimensioni dei dati tra architetture diverse. Analogamente alla migrazione a Hyperscale, la migrazione inversa è più veloce se effettuata durante un periodo di attività di scrittura ridotta. Informazioni sulle limitazioni per la migrazione inversa.

Se la migrazione di un database esistente in database SQL di Azure al livello di servizio Hyperscale è già stata eseguita in precedenza, è possibile eseguire la migrazione inversa 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, bisogna prima invertire la migrazione al livello di servizio Per utilizzo generico e poi cambiare il livello di servizio. La migrazione inversa è una dimensione dell'operazione di dati.

Non è possibile spostare i database creati nel livello di servizio Hyperscale ad altri livelli di servizio.

Informazioni su come invertire la migrazione da Hyperscale e limitazioni per la migrazione inversa e i criteri di backup conivolti.

Sì. Alcune funzionalità di database SQL di Azure non sono ancora supportate in Hyperscale. Se alcune di queste funzionalità sono abilitate per il database, la migrazione a Hyperscale potrebbe essere bloccata o queste funzionalità smetteranno di funzionare dopo la migrazione. Si prevede che queste limitazioni siano temporanee. Per informazioni dettagliate, vedere Limitazioni note.

Sì. È possibile usare molte tecnologie di migrazione esistenti per eseguire la migrazione a Hyperscale, inclusa la replica transazionale, e qualsiasi altra tecnologia di spostamento dati (copia bulk, Azure Data Factory, Azure Databricks, SSIS). Vedere anche il Servizio Migrazione del database di Azure, che supporta diversi scenari di migrazione.

Il tempo di inattività per la migrazione a Hyperscale è lo stesso di quando si esegue la migrazione dei database ad altri livelli di servizio del database SQL di Azure. È possibile usare la replica transazionale per ridurre al minimo il tempo di inattività per la migrazione di database con dimensioni fino a qualche TB. Per i database di dimensioni molto estese (più di 10 TB), può essere opportuno implementare il processo di migrazione dei dati usando ADF, Spark o altre tecnologie di spostamento dati in blocco.

Hyperscale è in grado di utilizzare 100 MB/s di dati nuovi/modificati, ma il tempo necessario per spostare i dati nei database nel database SQL di Azure dipende anche dalla velocità effettiva di rete disponibile, dalla velocità di lettura dell'origine e dall'obiettivo del livello di servizio del database di destinazione. La frequenza di generazione dei log di 150 MB/s è disponibile come funzionalità di anteprima del consenso esplicito. Per altre informazioni e per acconsentire esplicitamente a 150 MB/s, vedere Blog: Miglioramenti di Hyperscale di novembre 2024.

È possibile fare in modo che un'applicazione client legga i dati da Archiviazione di Azure e carichi i dati in un database Hyperscale (proprio come con qualsiasi altro database nel database SQL di Azure). La tecnologia PolyBase non è attualmente supportata nel database SQL di Azure. Come alternativa per assicurare un caricamento rapido, è possibile usare Azure Data Factory oppure un processo Spark in Azure Databricks con il connettore Spark per SQL. Il connettore Spark per SQL supporta l'inserimento bulk.

È anche possibile leggere in blocco i dati dall'archivio BLOB di Azure usando BULK INSERT o OPENROWSET: esempi di accesso bulk ai dati in Archiviazione BLOB di Azure.

Il modello di recupero con registrazione minima o con registrazione bulk non è supportato nel livello Hyperscale. Per assicurare la disponibilità elevata e il ripristino temporizzato, è richiesto il modello di recupero con registrazione completa. L'architettura del log Hyperscale offre tuttavia una velocità di inserimento dei dati più elevata rispetto ad altri livelli di servizio del database SQL di Azure.

No. Hyperscale è un'architettura SMP (Symmetric Multi-Processing) e non un'architettura MPP (Massively Parallel Processing) o multimaster. È possibile solo creare più repliche per aumentare il numero di istanze per i carichi di lavoro di sola lettura.

Sì. Il Servizio Migrazione del database di Azure supporta diversi scenari di migrazione.

Vedere Contratto di Servizio per database SQL di Azure. Consigliamo di aggiungere repliche secondarie a disponibilità elevata per carichi di lavoro critici. Ciò consente un failover più rapido e riduce il potenziale impatto sulle prestazioni subito dopo il failover.

Sì.

Sì, Hyperscale supporta la configurazione con ridondanza della zona. Per abilitare la configurazione con ridondanza della zona per Hyperscale, è necessaria almeno una replica secondaria a disponibilità elevata e l'uso dell'archiviazione con ridondanza geografica della zona o con ridondanza della zona.

Sì. Per altre informazioni, vedere Pool elastici Hyperscale e blog: i pool elastici Hyperscale sono ora disponibili a livello generale.

Per i database Hyperscale non sono previsti i tradizionali backup dei log completi, differenziali e delle transazioni. Vi sono invece snapshot di archiviazione regolari dei file di dati, con una cadenza di snapshot separata per ogni file. Il log delle transazioni generato viene mantenuto invariato per il periodo di conservazione configurato. Al momento del ripristino, i record deli log delle transazioni pertinenti vengono applicati a snapshot di archiviazione ripristinati. Indipendentemente dalla cadenza di snapshot, ciò determina un database coerente dal punto di vista transazionale senza perdite di dati a partire dal punto temporale specificato entro il periodo di conservazione. In effetti, il backup del database in Hyperscale è continuo.

Sì.

L'obiettivo del punto di ripristino per il ripristino temporizzato è di 0 minuti. La maggior parte delle operazioni di ripristino temporizzato viene completata entro 60 minuti indipendentemente dalle dimensioni del database. Il tempo di ripristino può essere più elevato per i database di dimensioni maggiori e se il database ha riscontrato un'attività di scrittura significativa entro il punto di ripristino nel tempo. La modifica della ridondanza dell'archiviazione quando si esegue un ripristino può comportare tempi di ripristino più lunghi, poiché il ripristino corrisponde alla dimensione dei dati e quindi il tempo necessario sarà proporzionale alle dimensioni del database.

No. I backup vengono gestiti dal sottosistema di archiviazione e usano gli snapshot di archiviazione. Non influiscono sui carichi di lavoro degli utenti.

Sì. Il ripristino geografico è completamente supportato se viene usata l'archiviazione con ridondanza geografica. Questo è il valore predefinito per i nuovi database. A differenza del ripristino temporizzazione, il ripristino geografico richiede un'operazione di ridimensionamento dei dati. I file di dati vengono copiati in parallelo, quindi la durata di questa operazione dipende principalmente dalle dimensioni del file più grande del database, più che dalle dimensioni totali del database. Il tempo di ripristino geografico sarà notevolmente più breve se il database viene ripristinato nell'area di Azure associata all'area del database di origine.

Sì. La replica geografica può essere configurata per database Hyperscale.

No. Il formato di archiviazione per i database Hyperscale è diverso da quello di qualsiasi versione rilasciata di SQL Server e non è possibile controllare i backup o accedervi. Per recuperare i dati da un database Hyperscale, è possibile estrarli usando qualsiasi tecnologia di spostamento dati, ossia Azure Data Factory, Azure Databricks, SSIS e così via.

Sì. A partire dal 4 maggio 2022, i backup per tutti i nuovi database vengono addebitati in base all'archivio di backup usato e alla ridondanza di archiviazione selezionata a tariffe acquisite nella pagina dei prezzi di database SQL di Azure. Per i database Hyperscale creati prima del 4 maggio 2022, i backup verranno addebitati solo se la conservazione dei backup è impostata su un valore maggiore di sette giorni. Per altre informazioni, vedere Backup di Hyperscale e ridondanza di archiviazione.

Informazioni dettagliate su come misurare le dimensioni dell'archivio di backup sono riportate in Backup automatici.

Per determinare la fattura dell'archivio di backup, le dimensioni dell'archivio di backup vengono calcolate periodicamente e moltiplicate per la frequenza di archivio di backup e il numero di ore dall'ultimo calcolo. Per stimare la fattura di backup per un periodo di tempo, moltiplicare le dimensioni dell'archivio di backup fatturabili per ogni ora del periodo per la frequenza di archivio di backup e aggiungere tutti gli importi orari. Per eseguire query sulle metriche pertinenti di Monitoraggio di Azure per molteplici intervalli orari a livello di codice, usare l'API REST di Monitoraggio di Azure. La fatturazione del backup nel livello di elaborazione serverless è identica a quella del livello di calcolo con provisioning.

I costi di backup saranno maggiori per i carichi di lavoro che aggiungono, modificano o eliminano grandi volumi di dati nel database. Al contrario, i carichi di lavoro che sono per lo più di sola lettura possono avere costi di backup minori.

Informazioni dettagliate su come minimizzare i costi dell'archivio di backup sono riportate in Backup automatici.

Attualmente, i livelli di servizio non Hyperscale (Standard/Premium/Utilizzo generico/Business Critical) non possono essere ripristinati geograficamente in un livello di servizio Hyperscale e viceversa. Per convertire un database non Hyperscale in un database Hyperscale, modificare il livello di servizio dopo un ripristino.

Il limite di velocità effettiva per il log delle transazioni è impostato su 100 MB/s per qualsiasi dimensione di calcolo Hyperscale. La possibilità di raggiungere questa velocità dipende da più fattori, inclusi, ad esempio, il tipo di carico di lavoro, la configurazione client e le prestazioni, e la disponibilità di capacità di calcolo sufficiente nella replica di calcolo primaria per generare il record di log a questa velocità. La frequenza di generazione dei log di 150 MB/s è disponibile come funzionalità di anteprima del consenso esplicito. Per altre informazioni e per acconsentire esplicitamente a 150 MB/s, vedere Blog: Miglioramenti di Hyperscale di novembre 2024.

Le operazioni di I/O al secondo e la latenza di I/O varieranno a seconda dei modelli di carico di lavoro. Se i dati a cui si accede vengono memorizzati nella cache RBPEX nella replica di calcolo, le prestazioni di I/O saranno simili a quelle dei livelli di servizio business critical o Premium.

No. Il calcolo è separato dal livello di archiviazione. In questo modo il backup non ha effetto sulle prestazioni.

Poiché lo spazio di archiviazione è condiviso e non viene eseguita alcuna replica fisica diretta tra le repliche di calcolo primarie e secondarie, la velocità effettiva nella replica primaria non sarà direttamente interessata dall'aggiunta di repliche secondarie. Tuttavia, i carichi di lavoro di scrittura continui e aggressivi potrebbero essere limitati nei nodi prmari per consentire l'applicazione del log nelle repliche secondarie e permettere ai server di pagina di recuperare. In questo modo si evitano prestazioni di lettura scarse nelle repliche secondarie e il recupero lungo dopo il failover in una replica secondaria a disponibilità elevata.

Sì. Tuttavia, proprio come in altri database DB di Azure SQL, le connessioni potrebbero essere terminate da errori temporanei poco frequenti, che possono interrompere query a esecuzione prolungata ed eseguire il rollback delle transazioni. Una causa di errori temporanei è che il sistema sposta rapidamente il database in un nodo di calcolo diverso per garantire elaborazione prolungata e disponibilità delle risorse di archiviazione o per eseguire la manutenzione pianificata. La maggior parte di questi eventi di riconfigurazione viene completata in meno di 10 secondi. Le applicazioni che si connettono al database devono essere sviluppate in modo da prevedere e tollerare tali errori temporanei non frequenti attraverso l'implementazione della logica di ripetizione dei tentativi. Inoltre, è consigliabile configurare una finestra di manutenzione che corrisponda alla pianificazione del carico di lavoro per evitare errori temporanei dovuti alla manutenzione pianificata.

Per la maggior parte dei problemi di prestazioni, in particolare per quelli non relativi alle prestazioni di archiviazione, sono valide le comuni procedure di diagnostica e risoluzione dei problemi di SQL. Per la diagnostica dei problemi di archiviazione specifici di Hyperscale, vedere Diagnostica e risoluzione dei problemi relativi alle prestazioni di SQL Hyperscale.

La quantità massima di memoria di cui un database serverless può aumentare è di 3 GB/vCore volte il numero massimo di vCore configurati rispetto a più di 5 GB/vCore volte lo stesso numero di vCore nel calcolo con provisioning. Per informazioni dettagliate, vedere Limiti delle risorse Hyperscale serverless.

L'aumento o la riduzione nel livello di calcolo con provisioning richiede generalmente fino a 2 minuti indipendentemente dalle dimensioni dei dati. Nel livello di elaborazione serverless, in cui il calcolo viene dimensionato automaticamente in base alla domanda del carico di lavoro, il tempo di ridimensionamento è in genere in sottosecondi, ma può richiedere occasionalmente il tempo necessario per il ridimensionamento del calcolo con provisioning.

No. Un database rimane online durante le operazioni di aumento o riduzione delle prestazioni.

L'aumento o la riduzione del calcolo con provisioning comporta l'eliminazione delle connessioni quando si verifica un failover al termine dell'operazione di ridimensionamento. Nell'elaborazione serverless, il dimensionamento automatico non comporta generalmente l'eliminazione di una connessione, ma può verificarsi occasionalmente. L'aggiunta o la rimozione di repliche secondarie non comporta le eliminazioni delle connessioni nella replica primaria.

Il ridimensionamento nel calcolo con provisioning viene eseguito dall'utente finale. Il ridimensionamento automatico nell'elaborazione serverless viene eseguito dal servizio.

Sì. Le dimensioni del database tempdb e della cache RBPEX nei nodi di calcolo aumentano automaticamente con l'aumentare del numero dei core. Per informazioni dettagliate, vedere Dimensioni di calcolo e archiviazione del livello Hyperscale.

No. Solo la replica di calcolo primaria accetta le richieste di lettura/scrittura. Le repliche di calcolo secondarie accettano solo le richieste di sola lettura.

Hyperscale supporta repliche a disponibilità elevata, repliche denominate e repliche geografiche. Per informazioni dettagliate, vedere Repliche secondarie di Hyperscale.

Tra 0 e 4. Per modificare il numero di repliche, è possibile usare il portale di Azure o l'API REST.

È possibile connettersi a queste repliche di calcolo aggiuntive di sola lettura impostando la proprietà ApplicationIntent nella stringa di connessione su ReadOnly. Tutte le connessioni contrassegnate con ReadOnly vengono indirizzate automaticamente a una delle repliche secondarie a disponibilità elevata, se presenti. Per informazioni dettagliate, vedere Usare le repliche di sola lettura per l'offload dei carichi di lavoro di query di sola lettura.

È possibile eseguire la query SQL seguente: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Il risultato è READ_ONLY se si è connessi a una replica secondaria di sola lettura e READ_WRITE se si è connessi alla replica primaria. Il contesto del database deve essere impostato sul nome del database, non sul database master.

No. È possibile connettersi alle repliche secondarie a disponibilità elevata solo specificando ApplicationIntent=ReadOnly. Tuttavia, è possibile usare endpoint dedicati per le repliche denominate.

No. Una nuova connessione con finalità di sola lettura viene reindirizzata a una replica secondaria arbitraria a disponibilità elevata.

Non nel livello di calcolo con provisioning. Le repliche secondarie a disponibilità elevata vengono usate come destinazioni di failover a disponibilità elevata, quindi devono avere la stessa configurazione della replica primaria per garantire le prestazioni previste dopo il failover. In serverless, il calcolo viene ridimensionato automaticamente per ogni replica a disponibilità elevata in base alla domanda di carico di lavoro individuale. Ogni replica secondaria a disponibilità elevata può comunque effettuare una scalabilità automatica dei core configurati per supportare il ruolo post-failover. Le repliche denominate consentono di ridimensionare ogni replica in modo indipendente.

No. Il database tempdb viene configurato in base alle dimensioni di calcolo con provisioning; le repliche secondarie a disponibilità elevata hanno le stesse dimensioni, inclusa tempdb, della replica di calcolo primaria. Nelle repliche denominate, tempdb viene ridimensionato in base alle dimensioni di calcolo della replica, pertanto può essere più piccolo o più grande rispetto a tempdb nella replica primaria.

No. I database Hyperscale hanno un'archiviazione condivisa e ciò significa che tutte le repliche di calcolo visualizzano gli stessi indici, tabelle e altri oggetti database. Per avere indici aggiuntivi ottimizzati per le operazioni di lettura nelle repliche secondarie, è necessario aggiungerli nella replica primaria. È comunque possibile creare tabelle temporanee (nomi di tabella preceduti da # o ##) in ogni replica secondaria per archiviare dati temporanei. Le tabelle temporanee sono di lettura/scrittura.

La latenza dei dati dal momento in cui viene eseguito il commit di una transazione nella replica primaria al momento in cui la transazione è leggibile in una replica secondaria dipende dalla frequenza di generazione del log corrente, dalle dimensioni della transazione, dal carico sulla replica e da altri fattori. La latenza dei dati per le transazioni di piccole dimensioni è in genere di qualche decina di millisecondi, ma non esiste un limite massimo per la latenza dei dati. I dati in una determinata replica secondaria sono sempre coerenti in modo transazionale, pertanto le transazioni più grandi richiedono più tempo per la propagazione. Tuttavia, in un determinato momento la latenza dei dati e lo stato del database possono essere diversi per le varie repliche secondarie. I carichi di lavoro che devono leggere immediatamente i dati di cui è stato eseguito il commit dovranno essere eseguiti nella replica primaria.

No, le repliche denominate non possono essere usate come destinazione del failover per la replica primaria. A tale scopo, aggiungere le repliche a disponibilità elevata.

Poiché ogni replica denominata può avere un obiettivo diverso del livello di servizio e quindi può essere usata per casi d'uso diversi, non esiste un modo predefinito per indirizzare il traffico di sola lettura inviato alla replica primaria verso un set di repliche denominate. Ad esempio, è possibile avere otto repliche denominate e indirizzare il carico di lavoro OLTP solo alle repliche denominate da 1 a 4, mentre tutti i carichi di lavoro analitici di Power BI usano le repliche denominate 5 e 6, e il carico di lavoro data science usa le repliche 7 e 8. A seconda dello strumento o del linguaggio di programmazione in uso, le strategie per distribuire tale carico di lavoro potrebbero variare. Per un esempio di creazione di una soluzione di routing del carico di lavoro per consentire l'aumento del back-end REST, consultare l’esempio di scale out OLTP.

No, poiché le repliche denominate usano gli stessi server di pagina della replica primaria e devono trovarsi nella stessa area.

Una replica denominata non può influire sulla disponibilità della replica primaria. In circostanze normali, è improbabile che le repliche denominate influiscano sulle prestazioni della replica primaria. Tuttavia potrebbe verificarsi un impatto nel caso vengano eseguiti carichi di lavoro intensivi. Analogamente a una replica a disponibilità elevata, viene mantenuta la sincronizzazione tra la replica denominata e la replica primaria tramite il servizio di log delle transazioni. Se una replica denominata, per qualsiasi motivo, non è in grado di utilizzare i log delle transazioni abbastanza velocemente, verrà chiesto alla replica primaria di rallentare (limitare) la generazione del log, in modo che possa recuperare. Anche se questo comportamento non influisce sulla disponibilità della replica primaria, può influire sulle prestazioni dei carichi di lavoro di scrittura nella replica primaria. Per evitare questa situazione, assicurarsi che le repliche denominate abbiano capacità aggiuntiva sufficiente, principalmente CPU, per elaborare il log delle transazioni senza ritardo. Ad esempio, se la replica primaria elabora numerose modifiche ai dati, è consigliabile che le repliche denominate abbiano almeno lo stesso obiettivo del livello di servizio della replica primaria, per evitare la saturazione della CPU nelle repliche e quindi forzare il rallentamento della replica primaria.

Le repliche denominate saranno comunque disponibili per l'accesso in sola lettura, come di consueto.

Per impostazione predefinita, le repliche denominate non hanno alcuna replica a disponibilità elevata propria. Un failover di una replica denominata richiede prima di tutto la creazione di una nuova replica, che in genere richiede circa 1-2 minuti. Tuttavia, le repliche denominate possono anche trarre vantaggio dalla disponibilità più elevata e dai failover più brevi forniti dalle repliche a disponibilità elevata. Per aggiungere repliche a disponibilità elevata per una replica denominata, è possibile usare il parametro ha-replicas con l'AZ CLI, o il parametro HighAvailabilityReplicaCount con PowerShell, o la proprietà highAvailabilityReplicaCount con l'API REST. Il numero di repliche a disponibilità elevata può essere impostato durante la creazione di una replica denominata e può essere modificato, solo tramite l'interfaccia della riga di comando AZ, PowerShell o l'API REST, in qualsiasi momento dopo la creazione della replica denominata. I prezzi delle repliche a disponibilità elevata per le repliche denominate sono gli stessi delle repliche a disponibilità elevata per i normali database di Hyperscale.

Sì. La chiave master della colonna viene archiviata nel database utente e può essere convalidata eseguendo la query SELECT * FROM sys.column_master_keys. Le repliche denominate e le repliche secondarie a disponibilità elevata leggono i dati dallo stesso livello di archiviazione/server di pagina del database Hyperscale primario. Entrambi i tipi di repliche vengono sincronizzati con il database Hyperscale primario tramite il servizio di log. Una modifica della chiave viene considerata una transazione e viene replicata automaticamente nella replica denominata e nella replica secondaria a disponibilità elevata.

La funzione DATABASEPROPERTYEX(), se eseguita all'interno del contesto di una replica denominata, può eseguire il mapping dell'oggetto replica_id alla replica denominata corrispondente. Tuttavia, non è attualmente possibile collegare l'oggetto replica_id alla rispettiva replica denominata per ogni record nella DMV sys.dm_database_replica_states quando viene eseguita una query dalla replica primaria. La query di esempio seguente può essere eseguita all'interno del contesto di una replica denominata per identificare il nome della replica, l'ID replica e i dettagli di sincronizzazione.

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

Contenuto correlato

Per altre informazioni sul livello di servizio Hyperscale, vedere Livello di servizio Hyperscale.