Eseguire la migrazione inversa di un database da Hyperscale

È possibile eseguire la migrazione di un database Hyperscale esistente nel database SQL di Azure al livello di servizio Per utilizzo generico usando il portale di Azure, l'interfaccia della riga di comando di Azure, PowerShell o Transact-SQL.

La migrazione inversa al livello di servizio Per utilizzo generico consente ai clienti che hanno recentemente convertito un database esistente nel database SQL di Azure in Hyperscale di tornare in caso di emergenza, in caso di mancata risposta alle esigenze di Hyperscale. Mentre la migrazione inversa viene avviata da una modifica del 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 nelle condizioni seguenti:

• La migrazione inversa è disponibile solo entro 45 giorni dalla migrazione originale a Hyperscale.
• I database creati in origine nel livello di servizio Hyperscale non sono idonei per la migrazione inversa.
• È possibile eseguire una migrazione inversa solo al livello di servizio utilizzo generico. La tua migrazione da Hyperscale a Utilizzo Generico può indirizzarsi verso i livelli di calcolo Serverless o Provisioned. 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 , prima eseguire la migrazione inversa al livello di servizio per utilizzo generico, quindi 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 , è necessario prima rimuoverlo dal pool elastico Hyperscale prima della migrazione inversa.
  • Al termine della migrazione inversa, è possibile aggiungere facoltativamente il database singolo per utilizzo generico a un pool elastico per utilizzo generico, se necessario.
• Per i database che non sono idonei per la migrazione inversa, l'unico modo per eseguire la migrazione da Hyperscale a un livello di servizio non Hyperscale consiste nell'esportare/importare usando un file bacpac o altre tecnologie di spostamento dati (copia bulk, Azure Data Factory, Azure Databricks, SSIS e così via) Esportazione/importazione 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 è supportata. L'importazione/esportazione bacpac per database Hyperscale di dimensioni inferiori (fino a 150 GB) è supportata con SSMS e SqlPackage versione 18.4 e successive. Per i database di dimensioni maggiori, l'esportazione/importazione bacpac potrebbe richiedere molto tempo e può 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 a 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 simultanee eseguite durante la migrazione. Il numero di vCore assegnati al database per utilizzo generico di destinazione influisce anche 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 sostenere carichi di lavoro simili.

Durante la migrazione inversa, il database Hyperscale di origine può riscontrare una riduzione delle prestazioni in caso di carico considerevole. In particolare, la velocità del log delle transazioni potrebbe essere ridotta (limitata) per garantire che la migrazione inversa stia effettuando progressi.

Proverete un breve periodo di inattività, generalmente di alcuni minuti, durante il passaggio finale al nuovo database General Purpose di destinazione.

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:

• Il database non ha la replica geografica abilitata.
• Il database non ha repliche denominate.
• Il database (dimensioni allocate) è sufficientemente piccolo da adattarsi al livello di servizio di destinazione.
• Se si specifica la dimensione massima per il database di utilizzo generico di destinazione, assicurarsi che la dimensione allocata del database sia abbastanza piccola da rientrare in 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 esito negativo immediatamente.

Criteri di backup

Ti viene fatturata utilizzando il normale listino prezzi per tutti i backup del database esistenti all'interno del periodo di conservazione configurato . Ti vengono addebitati gli snapshot per l'archiviazione di backup Hyperscale e i blob di dati di dimensioni che devono essere conservati per poter ripristinare il backup.

È possibile convertire un database in Hyperscale ed eseguire la migrazione inversa più volte a Utilizzo generico. Per il ripristino sono disponibili solo i backup dal livello corrente e precedente del database. Se ti sei spostato dal livello di servizio Per utilizzo generico a Hyperscale e sei tornato a Utilizzo generico, gli unici backup disponibili sono quelli del database per utilizzo generico corrente e del database Hyperscale immediatamente precedente. Questi backup conservati vengono fatturati in base alla fatturazione del database SQL di Azure. Tutti i livelli precedenti provati non avranno backup disponibili e non verranno fatturati.

Ad esempio, è possibile eseguire la migrazione tra i livelli di servizio Hyperscale e non Hyperscale:

1. Utilizzo generico
2. Convertire in Hyperscale
3. Eseguire la migrazione inversa a Utilizzo generico
4. Modifica del livello di servizio in Business Critical
5. Convertire in Hyperscale
6. Eseguire la migrazione inversa a Utilizzo generico

In questo caso, gli unici backup disponibili sono i passaggi 5 e 6 della sequenza temporale, se sono ancora entro il periodo di conservazione configurato . Eventuali backup dei passaggi precedenti non saranno disponibili. Valutare attentamente la disponibilità dei backup quando si tentano migrazioni ripetute dello stesso database tra i livelli di servizio Hyperscale e 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 invertire la migrazione di un database Hyperscale al livello di servizio Utilizzo generico

Per eseguire una migrazione inversa di un database Hyperscale esistente nel database SQL di Azure al livello di servizio Utilizzo Generico, identificare innanzitutto l'obiettivo del servizio di destinazione nel livello di servizio Utilizzo Generico e se si desidera eseguire la migrazione ai livelli di calcolo con provisioning o calcolo serverless. Esamina i limiti delle risorse per i database singoli se non sei sicuro di quale livello di servizio sia adatto per il tuo database.

Se si vuole eseguire una modifica aggiuntiva del livello di servizio dopo la migrazione inversa a Utilizzo generico, identificare l'obiettivo finale del servizio di destinazione. Assicurarsi che le dimensioni allocate del database siano abbastanza piccole da rientrare in quel parametro di servizio.

Selezionare la scheda per il metodo preferito per invertire la migrazione del database:

Portale

Il portale di Azure consente di invertire la migrazione al livello di servizio per utilizzo generico modificando il piano tariffario per il database.

1. Passare al database nel portale di Azure.
2. Nella barra di spostamento a sinistra selezionare Calcolo e archiviazione.
3. Selezionare l'elenco a discesa del livello di servizio per espandere le opzioni dei livelli di servizio.
4. Selezionare utilizzo generico (opzioni di calcolo e archiviazione scalabili) dal menu a discesa.
5. Esaminare la configurazione hardware elencata. Se necessario, selezionare Modifica configurazione per selezionare la configurazione hardware appropriata per il carico di lavoro.
6. Selezionare lo slider vCores se si desidera modificare il numero di vCores disponibili per il database nel livello di servizio Utilizzo generico.
7. Selezionare Applica.
8. Monitorare la conversione nel portale di Azure.
   1. Passare al database nel portale di Azure.
   2. Nella barra di spostamento a sinistra selezionare Panoramica.
   3. Esamina la sezione notifiche nella parte inferiore del riquadro destro. Se le operazioni sono in corso, viene visualizzata una finestra di notifica.
   4. Per visualizzare i dettagli, selezionare la casella di notifica.
   5. Si apre il riquadro delle operazioni in corso . Esaminare i dettagli delle operazioni in corso.

Questo esempio di codice chiama az sql db update per effettuare una migrazione inversa di un database Hyperscale esistente al livello di servizio Scopo Generale. È necessario specificare sia l'edizione che l'obiettivo di servizio. È possibile selezionare Provisioned o Serverless per il modello di calcolo di destinazione.

Sostituire resourceGroupName, serverName, databaseNamee serviceObjective con i valori appropriati prima di eseguire l'esempio di codice seguente:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel

Facoltativamente, è possibile includere l'argomento maxsize. Se il valore maxsize supera le dimensioni massime valide per l'obiettivo del servizio di destinazione, viene restituito un errore. Se l'argomento maxsize non viene specificato, per impostazione predefinita l'operazione corrisponde alla dimensione massima disponibile per l'obiettivo di servizio specificato. Nell'esempio seguente viene specificato maxsize:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"
serviceObjective="GP_Gen5_2"
computeModel="Provisioned"
maxsize="200GB"

az sql db update -g $resourceGroupName -s $serverName -n $databaseName \
    --edition GeneralPurpose --service-objective $serviceObjective \
    --compute-model $computeModel --max-size $maxsize

Monitora l'operazione in corso con az sql db op list. Per restituire operazioni recenti o in corso per un database nel database SQL di Azure:

resourceGroupName="myResourceGroup"
serverName="server01"
databaseName="mySampleDatabase"

az sql db op list -g $resourceGroupName -s $serverName -n $databaseName

PowerShell

Questo esempio di codice usa il cmdlet Set-AzSqlDatabase per invertire la migrazione di un database esistente da Hyperscale al livello di servizio Per utilizzo generico. È necessario specificare sia l'edizione che l'obiettivo di servizio. È possibile selezionare Provisioned o Serverless per il livello di calcolo di destinazione.

Sostituire $resourceGroupName, $serverName, $databaseName, $serviceObjectivee $computeModel con i valori appropriati prima di eseguire questo esempio di codice:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective

Facoltativamente, è possibile includere l'argomento maxsize. Se il valore maxsize supera le dimensioni massime valide per l'obiettivo del servizio di destinazione, viene restituito un errore. Se l'argomento maxsize non viene specificato, per impostazione predefinita l'operazione corrisponde alla dimensione massima disponibile per l'obiettivo di servizio specificato. Nell'esempio seguente viene specificato maxsize:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"
$serviceObjective = "GP_Gen5_2"
$computeModel = "Provisioned"
$maxSizeBytes = "268435456000"

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName `
    -DatabaseName $databaseName -Edition "GeneralPurpose" -computemodel $computeModel `
    -RequestedServiceObjectiveName $serviceObjective -MaxSizeBytes $maxSizeBytes

Monitorare l'operazione in corso con il cmdlet Get-AzSqlDatabaseActivity, che restituisce operazioni recenti o in corso per un database nel database SQL di Azure. Impostare i parametri $resourceGroupName, $serverNamee $databaseName sui valori appropriati per il database prima di eseguire il codice di esempio:

$resourceGroupName = "myResourceGroup"
$serverName = "server01"
$databaseName = "mySampleDatabase"

Get-AzSqlDatabaseActivity -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -DatabaseName $databaseName

Per migrare all'indietro un database Hyperscale al livello di servizio General Purpose con Transact-SQL, connettiti prima al database master sul server SQL logico utilizzando SQL Server Management Studio (SSMS)o Azure Data Studio.

È necessario specificare sia l'edizione che l'obiettivo di servizio nell'istruzione ALTER DATABASE.

Questa istruzione di esempio esegue la migrazione di un database denominato mySampleDatabase al livello di servizio Utilizzo generico con l'obiettivo di servizio GP_Gen5_4. Sostituire il nome del database e l'obiettivo di servizio con i valori appropriati prima di eseguire l'istruzione.

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2');
GO

Facoltativamente, è possibile includere l'argomento maxsize. Se il valore maxsize supera le dimensioni massime valide per l'obiettivo del servizio di destinazione, viene restituito un errore. Se l'argomento maxsize non viene specificato, per impostazione predefinita l'operazione corrisponde alla dimensione massima disponibile per l'obiettivo di servizio specificato. Nell'esempio seguente viene specificato maxsize:

ALTER DATABASE [mySampleDatabase]
    MODIFY (EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_Gen5_2', MAXSIZE = 200 GB);
GO

Per monitorare le operazioni per un database Hyperscale, connettersi al database master del server logico usando SQL Server Management Studio (SSMS), l'estensione mssql per Visual Studio Codeo il client di propria scelta per eseguire comandi Transact-SQL.

Eseguire una query sulla vista a gestione dinamica sys.dm_operation_status per esaminare le informazioni sulle operazioni recenti eseguite sui database nel server logico.

La vista di gestione dinamica sys.dm_operation_status restituisce le operazioni ordinate per le più recenti. Sostituire il nome del database con il valore appropriato prima di eseguire l'esempio di codice.

SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO

Contenuto correlato

• Come gestire un database Hyperscale
• Convertire un database esistente in Hyperscale