Domande frequenti su Hyperscale per il database SQL di Azure

Un database Hyperscale è un database in database SQL supportato dalla tecnologia di archiviazione con scalabilità orizzontale Hyperscale. Un database Hyperscale supporta fino a 100 TB di dati e offre velocità effettiva e prestazioni elevate, oltre che velocità di ridimensionamento per adattarsi ai requisiti dei carichi di lavoro. Connessione ivity, query processing, database engine features e così via, funzionano come qualsiasi altro database in 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 sono differenziati in base alla disponibilità del database e al tipo di archiviazione, alle prestazioni e alle dimensioni massime di archiviazione, come descritto in Confronto tra limiti di risorse.

Il livello di servizio Hyperscale è destinato a tutti i clienti che richiedono prestazioni e disponibilità più elevate, backup e ripristino rapidi e/o scalabilità di calcolo e archiviazione veloci. Sono inclusi i clienti 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 fino a 100 TB.
• Backup rapidi del database indipendentemente dalle dimensioni del database (i backup sono basati su snapshot di archiviazione).
• Ripristini rapidi del database indipendentemente dalle dimensioni del database (i ripristini provengono da snapshot di archiviazione).
• Velocità effettiva del log più elevata indipendentemente dalle dimensioni del database e dal numero di vCore.
• Read Scale-out using one or more read-only replicas, used for offloading read-only workloads or as hot standby databases.
• 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 il calcolo serverless, indipendentemente dalle dimensioni del database.

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

Sì. Per altre informazioni e limiti sul numero di database per server, vedere database SQL limiti delle risorse 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, la scalabilità verticale e la riduzione delle prestazioni non è un'operazione di dimensioni dei dati.

  Il supporto per il calcolo serverless offre scalabilità automatica e riduzione delle prestazioni e il calcolo viene fatturato in base all'utilizzo.

• Scalabilità orizzontale

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

  • Fino a quattro repliche a disponibilità elevata con le stesse dimensioni di calcolo della replica primaria. Queste repliche fungono da repliche hot standby per eseguire rapidamente il failover dal database primario. È anche possibile usarli 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à orizzontale in lettura.
  • Una replica geografica in un'area di Azure diversa da proteggere da interruzioni a livello di area e per abilitare la scalabilità orizzontale 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. Questo è lo stesso di qualsiasi altro database SQL di Azure.

Con il nuovo prezzo semplificato in vigore dal 15 dicembre 2023, il prezzo di calcolo per i database Hyperscale appena creati, tutti i database Hyperscale serverless e tutti i pool elastici Hyperscale sono stati ridotti. 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 con provisioning (creati prima del 15 dicembre 2023). Per tali database meno recenti, AHB è applicabile solo fino a dicembre 2026, dopo il quale tali 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 carico di lavoro, inclusi 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 pochi TB fino a 100 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), Azure Synapse Analytics o Microsoft Fabric potrebbe essere la scelta migliore.

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

Per i carichi di lavoro di 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 Hyperscale.

Per i carichi di lavoro di lettura, è possibile usare repliche denominate.

È possibile ridimensionare il numero di repliche secondarie a disponibilità elevata tra 0 e 4 usando portale di Azure o l'API REST. È anche possibile creare fino a 30 repliche denominate per molti scenari di scalabilità orizzontale in lettura.

Nei database Hyperscale la resilienza dei dati viene fornita a livello di archiviazione. È necessaria una sola replica (primaria) per fornire 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, può essere necessario un minuto o due per creare una nuova replica dopo il failover, 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ò comportare 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 di failover.

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 a causa di transazioni a esecuzione prolungata o a causa dell'elaborazione di Change Data Capture non mantenendo al passo con la frequenza di modifica dei dati. Evitare inutilmente transazioni lunghe e di grandi dimensioni 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 velocità effettiva 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.

Il tempdb database si trova nell'archiviazione SSD locale e viene ridimensionato proporzionalmente alle dimensioni di calcolo (il numero di core) di cui si effettua il provisioning. Le dimensioni di tempdb non sono configurabili e sono gestite per l'utente. 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 in blocchi da 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 memorizzati completamente nella cache nell'archiviazione SSD locale, nei server di pagine remoti per le 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 PRIMARY filegroup. I motivi comuni per la creazione di filegroup aggiuntivi non si applicano nell'architettura di archiviazione Hyperscale o in database SQL di Azure su larga scala.

No.

Non al momento.

Sì, proprio come in qualsiasi altro database del database SQL di Azure. Sono incluse 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 MSSQL usa una strategia di riempimento proporzionale per distribuire i dati sui 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 sarà 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.

La migrazione inversa al livello di servizio Per utilizzo generico consente ai clienti che hanno recentemente migrato un database esistente in database SQL di Azure al livello di servizio Hyperscale di tornare indietro, se Hyperscale non soddisfa le proprie esigenze. Mentre la migrazione inversa viene avviata da una modifica del 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 eseguita durante un periodo di attività di scrittura ridotta. Informazioni sulle limitazioni per la migrazione inversa.

Se in precedenza è stata eseguita la migrazione di un database SQL di Azure esistente al livello di servizio Hyperscale, è possibile annullare la migrazione 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. La migrazione inversa è una dimensione dell'operazione di dati.

I database creati nel livello di servizio Hyperscale non possono essere spostati in altri livelli di servizio.

Informazioni su come invertire la migrazione da Hyperscale, incluse le limitazioni per la migrazione inversa e i criteri di backup interessati.

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 dei 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 i tempi di inattività della migrazione per i database con dimensioni fino a pochi TB. Per i database di dimensioni molto grandi (10+ TB), è possibile valutare la possibilità di implementare il processo di migrazione usando ADF, Spark o altre tecnologie di spostamento dei 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.

È 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. È consigliabile aggiungere repliche secondarie a disponibilità elevata per carichi di lavoro critici. Ciò consente un failover più rapido e riduce il potenziale impatto sulle prestazioni immediatamente 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 della zona o con ridondanza geografica. Il supporto per le repliche denominate Hyperscale con ridondanza della zona è attualmente in anteprima.

Sì. I pool elastici Hyperscale sono attualmente in anteprima. I pool elastici Hyperscale con ridondanza della zona sono attualmente disponibili in anteprima.

Per i database Hyperscale non sono previsti i tradizionali backup dei log completi, differenziali e delle transazioni. Esistono 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. In fase di ripristino, i record del log delle transazioni pertinenti vengono applicati agli snapshot di archiviazione ripristinati. Indipendentemente dalla frequenza degli snapshot, questo comporta un database coerente in modo transazionale senza perdita di dati a partire dal punto nel tempo specificato entro il periodo di conservazione. In effetti, il backup del database in Hyperscale è continuo.

Sì.

L'RPO per il ripristino temporizzato è 0 min. 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ù lungo per i database di dimensioni maggiori e se il database ha riscontrato un'attività di scrittura significativa prima e fino al punto di ripristino nel tempo. La modifica della ridondanza dell'archiviazione quando si esegue un ripristino può comportare tempi di ripristino più lunghi perché il ripristino è di dimensioni dei dati e di conseguenza il tempo 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. Si tratta dell'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ì. La replica geografica può essere configurata per i database Hyperscale.

No. Il formato di archiviazione per i database Hyperscale è diverso da 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, ovvero 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'archiviazione di backup usata 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 hyperscale e ridondanza dell'archiviazione.

Informazioni dettagliate su come misurare le dimensioni dell'archiviazione di backup vengono acquisite in Backup automatici.

Per determinare la fattura dell'archiviazione di backup, le dimensioni dell'archiviazione di backup vengono calcolate periodicamente e moltiplicate per la frequenza di archiviazione del backup e il numero di ore dall'ultimo calcolo. Per stimare la fattura del backup per un periodo di tempo, moltiplicare le dimensioni di archiviazione di backup fatturabili per ogni ora del periodo in base alla frequenza di archiviazione dei backup e aggiungere tutti gli importi orari. Per eseguire query sulle metriche pertinenti di Monitoraggio di Azure per intervalli orari multipli a livello di codice, usare l'API REST di Monitoraggio di Azure. La fatturazione del backup nel livello di calcolo 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 potrebbero avere costi di backup più piccoli.

Informazioni dettagliate su come ridurre al minimo i costi di archiviazione dei backup vengono acquisiti in Backup automatici.

Il limite di velocità effettiva per il log delle transazioni è impostato su 100 MB/s per qualsiasi dimensione di calcolo Hyperscale. La possibilità di ottenere questa velocità dipende da più fattori, tra cui, a titolo esemplificativo, il tipo di carico di lavoro, la configurazione client e le prestazioni e la capacità di calcolo sufficiente nella replica di calcolo primaria per produrre record di log a questa velocità.

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 si elimina l'impatto sulle prestazioni del backup.

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 verrà influenzata direttamente dall'aggiunta di repliche secondarie. Tuttavia, i carichi di lavoro di scrittura continui e aggressivi potrebbero essere limitati nel 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 ripristino lungo dopo il failover in una replica secondaria a disponibilità elevata.

Sì. Tuttavia, proprio come in altri database del 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 la disponibilità continua delle risorse di calcolo e archiviazione o per eseguire la manutenzione pianificata. La maggior parte di questi eventi di riconfigurazione termina in meno di 10 secondi. Le applicazioni che si connettono al database devono essere compilate per prevedere e tollerare questi errori temporanei poco frequenti implementando la 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 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 che 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.

Il ridimensionamento del livello di calcolo con provisioning richiede in genere fino a 2 minuti, indipendentemente dalle dimensioni dei dati. Nel livello di calcolo serverless, in cui il calcolo viene ridimensionato automaticamente in base alla domanda del carico di lavoro, il tempo di ridimensionamento è in genere sottosecondo, 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.

Il ridimensionamento delle risorse di calcolo sottoposte a provisioning comporta l'eliminazione delle connessioni quando si verifica un failover alla fine dell'operazione di ridimensionamento. Nel calcolo serverless, la scalabilità automatica in genere non comporta 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 nel calcolo serverless viene eseguito dal servizio.

Sì. Le dimensioni della tempdb cache di database e RBPEX nei nodi di calcolo aumentano automaticamente man mano che aumenta il numero di 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 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 di sola lettura aggiuntive impostando la ApplicationIntent proprietà nel 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 master database.

No. È possibile connettersi solo alle repliche secondarie a disponibilità elevata 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 a disponibilità elevata arbitraria.

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 offrire 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 secondario a disponibilità elevata può comunque ridimensionare automaticamente i core max configurati per supportare il ruolo post-failover. Le repliche denominate consentono di ridimensionare ogni replica in modo indipendente.

No. Il tempdb database viene configurato in base alle dimensioni di calcolo di cui è stato effettuato il provisioning. Le repliche secondarie a disponibilità elevata hanno le stesse dimensioni, tra cui tempdb, come il calcolo primario. Nelle repliche denominate, tempdb viene ridimensionato in base alle dimensioni di calcolo della replica, pertanto può essere minore o maggiore rispetto tempdb al database primario.

No. I database Hyperscale hanno un archivio condiviso, ovvero tutte le repliche di calcolo visualizzano le stesse tabelle, indici e altri oggetti di 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. Le tabelle temporanee sono di lettura/scrittura.

La latenza dei dati dal momento in cui viene eseguito il commit di una transazione nel database primario al momento in cui è leggibile in un database secondario dipende dalla frequenza di generazione del log corrente, dalle dimensioni delle transazioni, dal carico sulla replica e da altri fattori. La latenza dei dati tipica per le transazioni di piccole dimensioni è di decine di millisecondi, ma non esiste alcun limite superiore sulla 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 potrebbero essere diversi per le diverse 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 destinazioni di failover per la replica primaria. Aggiungere repliche a disponibilità elevata a tale scopo.

Poiché ogni replica denominata può avere un obiettivo del livello di servizio diverso e quindi essere usato per casi d'uso diversi, non esiste alcun modo predefinito per indirizzare il traffico di sola lettura inviato al database primario a un set di repliche denominate. Ad esempio, è possibile avere otto repliche denominate e si potrebbe voler indirizzare il carico di lavoro OLTP solo alle repliche denominate da 1 a 4, mentre i carichi di lavoro analitici di Power BI usano repliche denominate 5 e 6 e il carico di lavoro di data science usa repliche 7 e 8. A seconda dello strumento o del linguaggio di programmazione usato, le strategie per distribuire tale carico di lavoro possono variare. Per un esempio di creazione di una soluzione di routing del carico di lavoro per consentire a un back-end REST di aumentare il numero di istanze, vedere l'esempio di scalabilità orizzontale 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. È improbabile che le repliche denominate, in circostanze normali, influiscano sulle prestazioni del database primario, ma possono verificarsi se sono in esecuzione 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, inizierà a chiedere alla replica primaria di rallentare (limitare) la generazione del log, in modo che possa recuperare. 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 lo stesso obiettivo del livello di servizio del database primario 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 dispongono di repliche a disponibilità elevata personalizzate. 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'interfaccia della riga di comando di Azure o il parametro HighAvailabilityReplicaCount con PowerShell o la proprietà con l'API highAvailabilityReplicaCountREST. 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 di 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 corrispondono alle repliche a disponibilità elevata per i normali database Hyperscale.

Contenuto correlato

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