Come gestire un database Hyperscale
Si applica a:
Database SQL di Azure
Il livello di servizio Hyperscale offre un livello altamente scalabile per le prestazioni di archiviazione e calcolo, e sfrutta l'architettura di Azure per aumentare il numero di istanze per le risorse di archiviazione e di calcolo per un database SQL di Azure sostanzialmente oltre i limiti disponibili per i livelli di utilizzo generico e business critical. Questo articolo descrive come svolgere attività amministrative essenziali per i database Hyperscale, eseguire la migrazione di un database esistente a Hyperscale, effettuare il ripristino di un database Hyperscale in un'area diversa, eseguire la migrazione inversa da Hyperscale a un altro livello di servizio e monitorare lo stato delle operazioni in corso e recenti su un database Hyperscale.
Informazioni su come creare un nuovo database Hyperscale in Avvio rapido: Creare un database Hyperscale in database SQL di Azure.
Suggerimento
Prezzi semplificati per database SQL Hyperscale a dicembre 2023. Per informazioni dettagliate, consultare il blog sui prezzi di Hyperscale.
Eseguire la migrazione di un database esistente a Hyperscale
È possibile eseguire la migrazione di database SQL di Azure esistenti al livello di servizio Hyperscale usando il portale di Azure, l’interfaccia della riga di comando di Azure, Powershell o Transact-SQL.
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. È consigliabile eseguire la migrazione a Hyperscale durante un periodo di attività di scrittura limitata, in modo da ridurre il tempo di riproduzione delle modifiche accumulate.
Durante il cutover finale al livello di servizio Hyperscale può verificarsi un breve periodo di inattività della durata di alcuni minuti.
Prerequisiti
Per spostare in Hyperscale un database che fa parte di una relazione di replica geografica primaria o secondaria, è necessario prima terminare la replica dei dati tra la replica primaria e secondaria. I database in un gruppo di failover devono essere prima rimossi dal gruppo.
Dopo che un database è stato spostato in Hyperscale, è possibile creare una nuova replica geografica Hyperscale per tale database.
Informazioni su come eseguire la migrazione di un database al livello di servizio Hyperscale
Per eseguire la migrazione di un database esistente in database SQL di Azure al livello di servizio Hyperscale, occorre prima identificare l'obiettivo del servizio di destinazione. In caso di dubbi su quale obiettivo di servizio sia adatto per il database, esaminare i limiti delle risorse per i database singoli. In molti casi, è possibile scegliere un obiettivo di servizio con lo stesso numero di vCore e la stessa generazione hardware del database originale. Se necessario, è possibile modificare l'obiettivo di servizio con tempi di inattività minimi.
Selezionare la scheda per lo strumento preferito per eseguire la migrazione del database:
Il portale di Azure consente di eseguire la migrazione al livello di servizio Hyperscale modificando il piano tariffario per il database.
- Spostarsi al database di cui si vuole eseguire la migrazione nel portale di Azure.
- Nella barra di spostamento sinistra, selezionare Calcolo + Archiviazione.
- Selezionare l'elenco a discesa Livello di servizio per espandere le opzioni per i livelli di servizio.
- Selezionare Hyperscale (archiviazione scalabile su richiesta) dal menu a discesa.
- Esaminare la configurazione hardware elencata. Se necessario, selezionare Modifica configurazione per scegliere la configurazione hardware più appropriata per il carico di lavoro.
- Selezionare il dispositivo di scorrimento vCore se si intende modificare il numero di vCore disponibili per il database nel livello di servizio Hyperscale.
- Selezionare il dispositivo di scorrimento High-AvailabilitySecondaryReplicas se si desidera modificare il numero di repliche nel livello di servizio Hyperscale.
- Selezionare Applica.
È possibile monitorare le operazioni per un database Hyperscale mentre l'operazione è in corso.
Eseguire la migrazione inversa da Hyperscale
La migrazione inversa al livello di servizio per utilizzo generico permette ai clienti che di recente hanno eseguito la migrazione di un database esistente nel database SQL di Azure al livello di servizio Hyperscale di tornare indietro in caso di emergenza 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 uno spostamento di dimensioni dei dati tra architetture diverse.
Limitazioni per la migrazione inversa
La migrazione inversa è disponibile alle condizioni seguenti:
- La migrazione inversa è disponibile solo entro 45 giorni dalla migrazione originale a Hyperscale.
- I database creati originariamente nel livello di servizio Hyperscale non sono idonei alla migrazione inversa.
- È possibile eseguire la migrazione inversa solo al livello di servizio per utilizzo generico. La migrazione dal livello di servizio Hyperscale a quello di utilizzo generico può avere come destinazione i livelli di calcolo serverless o con provisioning. Se si vuole eseguire la migrazione del database a un altro livello di servizio, ad esempio Business Critical o un livello di servizio basato su DTU, eseguire prima la migrazione inversa al livello di servizio per utilizzo generico, e successivamente modificare il livello di servizio.
- La migrazione inversa ai database con meno di 2 vcore non è supportata. È possibile ridurre il database a meno di 2 vcore al termine della migrazione.
- La migrazione inversa diretta da o verso un pool elastico non è supportata. È possibile invertire la migrazione solo di un database singolo Hyperscale a un database singolo per utilizzo generico.
- Se il database Hyperscale fa parte di un pool elastico Hyperscale (anteprima), prima di eseguire la migrazione inversa è necessario rimuoverlo dal pool elastico Hyperscale.
- Se necessario, al termine della migrazione inversa, è possibile aggiungere facoltativamente il database singolo per utilizzo generico a un pool elastico per utilizzo generico.
- Per i database che non sono idonei alla migrazione inversa, l'unico modo per eseguire la migrazione da Hyperscale a un livello di servizio non Hyperscale consiste nell'eseguire l'esportazione o l'importazione usando un file con estensione BACPAC o altre tecnologie di spostamento dati (copia bulk, Azure Data Factory, Azure Databricks, SSIS e così via). L'esportazione e l'importazione di file BACPAC dal portale di Azure, da PowerShell usando New-AzSqlDatabaseExport o New-AzSqlDatabaseImport, dall'interfaccia della riga di comando di Azure usando az sql db export e az sql db import e dall'API REST non sono supportate. L'importazione e l'esportazione di file BACPAC per database Hyperscale di dimensioni inferiori (fino a 150 GB) sono supportate tramite SSMS e SqlPackage versione 18.4 e successive. Per i database di dimensioni superiori, l'esportazione o l'importazione di file BACPAC potrebbe richiedere molto tempo e avere esito negativo per diversi motivi.
Durata e tempo di inattività
A differenza delle normali operazioni di modifica degli obiettivi a livello di servizio in Hyperscale, la migrazione a Hyperscale e la migrazione inversa al livello di servizio per utilizzo generico sono operazioni di dimensioni dei dati.
La durata di un’operazione di migrazione inversa dipende principalmente dalle dimensioni del database e dalle attività di scrittura eseguite simultaneamente durante la migrazione. Il numero di vCore assegnati al database di destinazione per utilizzo generico incide sulla durata della migrazione inversa. È consigliabile effettuare il provisioning del database per utilizzo generico di destinazione con un numero di vCore maggiore o uguale al numero di vCore assegnati al database Hyperscale di origine per supportare carichi di lavoro analoghi.
Durante la migrazione inversa, il database Hyperscale di origine può riscontrare una riduzione delle prestazioni in caso di carico di lavoro considerevole. In particolare, la velocità del log delle transazioni potrebbe essere ridotta (limitata) per garantire l'avanzamento della migrazione inversa.
Durante il cutover finale al nuovo database per utilizzo generico di destinazione si verifica un breve periodo di inattività della durata di alcuni minuti.
Prerequisiti
Prima di avviare una migrazione inversa da Hyperscale al livello di servizio per utilizzo generico, è necessario assicurarsi che il database soddisfi le limitazioni per la migrazione inversa e che:
- La replica geografica non sia abilitata nel database.
- Il database non abbia repliche denominate.
- Il database (dimensioni allocate) sia sufficientemente piccolo da adattarsi al livello di servizio di destinazione.
- Se si specifica la dimensione massima del database per utilizzo generico di destinazione, assicurarsi che le dimensioni allocate del database siano sufficientemente piccole per adattarsi a tale dimensione massima.
I controlli dei prerequisiti vengono eseguiti prima dell'avvio di un'operazione di migrazione inversa. Se i prerequisiti non sono soddisfatti, l'operazione di migrazione inversa ha un immediato esito negativo.
Criteri di backup
Vengono fatturati i prezzi regolari per tutti i backup del database esistenti entro il periodo di conservazione configurato. Vengono addebitati gli snapshot dell'archivio di backup Hyperscale e i BLOB di archiviazione dei dati di dimensioni che devono essere conservati per poter ripristinare il backup.
È possibile eseguire la migrazione di un database a Hyperscale e la migrazione inversa al livello di servizio per utilizzo generico diverse volte. Per il ripristino sono disponibili solo i backup del livello di servizio corrente e direttamente precedente del database. Se è stata eseguita la migrazione dal livello di servizio per utilizzo generico a Hyperscale e nuovamente a utilizzo generico, gli unici backup disponibili sono quelli del database per utilizzo generico corrente e del database Hyperscale immediatamente precedente. Questi backup vengono conservati e fatturati in base alla fatturazione per database SQL di Azure. Tutti i livelli precedentemente provati non avranno backup disponibili e non verranno fatturati.
Ad esempio, è possibile eseguire la migrazione tra i livelli di servizio Hyperscale e non Hyperscale:
- Utilizzo generico
- Eseguire la migrazione a Hyperscale
- Eseguire la migrazione inversa a Utilizzo generico
- Modifica del livello di servizio a Business critical
- Eseguire la migrazione a Hyperscale
- Eseguire la migrazione inversa a Utilizzo generico
In questo caso, gli unici backup disponibili sono relativi ai passaggi 5 e 6 della timeline, se compresi entro il periodo di conservazione configurato. Eventuali backup dei passaggi precedenti non saranno disponibili. Valutare attentamente la disponibilità dei backup quando si eseguono più migrazioni ripetute dello stesso database tra Hyperscale e il livello di servizio per utilizzo generico. I backup di database precedenti al database immediatamente precedente diventano non disponibili non appena viene avviata una migrazione inversa e rimangono non disponibili anche se la migrazione viene annullata.
Come eseguire la migrazione inversa di un database Hyperscale al livello di servizio per utilizzo generico
Per eseguire la migrazione inversa di un database Hyperscale esistente in database SQL di Azure al livello di servizio per utilizzo generico, occorre prima identificare l'obiettivo del servizio di destinazione nel livello di servizio per utilizzo generico e stabilire se si intende eseguire la migrazione ai livelli di calcolo con provisioning o serverless. In caso di dubbi su quale obiettivo di servizio sia adatto per il database, esaminare i limiti delle risorse per i database singoli.
Se si intende eseguire una modifica aggiuntiva del livello di servizio dopo la migrazione inversa a utilizzo generico, identificare anche l'obiettivo del servizio di destinazione finale e assicurarsi che le dimensioni allocate del database siano sufficientemente piccole da adattarsi a tale obiettivo del servizio.
Selezionare la scheda corrispondente al metodo preferito per eseguire la migrazione inversa del database:
Il portale di Azure consente di eseguire la migrazione inversa al livello di servizio per utilizzo generico modificando il piano tariffario per il database.
- Spostarsi al database di cui si vuole eseguire la migrazione nel portale di Azure.
- Nella barra di spostamento sinistra, selezionare Calcolo + Archiviazione.
- Selezionare l'elenco a discesa Livello di servizio per espandere le opzioni per i livelli di servizio.
- Selezionare Utilizzo generico (opzioni di calcolo e archiviazione scalabili) dal menu a discesa.
- Esaminare la configurazione hardware elencata. Se necessario, selezionare Modifica configurazione per scegliere la configurazione hardware più appropriata per il carico di lavoro.
- Selezionare il dispositivo di scorrimento vCore se si intende modificare il numero di vCore disponibili per il database nel livello di servizio per Utilizzo generico.
- Selezionare Applica.
Monitorare le operazioni per un database Hyperscale
È possibile monitorare lo stato delle operazioni in corso o completate di recente per un database SQL di Azure usando il portale di Azure, l'interfaccia della riga di comando di Azure, PowerShell o Transact-SQL.
Selezionare la scheda corrispondente al metodo preferito per monitorare le operazioni.
Quando è in corso un'operazione, che si tratti di migrazione, migrazione inversa o ripristino, il portale di Azure mostra una notifica per un database in database SQL di Azure.
- Spostarsi nel database nel portale di Azure.
- Nella barra di spostamento a sinistra selezionare Panoramica.
- Esaminare la sezione Notifiche nella parte inferiore del riquadro destro. Se le operazioni sono in corso, viene visualizzata una finestra di notifica.
- Selezionare la casella di notifica per visualizzare i dettagli.
- Viene visualizzato il riquadro Operazioni in corso. Esaminare i dettagli delle operazioni in corso.
Visualizzare i database nel livello di servizio Hyperscale
Dopo la migrazione di un database a Hyperscale o la riconfigurazione di un database all'interno del livello di servizio Hyperscale, è possibile visualizzare e/o documentare la configurazione del database Hyperscale.
Il portale di Azure mostra un elenco di tutti i database in un server logico. La colonna Piano tariffario include il livello di servizio per ciascun database.
- Nel portale di Azure passare al server logico.
- Nella barra di spostamento a sinistra selezionare Panoramica.
- Scorrere fino all'elenco delle risorse nella parte inferiore del riquadro. Nella finestra vengono visualizzati i pool elastici e i database SQL nel server logico.
- Esaminare la colonna Piano tariffario per identificare i database nel livello di servizio Hyperscale.
Contenuto correlato
Maggiori informazioni sui database Hyperscale sono disponibili negli articoli seguenti:
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per