Effectuer une migration inversée d’une base de données à partir d’Hyperscale

S’applique à :Azure SQL Database

Vous pouvez migrer une base de données Hyperscale existante dans Azure SQL Database vers le niveau de service Usage général à l’aide du portail Azure, d’Azure CLI, de PowerShell ou de Transact-SQL.

La migration inversée vers le niveau de service Usage général permet aux clients qui ont récemment converti une base de données existante dans Azure SQL Database vers Hyperscale de revenir en urgence, si Hyperscale ne répond pas à leurs besoins. Bien que la migration inversée soit lancée par un changement de niveau de service, il s’agit essentiellement d’un déplacement de taille de données entre différentes architectures.

Limitations de la migration inversée

La migration inversée est disponible dans les conditions suivantes :

La migration inversée est disponible uniquement dans les 45 jours suivant la migration d’origine vers Hyperscale.
Les bases de données créées à l’origine dans le niveau de service Hyperscale ne sont pas éligibles à la migration inversée.
Vous avez la possibilité d'annuler la migration vers le niveau de service Usage général uniquement. Votre migration d’Hyperscale vers le niveau d’usage général peut cibler les niveaux de calcul serverless ou provisionnés. Si vous souhaitez migrer la base de données vers un autre niveau de service, tel que critique pour l'entreprise ou niveau de service basé sur les DTU, effectuez d’abord une migration inversée vers le niveau de service usage général, puis modifiez le niveau de service.
La migration inversée vers les bases de données avec moins de 2 vCores n’est pas prise en charge. Vous pouvez mettre à l'échelle et réduire la taille de la base de données à moins de 2 vCores une fois la migration terminée.
La migration inversée directe depuis ou vers un pool élastique n’est pas prise en charge. Vous pouvez inverser la migration d’une seule base de données Hyperscale vers une base de données à usage général unique.
- Si la base de données Hyperscale fait partie d’un pool élastique Hyperscale, vous devez d’abord la supprimer du pool élastique Hyperscale avant d'inverser la migration.
- Une fois la migration inversée terminée, vous pouvez éventuellement ajouter la base de données à usage général unique à un pool élastique à usage général si nécessaire.
Pour les bases de données pour lesquelles la migration inversée n’est pas possible, la seule façon de migrer une base de données d’Hyperscale vers un niveau de service non-Hyperscale consiste à exporter/importer à l’aide d’un fichier bacpac ou d’autres technologies de déplacement de données (copie en bloc, Azure Data Factory, Azure Databricks, SSIS, etc.) L’exportation et l’importation bacpac à partir du portail Azure, à partir de PowerShell à l’aide des cmdlets New-AzSqlDatabaseExport ou New-AzSqlDatabaseImport, à partir d’Azure CLI à l’aide des commandes az sql db export et az sql db import, et d’une API REST, ne sont pas prises en charge. L’exportation / l’importation bacpac pour des bases de données Hyperscale de plus petite taille (jusqu’à 150 Go) est prise en charge via SSMS et SqlPackage versions 18.4 et ultérieures. Dans le cas de bases de données plus volumineuses, l’exportation / l’importation bacpac peut prendre beaucoup de temps et échouer pour différentes raisons.

Durée et temps d’arrêt

Contrairement aux opérations régulières de changement d’objectif de niveau de service dans Hyperscale, la migration vers Hyperscale et la migration inversée vers l’usage général sont des opérations liées à la taille des données.

La durée de l’opération de migration inversée dépend principalement de la taille de la base de données et des activités d’écriture simultanées qui se produisent pendant la migration. Le nombre de vCores que vous affectez à la base de données à usage général cible a également un impact sur la durée de la migration inversée. Nous vous recommandons d’approvisionner la base de données à usage général cible avec un nombre de vCores supérieurs ou égal au nombre de vCores affectés à la base de données Hyperscale source pour des charges de travail similaires.

Lors de la migration inversée, la base de données Hyperscale source peut voir ses performances dégradées en cas de charge importante. Plus précisément, il peut arriver que le taux de journalisation des transactions soit réduit (limité) pour garantir la progression de la migration inversée.

Vous rencontrerez une courte période de temps d’arrêt, généralement quelques minutes, pendant le basculement final vers la nouvelle base de données à usage général.

Conditions préalables

Avant de lancer une migration inversée d’Hyperscale vers le niveau de service à usage général, vous devez vous assurer que votre base de données respecte les limitations de la migration inversée et :

La géoréplication de votre base de données n’est pas activée.
Votre base de données n’a pas de réplicas nommés.
Votre base de données (taille allouée) est suffisamment petite pour s’adapter au niveau de service cible.
Si vous spécifiez la taille maximale de base de données pour la base de données à usage général cible, assurez-vous que la taille allouée de la base de données est suffisamment petite pour s’adapter à cette taille maximale.

Ces vérifications des prérequis doivent avoir lieu avant le démarrage de l’opération de migration inversée. Si les conditions préalables ne sont pas remplies, l’opération de migration inversée échoue immédiatement.

Stratégies de sauvegarde

Vous serez facturé selon la tarification normale pour toutes les sauvegardes de base de données existantes au cours de la période de rétention configurée. Vous serez facturé pour les instantanés de stockage de sauvegarde Hyperscale et pour les objets blob de stockage de données qui doivent être conservés pour pouvoir restaurer la sauvegarde.

Vous pouvez convertir une base de données en Hyperscale et effectuer une migration inversée vers usage général plusieurs fois. Seules les sauvegardes à partir du niveau actuel et du niveau précédent de votre base de données seront disponibles pour la restauration. Si vous êtes passé du niveau de service usage général à Hyperscale et que vous êtes revenu à l’usage général, les seules sauvegardes disponibles sont celles de la base de données à usage général actuelle et celle de la base de données Hyperscale précédente. Ces sauvegardes conservées sont facturées conformément à la facturation Azure SQL Database. Les niveaux précédents essayés n’ont pas de sauvegardes et ne seront pas facturés.

Par exemple, vous pouvez migrer entre les niveaux de service Hyperscale et non-Hyperscale :

Usage général
Convertir en Hyperscale
Migration inversée vers usage général
Changement de niveau de service en critique pour l'entreprise
Convertir en Hyperscale
Migration inversée vers usage général

Dans ce cas, les seules sauvegardes disponibles proviennent des étapes 5 et 6 de la chronologie, si elles sont toujours dans la période de rétention configurée. Toutes les sauvegardes des étapes précédentes ne sont pas disponibles. Vérifiez scrupuleusement la disponibilité des sauvegardes lorsque vous cherchez à effectuer des migrations répétées de la même base de données entre les niveaux de service Hyperscale et Usage général. Les sauvegardes de bases de données antérieures à la base de données qui précède immédiatement deviennent indisponibles dès lors qu’une migration inversée a démarré et restent indisponibles même si la migration est annulée.

Comment inverser la migration d’une base de données Hyperscale vers le niveau de service usage général

Pour inverser la migration d’une base de données Hyperscale existante dans Azure SQL Database vers le niveau de service Hyperscale, commencez par identifier votre objectif de service cible dans le niveau de service à usage général et si vous souhaitez migrer vers les niveaux de calcul approvisionnés ou serverless. Passez en revue limites de ressources pour les bases de données uniques si vous ne savez pas quel objectif de service convient à votre base de données.

Si vous souhaitez effectuer une modification de niveau de service supplémentaire après la migration inversée vers usage général, identifiez votre objectif de service cible final. Assurez-vous que la taille allouée de votre base de données est suffisamment petite pour s’adapter à cet objectif de service.

Sélectionnez l’onglet de votre méthode préférée pour inverser la migration de votre base de données :

Le portail Azure vous permet d’inverser la migration vers le niveau de service Usage général en modifiant le niveau tarifaire de votre base de données.

Accédez à la base de données dans le portail Azure.
Dans la barre de navigation de gauche, sélectionnez Informatique + stockage.
Sélectionnez la liste déroulante niveau de service pour développer les options des niveaux de service.
Sélectionnez Usage général (options de calcul et de stockage évolutives) dans le menu à liste déroulante.
Passez en revue la configuration matérielle répertoriée. Si vous le souhaitez, sélectionnez Modifier la configuration pour sélectionner la configuration matérielle appropriée pour votre charge de travail.
Sélectionnez le curseur vCores si vous souhaitez modifier le nombre de vCores disponibles dans votre base de données sous le niveau de service usage général.
Sélectionnez Appliquer.
Surveillez la conversion dans le portail Azure.
1. Accédez à la base de données dans le portail Azure.
2. Dans la barre de navigation de gauche, sélectionnez Vue d’ensemble.
3. Passez en revue la section Notifications en bas du volet droit. Si des opérations sont en cours, une boîte de notification s’affiche.
4. Pour afficher les détails, sélectionnez la zone de notification.
5. Le volet Opérations en cours s’ouvre. Passez en revue les détails des opérations en cours.

Cet exemple de code appelle az sql db update pour inverser la migration d’une base de données Hyperscale existante vers le niveau de service usage général. Vous devez spécifier l’édition et l’objectif de service. Vous avez la possibilité de sélectionner soit Provisioned soit Serverless comme modèle de calcul cible.

Remplacez resourceGroupName, serverName, databaseNameet serviceObjective par les valeurs appropriées avant d’exécuter l’exemple de code suivant :

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

Vous pouvez aussi inclure l’argument maxsize. Si la valeur maxsize dépasse la taille maximale valide pour l’objectif de service cible, une erreur est retournée. Si l’argument maxsize n’est pas spécifié, l’opération est définie par défaut sur la taille maximale disponible pour l’objectif de service donné. L'exemple suivant spécifie 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

Surveillez l’opération en cours avec az sql db op list. Pour retourner des opérations récentes ou en cours pour une base de données dans Azure SQL Database :

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

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

Cet exemple de code utilise l’applet de commande Set-AzSqlDatabase pour inverser la migration d’une base de données existante d’Hyperscale vers le niveau de service Usage général. Vous devez spécifier l’édition et l’objectif de service. Vous avez la possibilité de sélectionner soit Provisioned soit Serverless comme niveau hiérarchique de calcul cible.

Remplacez $resourceGroupName, $serverName, $databaseName, $serviceObjective et $computeModel par les valeurs appropriées avant d’exécuter cet exemple de code :

$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

$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

Surveillez l’opération en cours avec l’applet de commande Get-AzSqlDatabaseActivity , qui retourne des opérations récentes ou en cours pour une base de données dans Azure SQL Database. Définissez les paramètres $resourceGroupName, $serverNameet $databaseName sur les valeurs appropriées pour votre base de données avant d’exécuter l’exemple de code :

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

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

Pour inverser la migration d’une base de données Hyperscale vers le niveau de service Usage général avec Transact-SQL, commencez par vous connecter à la master base de données sur votre serveur SQL logique à l’aide de SQL Server Management Studio (SSMS).

Vous devez spécifier l’édition et l’objectif de service dans l’instruction ALTER DATABASE.

Cet exemple d’instruction migre une base de données appelée mySampleDatabase vers le niveau de service usage général avec l’objectif de service GP_Gen5_4. Remplacez le nom de la base de données et l’objectif de service par les valeurs appropriées avant d’exécuter l’instruction.

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

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

Pour surveiller les opérations d’une base de données Hyperscale, connectez-vous à la base de données de votre master à l’aide de SQL Server Management Studio (SSMS),de l’extension mssql pour Visual Studio Code ou du client de votre choix pour exécuter des commandes Transact-SQL.

Interrogez la vue de gestion dynamique sys.dm_operation_status pour examiner les informations sur les opérations récentes effectuées sur des bases de données de votre serveur logique.

La sys.dm_operation_status vue de gestion dynamique retourne les opérations triées par ordre des plus récentes. Remplacez le nom de la base de données par la valeur appropriée avant d’exécuter l’exemple de code.

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

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-08-01