Domande frequenti su Hyperscale per il database SQL di Azure

Un database Hyperscale è un database nel database SQL di Azure supportato dalla tecnologia hyperscale di archiviazione con scalabilità orizzontale. 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 di 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 per database singoli (con provisioning e serverless) e per i pool elastici che usano il modello di acquisto basato su vCore. 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, indipendentemente dalle dimensioni di calcolo.
• 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).
• Velocità effettiva del log delle transazioni superiore 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 e la riduzione delle prestazioni non è un'operazione di dimensioni dei dati.

  Il supporto per di calcolo serverless offre scalabilità automatica e riduzione delle prestazioni e fatturazione di calcolo 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 delle transazioni predefinito è READ COMMITTED con l'opzione di database READ_COMMITTED_SNAPSHOT (RCSI) abilitata. Nelle repliche secondarie il livello di isolamento è 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 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 MiB/s è disponibile come funzionalità di anteprima con consenso esplicito per la memoria ottimizzata per la serie Premium e la memoria premium. Per altre informazioni e per acconsentire esplicitamente a 150 MiB/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. Ogni replica denominata può avere fino a 4 repliche secondarie a disponibilità elevata.

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

Tuttavia, se è presente solo la replica primaria, può essere necessario un minuto o due per creare una nuova replica, rispetto ai 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 applicazioni 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 di failover.

Le dimensioni massime di un singolo database Hyperscale sono attualmente di 128 TB, indipendentemente dalle dimensioni di calcolo. 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. Tuttavia, la frequenza di generazione dei log potrebbe essere ridotta per la scrittura continua di carichi di lavoro in modo aggressivo. Il picco di frequenza di generazione dei log sostenibile è di 100 MB/s.

La frequenza di generazione dei log di 150 MiB/s è disponibile come funzionalità di anteprima con consenso esplicito per la memoria della serie Premium e della serie Premium ottimizzata. Per altre informazioni e per acconsentire esplicitamente a 150 MiB/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 dimensioni iniziali di 10 GB e aumenta in base alle esigenze.

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. Sono incluse righe, pagine e columnstore compressione.

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ì. 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 è un'operazione di dimensioni dei 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à del database SQL di Azure non sono supportate in Hyperscale. Se alcune di queste funzionalità sono abilitate per il database, la migrazione a Hyperscale potrebbe essere bloccata o queste funzionalità non funzionano dopo la migrazione. 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, dal tipo di caricamento (bulk vs row-by-row) e dall'obiettivo del livello di servizio del database di destinazione. La frequenza di generazione dei log di 150 MiB/s è disponibile come funzionalità di anteprima con consenso esplicito per la memoria della serie Premium e della serie Premium ottimizzata. Per altre informazioni e per acconsentire esplicitamente a 150 MiB/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.

I modelli di recupero con registrazione minima o minima delle operazioni bulk non sono supportati in 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 creare più repliche per aumentare il numero di istanze dei 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 frequenza degli snapshot, questo comporta un database coerente in modo transazionale a partire dal punto nel tempo specificato entro il periodo di conservazione, senza perdita di dati. 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. L'esecuzione di un ripristino dopo una modifica recente di ridondanza dell'archiviazione potrebbe comportare tempi di ripristino più lunghi perché il ripristino può essere un'operazione di dimensioni dei dati in questo caso e il tempo di ripristino potrebbe essere 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 o con ridondanza geografica. L'archiviazione con ridondanza geografica è l'impostazione predefinita 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ì. di replica geografica e gruppi di failover possono essere configurati per i 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 estrarre i dati da un database Hyperscale, è possibile estrarre dati usando qualsiasi tecnologia di spostamento dei dati, ad esempio 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.

Per informazioni dettagliate su come misurare le dimensioni dell'archiviazione di backup, vedere Backup automatizzati.

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.

Per informazioni dettagliate su come ridurre al minimo i costi di archiviazione dei backup, vedere Backup automatizzati.

Attualmente, i livelli di servizio non Hyperscale (Basic/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 del log delle transazioni è di 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 MiB/s è disponibile come funzionalità di anteprima con consenso esplicito per la memoria della serie Premium e della serie Premium ottimizzata. Per altre informazioni e per acconsentire esplicitamente a 150 MiB/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 nell'archiviazione SSD locale nella replica di calcolo, si noteranno prestazioni di I/O simili ai 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é l'archiviazione è condivisa e non è presente alcuna replica fisica diretta tra repliche di calcolo primarie e secondarie, la velocità effettiva nella replica primaria non è direttamente interessata dall'aggiunta di repliche secondarie. Tuttavia, la frequenza dei log per i carichi di lavoro di scrittura continui e aggressivi potrebbe essere limitata al database primario per consentire l'applicazione del log nelle repliche secondarie e nei server di pagine. 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 SQL di Azure, le connessioni potrebbero essere terminate da errori temporanei molto frequenti, che possono interrompere query a esecuzione prolungata e 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 quelli non radicati nelle prestazioni di archiviazione, si applicano i passaggi comuni di diagnostica e risoluzione dei problemi di MSSQL. 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ì. Il database tempdb e cache SSD di calcolo dimensioni nei nodi di calcolo aumentano automaticamente man mano che il numero di core viene aumentato. 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. repliche denominate consentono di ridimensionare ogni replica denominata 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 i dati temporanei nel database tempdb. 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. In un determinato momento la latenza dei dati e lo stato del database potrebbero essere diversi per repliche secondarie diverse. 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. Aggiungere repliche a disponibilità elevata per la replica principale a tale scopo.

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. Tuttavia, se è stata creata una replica geografica per la replica primaria in un'area diversa, è possibile creare repliche denominate per la replica geografica.

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 il log delle transazioni abbastanza velocemente, inizia a chiedere alla replica primaria di ridurre la frequenza di generazione del log, in modo che possa essere recuperata. Anche se questo comportamento non influisce sulla disponibilità del database primario, può influire sulle prestazioni dei carichi di lavoro di scrittura nel database primario. Per evitare questa situazione, assicurarsi che le repliche denominate dispongano di risorse sufficienti, principalmente cpu, per elaborare il log delle transazioni senza ritardi. Ad esempio, se il database primario elabora numerose modifiche ai dati, è consigliabile avere repliche denominate con almeno le stesse dimensioni di calcolo della replica primaria per evitare di saturare la CPU nelle repliche e forzare il rallentamento della replica primaria.

Le repliche denominate sono ancora 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. È possibile aggiungere repliche a disponibilità elevata per una replica denominata nel portale di Azure oppure usare il parametro ha-replicas con l'interfaccia della riga di comando di AZoppure il parametro HighAvailabilityReplicaCount con PowerShello la proprietà highAvailabilityReplicaCount con API REST. Il numero di repliche a disponibilità elevata può essere impostato durante la creazione di una replica denominata e può essere modificato 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 le repliche primarie.

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 in tutte le repliche secondarie.

Non quando si esegue una query sys.dm_database_replica_states nella replica primaria. È tuttavia possibile connettersi a una replica denominata per determinare l'ID di replica e altri dettagli usando la query di esempio seguente:

  SELECT replica_id,
         DB_NAME() AS named_replica_database_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,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

Contenuto correlato

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