Migrer des bases de données de SQL Server à l’aide du service LRS - Azure SQL Managed Instance

S’applique à :Azure SQL Managed Instance

Cet article explique comment migrer des bases de données vers Azure SQL Managed Instance en utilisant Log Replay Service (LRS). LRS est un service cloud gratuit disponible pour Azure SQL Managed Instance, basé sur la technologie d’envoi de journaux SQL Server.

Les sources suivantes sont prises en charge :

• SQL Server sur les machines virtuelles
• Amazon EC2 (Elastic Compute Cloud)
• Amazon RDS (Relational Database Service) pour SQL Server
• Google Compute Engine
• Cloud SQL pour SQL Server - GCP (Google Cloud Platform)

Prérequis

Avant de commencer, tenez compte des exigences suivantes pour votre instance SQL Server et Azure.

SQL Server

Vérifiez que vous respectez les conditions requises suivantes pour SQL Server :

• Versions de SQL Server 2008 à 2022.
• Votre base de données SQL Server utilise le modèle de récupération complète (obligatoire).
• Une sauvegarde complète des bases de données (un ou plusieurs fichiers).
• Une sauvegarde différentielle (un ou plusieurs fichiers).
• Une sauvegarde de journal (non fractionnée pour un fichier journal des transactions).
• Pour les versions SQL Server 2008 à 2016, effectuez une sauvegarde localement et chargez-la manuellement sur votre compte Stockage Blob Azure.
• Pour SQL Server 2016 et versions ultérieures, vous pouvez effectuer votre sauvegarde directement sur votre compte Stockage Blob Azure.

Bien que l’activation de la fonctionnalité CHECKSUM pour les sauvegardes ne soit pas obligatoire, nous vous recommandons vivement de l’activer pour des opérations de restauration plus rapides.

Azure

Vérifiez que vous respectez les conditions requises suivantes pour Azure :

• Version 4.0.0 ou ultérieure du module PowerShell Az.SQL (installée ou accessible par le biais d’Azure Cloud Shell).
• Azure CLI version 2.42.0 ou ultérieure (installée).
• Un conteneur Stockage Blob Azure provisionné.
• Un jeton de sécurité de signature d’accès partagé (SAS) avec des autorisations Lecture et Liste générées pour le conteneur Stockage Blob ou une identité managée pouvant accéder au conteneur.
• Placez des fichiers de sauvegarde pour une base de données individuelle dans un dossier distinct dans un compte de stockage en utilisant une structure de fichier plat (obligatoire). Les dossiers imbriqués dans des dossiers de base de données ne sont pas pris en charge.

Autorisations Azure RBAC

L’exécution du service LRS via les clients fournis requiert l’un des rôles Azure RBAC suivants :

• Rôle Contributeur SQL Managed Instance
• Un rôle avec l’autorisation suivante : Microsoft.Sql/managedInstances/databases/*

Bonnes pratiques

Respectez les bonnes pratiques suivantes quand vous utilisez LRS :

• Exécutez l’Assistant Migration de données pour confirmer que vos bases de données sont prêtes à être migrées vers SQL Managed Instance.
• Fractionnez les sauvegardes complètes et différentielles en plusieurs fichiers, au lieu d’utiliser un seul fichier.
• Activer la compression de sauvegarde pour aider les vitesses de transfert réseau.
• Utilisez Cloud Shell pour exécuter les scripts PowerShell et CLI, car il dispose toujours des dernières cmdlets mis en production.
• Configurez une fenêtre de maintenance pour permettre la planification de mises à jour système à un jour et une heure spécifiques. Cette configuration permet d’obtenir un temps plus prévisible pour les migrations de base de données, car les mises à niveau du système peuvent interrompre les migrations en cours.
• Planifiez l’accomplissement d’un travail de migration LRS unique dans un délai maximal de 30 jours. Au terme de ce délai d’exécution, le travail LRS est automatiquement annulé.
• Activez CHECKSUM quand vous effectuez vos sauvegardes pour que la restauration de base de données soit plus rapide. SQL Managed Instance effectue une vérification d’intégrité sur les sauvegardes sans CHECKSUM, ce qui augmente le temps de restauration.

Les mises à jour système pour SQL Managed Instance prennent le pas sur les migrations de bases de données en cours. Lors d’une mise à jour système sur une instance, toutes les migrations LRS en attente sont suspendues et ne reprennent qu’après la mise en œuvre de la mise à jour. Ce comportement du système pourrait allonger la durée de migration, en particulier pour les bases de données volumineuses.

Afin d’obtenir une heure prévisible pour les migrations de base de données, envisagez de configurer une fenêtre de maintenance afin de planifier les mises à jour système sur un jour et une heure spécifiques, et d’exécuter et d’achever les travaux de migration en dehors de la période de la fenêtre de maintenance désignée.

Important

• Vous ne pouvez pas utiliser des bases de données en cours de restauration via LRS jusqu’à ce que le processus de migration se termine.
• L’accès en lecture seule aux bases de données pendant la migration n’est pas pris en charge par le service LRS.
• Une fois la migration terminée, le processus de migration est finalisé et ne peut pas être repris avec des sauvegardes différentielles supplémentaires.

Migrer plusieurs bases de données

Lors de la migration de plusieurs bases de données à l’aide du même conteneur Stockage Blob Azure, vous devez placer les fichiers de sauvegarde de différentes bases dans des dossiers distincts dans le conteneur. Tous les fichiers de sauvegarde d’une même base de données doivent être placés dans une structure de fichiers plate à l’intérieur d’un dossier de base de données, et les dossiers ne peuvent pas être imbriqués. Les dossiers imbriqués dans des dossiers de base de données ne sont pas pris en charge.

Voici un exemple de structure de dossiers au sein d’un conteneur Stockage Blob Azure, une structure requise pour migrer plusieurs bases de données à l’aide de LRS.

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure. 
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Créez un compte de stockage.

Vous utilisez un compte Stockage Blob Azure comme stockage intermédiaire pour les fichiers de sauvegarde entre votre instance de SQL Server et votre déploiement SQL Managed Instance. Pour créer un compte de stockage et un conteneur Blob dans le compte de stockage :

1. Créer un compte de stockage.
2. Créez un conteneur blob dans le compte de stockage.

Configurer le stockage Azure derrière un pare-feu

L’utilisation du stockage Blob Azure protégé derrière un pare-feu est prise en charge, mais nécessite une configuration supplémentaire. Pour permettre l’accès en lecture/écriture au stockage Azure quand le Pare-feu Azure est activé, vous devez ajouter le sous-réseau de l’instance managée SQL aux règles de pare-feu du réseau virtuel pour le compte de stockage, en utilisant la délégation de sous-réseau MI et le point de terminaison du service de stockage. Le compte de stockage et l’instance managée doivent se trouver dans la même région ou bien dans deux régions jumelées.

Si votre stockage Azure se trouve derrière un pare-feu, vous pouvez voir le message suivant dans le journal des erreurs de l’instance managée SQL :

Audit: Storage access denied user fault. Creating an email notification:

Cela génère un e-mail qui vous avertit que l’audit de l’instance managée SQL ne parvient pas à écrire les journaux d’audit dans le compte de stockage. Si vous voyez cette erreur ou recevez cet e-mail, effectuez les étapes décrites dans cette section pour configurer votre pare-feu.

Pour configurer le pare-feu, suivez ces étapes :

1. Accédez à votre instance managée dans le portail Azure et sélectionnez le sous-réseau pour ouvrir la page Sous-réseaux.

   

2. Dans la page Sous-réseaux, sélectionnez le nom du sous-réseau pour ouvrir la page de configuration de ce sous-réseau.

   

3. Sous Délégation de sous-réseau, choisissez Microsoft.Sql/managedInstances dans le menu déroulant Déléguer le sous-réseau à un service. Attendez environ une heure le temps que les autorisations se propagent. Ensuite, sous Points de terminaison de service, choisissez Microsoft.Storage dans la liste déroulante Services.

   

4. Ensuite, accédez à votre compte de stockage dans le portail Azure, sélectionnez Réseaux sous Sécurité et réseaux, puis choisissez l’onglet Pare-feu et réseaux virtuels.

5. Sous l’onglet Pare-feu et réseaux virtuels de votre compte de stockage, choisissez +Ajouter un réseau virtuel existant pour ouvrir la page Ajouter des réseaux.

   

6. Sélectionnez l’abonnement, le réseau virtuel et le sous-réseau d’instance managée appropriés dans les menus déroulants, puis sélectionnez Ajouter pour ajouter le réseau virtuel de l’instance managée SQL au compte de stockage.

Authentifiez-vous auprès de votre compte Stockage Blob.

Utilisez un jeton SAS ou une identité managée pour accéder à votre compte Stockage Blob Azure.

Avertissement

Vous ne pouvez pas utiliser à la fois un jeton SAS et une identité managée en parallèle sur le même compte de stockage. Vous pouvez utiliser soit un jeton SAS, soit une identité managée, mais pas les deux.

Jeton SAP

Générer le jeton d’authentification SAS du Stockage Blob pour le service LRS

Accédez à votre compte Stockage Blob Azure à l’aide d’un jeton SAS.

Vous pouvez utiliser un compte Stockage Blob Azure comme stockage intermédiaire pour les fichiers de sauvegarde entre votre instance de SQL Server et votre déploiement SQL Managed Instance. Générez un jeton d’authentification SAS, avec uniquement les autorisations Lecture et Liste pour LRS. Le jeton permet au service LRS d’accéder à votre compte Stockage Blob et d’utiliser les fichiers de sauvegarde pour les restaurer dans sur votre instance managée.

Effectuez ces étapes pour générer le jeton :

1. Dans le portail Azure, ouvrez Explorateur Stockage.

2. Développez Conteneurs d’objets blob.

3. Cliquez avec le bouton droit sur le conteneur d'objets blob, puis sélectionnez Obtenir une signature d'accès partagé.

   

4. Sélectionnez le délai d’expiration du jeton. Assurez-vous que le jeton est valide pendant la durée de la migration.

5. Sélectionnez le fuseau horaire pour le jeton : UTC ou votre heure locale.

   Important

   Le fuseau horaire du jeton et votre instance gérée peuvent ne pas correspondre. Assurez-vous que le jeton SAS a la validité de temps appropriée en tenant compte des fuseaux horaires. Pour tenir compte des différences de fuseau horaire, définissez la valeur FROM de validité bien avant le début de votre fenêtre de migration et la valeur TO bien après la fin de votre migration.

6. Sélectionner uniquement les autorisations Lecture et Liste.

   Important

   Ne sélectionnez aucune autre autorisation. Sinon, LRS ne démarrera pas. Il s’agit d’une exigence de sécurité par défaut.

7. Sélectionnez Créer.

   

L’authentification SAS est générée avec la validité que vous avez indiquée. Vous avez besoin de la version d’URI du jeton, comme illustré dans la capture d’écran suivante :

Remarque

L’utilisation de jetons SAP créés avec des autorisations définies via la définition d’une stratégie d’accès stockée n’est pas prise en charge pour l’instant. Suivez les instructions de cette procédure afin de spécifier manuellement les autorisations Lecture et Liste pour le jeton SAS.

Copier les paramètres à partir du jeton SAS

Accédez à votre compte Stockage Blob Azure en utilisant un jeton SAS ou une identité managée.

Avant d’utiliser le jeton SAS pour démarrer LRS, vous devez comprendre sa structure. L’URI du jeton SAS généré se compose de deux parties séparées par un point d’interrogation (?), comme illustré dans cet exemple :

La première partie commençant par https:// jusqu’au point d’interrogation (?) est utilisée pour le paramètre StorageContainerURI qui est alimenté comme entrée au service LRS. Cela donne au service LRS des informations sur le dossier dans lequel les fichiers de sauvegarde de base de données sont stockés.

La deuxième partie, à partir du point d’interrogation (?) jusqu’à la fin de la chaîne, est le paramètre StorageContainerSasToken. Cette partie correspond au jeton d’authentification signé proprement dit, valide durant la période indiquée. Cette partie ne doit pas nécessairement commencer par sp=, comme dans l’exemple. Votre scénario peut différer.

Copiez les paramètres comme suit :

1. Copiez la première partie du jeton, de https:// jusqu’au point d’interrogation (?), sans l’inclure. Utilisez-la comme paramètre StorageContainerUri dans PowerShell ou Azure CLI lorsque vous démarrez LRS.

   

2. Copiez la deuxième partie du jeton, après le point d’interrogation (?) jusqu’à la fin de la chaîne. Utilisez-la comme paramètre StorageContainerSasToken dans PowerShell ou Azure CLI lorsque vous démarrez LRS.

   

Remarque

N’incluez pas le point d’interrogation (?) lorsque vous copiez l’une ou l’autre partie du jeton.

Identité gérée

Pour utiliser une identité managée, affectez une identité managée par le système ou une identité managée par l’utilisateur pour accéder au conteneur Stockage Blob Azure.

Pour ce faire, procédez comme suit :

1. Dans le portail Azure, accédez au compte Stockage Blob auquel vous envisagez d’autoriser l’accès à l’instance managée.
2. Sélectionnez Contrôle d’accès (IAM) .
3. Sélectionnez Ajouter, puis sélectionnez Ajouter une attribution de rôle.
4. Recherchez et sélectionnez le rôle existant Lecteur de données Stockage Blob. Les rôles personnalisés sont pris en charge tant qu’ils disposent des autorisations Lecture et Liste, au minimum.
5. Sélectionnez Identité managée.
6. Utilisez l’option Sélectionner des membres pour identifier votre abonnement.
7. Dans la liste déroulante Identité managée, sélectionnez SQL Managed Instance, puis sélectionnez l’instance managée vers laquelle vous souhaitez effectuer la migration.
8. Choisissez Sélectionner pour enregistrer vos paramètres et autoriser l’accès.
9. Terminez le processus en sélectionnant Vérifier + affecter.

Valider l’accès au stockage de votre instance managée

Vérifiez que votre instance managée peut accéder au compte Stockage Blob.

Tout d’abord, chargez une sauvegarde de base de données, comme full_0_0.bak, dans votre conteneur Stockage Blob Azure.

Ensuite, connectez-vous à votre instance managée et exécutez un exemple de requête test pour déterminer si votre instance managée est en mesure d’accéder à la sauvegarde dans le conteneur.

Jeton SAP

Si vous utilisez un jeton SAS pour vous authentifier auprès de votre compte de stockage, remplacez <sastoken> par votre jeton SAS et exécutez la requête suivante sur votre instance :

CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE' 
, SECRET = '<sastoken>' 

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak' 

Identité gérée

Si vous utilisez une identité managée pour vous authentifier auprès de votre compte de stockage, mettez à jour CREATE CREDENTIAL avec l’URL de votre compte de stockage et exécutez l’exemple de requête suivant sur votre instance :

RESTORE HEADERONLY 
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak' 

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'MANAGED IDENTITY' 

Charger des sauvegardes sur votre compte Stockage Blob

Lorsque votre conteneur blob est prêt et que vous avez confirmé que votre instance managée peut accéder au conteneur, vous pouvez commencer à charger vos sauvegardes sur votre compte Stockage Blob. Vous pouvez :

• Copier vos sauvegardes sur votre compte Stockage Blob
• Effectuez des sauvegardes à partir de SQL Server directement dans votre compte Stockage Blob à l’aide de la commande BACKUP TO URL, si votre environnement le permet (à partir de SQL Server versions 2012 SP1 CU2 et SQL Server 2014).

Copier les sauvegardes existantes sur votre compte Stockage Blob

Si vous utilisez une version antérieure de SQL Server, ou si votre environnement ne prend pas en charge la sauvegarde directe vers une URL, effectuez vos sauvegardes sur SQL Server comme vous le feriez normalement, puis copiez-les dans votre compte Stockage Blob.

Effectuer des sauvegardes sur une instance SQL Server

Configurez les bases de données que vous voulez migrer sur le mode de récupération complète pour autoriser les sauvegardes de fichier journal.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO

Pour effectuer manuellement des sauvegardes complètes, différentielles et de fichier journal de votre base de données sur le stockage local, utilisez l’exemple de script T-SQL suivant. CHECKSUM n’est pas obligatoire, mais nous le recommandons.

L’exemple suivant prend une sauvegarde complète de base de données sur le disque local :

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

L’exemple suivant prend une sauvegarde différentielle sur le disque local :

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

L’exemple suivant prend une sauvegarde du journal des transactions sur le disque local :

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO

Copier des sauvegardes sur votre compte Stockage Blob

Lorsque vos sauvegardes sont prêtes et que vous voulez commencer à migrer des bases de données vers une instance managée à l’aide de LRS, vous pouvez utiliser les approches suivantes pour copier les sauvegardes existantes dans votre compte Stockage Blob :

• Téléchargez et installez AzCopy.
• Téléchargez et installez l'Explorateur Stockage Microsoft Azure.
• Utilisez Explorateur Stockage dans le portail Azure.

Notes

Pour migrer plusieurs bases de données à l’aide du même conteneur Stockage Blob Azure, placez tous les fichiers de sauvegarde d’une base de données individuelle dans un dossier distinct à l’intérieur du conteneur. Utilisez la structure de fichier plat pour chaque dossier de base de données. Les dossiers imbriqués dans des dossiers de base de données ne sont pas pris en charge.

Effectuer des sauvegardes directement dans votre compte Stockage Blob

Si vous utilisez une version prise en charge de SQL Server (à compter de SQL Server 2012 SP1 CU2 et SQL Server 2014), et que vos stratégies d’entreprise et réseau l’autorisent, vous pouvez effectuer des sauvegardes de SQL Server directement dans votre compte Stockage Blob à l’aide de l’option SQL Server native BACKUP TO URL. Si vous pouvez utiliser BACKUP TO URL, vous n’avez pas besoin d’effectuer des sauvegardes sur le stockage local et de les charger dans votre compte Stockage Blob.

Quand vous effectuez des sauvegardes natives directement dans votre compte Stockage Blob, vous devez vous authentifier auprès du compte de stockage.

Utilisez la commande suivante pour créer des informations d’identification qui importent le jeton SAS dans votre instance SQL Server :

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',  
SECRET = '<SAS_TOKEN>';  

Pour obtenir des instructions détaillées sur l’utilisation de jetons SAS, consultez le tutoriel Utiliser Stockage Blob Azure avec SQL Server.

Une fois que vous avez créé les informations d’identification pour authentifier votre instance SQL Server auprès de Stockage Blob, vous pouvez utiliser la commande BACKUP TO URL pour effectuer des sauvegardes directement dans le compte de stockage. La commande CHECKSUM est recommandée, mais pas obligatoire.

L’exemple suivant prend une sauvegarde complète de base de données vers une URL :

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO

L’exemple suivant prend une sauvegarde différentielle de base de données vers une URL :

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'  
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO

L’exemple suivant prend une sauvegarde du journal des transactions vers une URL :

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'  
WITH COMPRESSION, CHECKSUM

Se connecter à Azure et sélectionner un abonnement

Utilisez la cmdlet PowerShell suivante pour vous connecter à Azure :

Login-AzAccount

Sélectionnez l’abonnement dans lequel se trouve votre instance managée à l’aide de la cmdlet PowerShell suivante :

Select-AzSubscription -SubscriptionId <subscription ID>

Démarrer la migration

Commencez la migration en démarrant LRS. Vous pouvez démarrer le service en mode autocomplétion ou en mode continu.

Lorsque vous utilisez le mode autocomplétion, la migration se termine automatiquement lorsque le dernier fichier de sauvegarde spécifié a été restauré. Cette option nécessite que la chaîne de sauvegarde toute entière soit disponible à l’avance et chargée dans votre compte Stockage Blob. Elle n’autorise pas l’ajout de nouveaux fichiers de sauvegarde durant la migration. Cette option requiert que la commande start spécifie le nom de fichier du dernier fichier de sauvegarde. Nous recommandons ce mode pour les charges de travail passives ne nécessitant aucun rattrapage de données.

Lorsque vous utilisez le mode continu, le service analyse continuellement le dossier Stockage Blob Azure et restaure tout nouveau fichier de sauvegarde ajouté pendant la migration. La migration ne s’achève qu’après que le basculement manuel a été demandé. Vous devez utiliser une migration en mode continu quand vous ne disposez pas d’une chaîne de sauvegarde entière à l’avance, et envisagez d’ajouter de nouveaux fichiers de sauvegarde en cours de migration. Nous recommandons ce mode pour les charges de travail actives nécessitant un rattrapage de données.

Planifiez l’accomplissement d’un travail de migration LRS unique dans un délai maximal de 30 jours. À l’expiration de ce délai, le travail LRS est automatiquement annulé.

Notes

Lors de la migration de plusieurs bases de données, LRS doit être démarré séparément pour chaque base de données qui pointe vers le chemin d’URI complet du conteneur Stockage Blob Azure et le dossier de la base de données individuelle.

Démarrer le service LRS en mode d’autocomplétion

Vérifiez que chaîne de sauvegarde toute entière a été chargée sur votre compte Stockage Blob Azure. Cette option n’autorise pas l’ajout de nouveaux fichiers de sauvegarde une fois la migration en cours.

Pour démarrer LRS en mode autocomplétion, utilisez les commandes PowerShell ou Azure CLI. Indiquez le nom du dernier fichier de sauvegarde à l’aide du paramètre -LastBackupName. Après la restauration du dernier fichier de sauvegarde spécifié, le service opère automatiquement un basculement.

Restaurez votre base de données à partir du compte de stockage à l’aide du jeton SAS ou d’une identité managée.

Important

• Avant de démarrer la migration en mode autocomplétion, assurez-vous que la chaîne de sauvegarde entière a été chargée sur votre compte Stockage Blob Azure. Ce mode n’autorise pas l’ajout de nouveaux fichiers de sauvegarde une fois la migration en cours.
• Assurez-vous que vous avez correctement spécifié le dernier fichier de sauvegarde, et que vous n’avez pas chargé d’autres fichiers. Si le système détecte des fichiers de sauvegarde au-delà du dernier fichier spécifié, la migration échoue.

Jeton SAP

L’exemple PowerShell suivant démarre LRS en mode autocomplétion à l’aide d’un jeton SAS :

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

L’exemple Azure CLI suivant démarre LRS en mode autocomplétion à l’aide d’un jeton SAS :

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Identité gérée

L’exemple PowerShell suivant démarre LRS en mode autocomplétion à l’aide d’une identité managée :

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Démarrer le service LRS en mode continu

Assurez-vous que vous avez chargé votre chaîne de sauvegarde initiale sur votre compte Stockage Blob Azure.

Important

Après avoir démarré LRS en mode continu, vous pourrez ajouter de nouvelles sauvegardes de journal et différentielles à votre compte de stockage jusqu’au basculement manuel. Une fois le basculement manuel lancé, aucun fichier différentiel supplémentaire ne peut plus être ajouté ou restauré.

Jeton SAP

L’exemple PowerShell suivant démarre LRS en mode continu à l’aide d’un jeton SAS :

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

L’exemple Azure CLI suivant démarre LRS en mode continu :

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Identité gérée

L’exemple PowerShell suivant démarre LRS en mode continu à l’aide d’une identité managée :

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

Script du travail de migration

Les clients PowerShell et Azure CLI utilisés pour démarrer le service LRS en mode continu sont synchrones. Dans ce mode, PowerShell et Azure CLI attendent la réponse de l’API rendant compte de la réussite ou de l’échec avant de démarrer le travail.

Pendant ce temps d’attente, la commande ne renvoie pas le contrôle à l’invite de commandes. Si vous créez un script pour l’expérience de migration et que vous avez besoin que la commande de démarrage du service LRS rende immédiatement le contrôle afin continuer avec le reste du script, vous pouvez exécuter PowerShell en tant que travail en arrière-plan avec le commutateur -AsJob. Par exemple :

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Quand vous démarrez un travail en arrière-plan, un objet de travail est immédiatement retourné, même si le travail prend plus de temps que prévu. Vous pouvez continuer à travailler dans la session sans interruption pendant l'exécution de la tâche. Pour plus d’informations sur l’exécution de PowerShell en tant que travail en arrière-plan, consultez la documentation PowerShell Start-Job.

De même, pour démarrer une commande Azure CLI sur Linux en tant que processus en arrière-plan, utilisez le signe esperluette (&) à la fin de la commande de démarrage du service LRS :

az sql midb log-replay start <required parameters> &

Superviser la progression de la migration

Az.SQL 4.0.0 et version ultérieure fournit un rapport de progression détaillé. Consultez Détails de la restauration de base de données managée – Obtenir pour obtenir un exemple de sortie.

Pour surveiller la progression de la migration par le biais de PowerShell, utilisez la commande suivante :

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Pour surveiller la progression de la migration par le biais d’Azure CLI, utilisez la commande suivante :

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

Arrêter la migration (facultatif)

Si vous devez arrêter la migration, utilisez PowerShell ou Azure CLI. L’arrêt de la migration entraîne la suppression de la base de données en cours de restauration sur votre instance managée. Il n’est donc pas possible de reprendre la migration.

Pour arrêter le processus de migration par le biais de PowerShell, utilisez la commande suivante :

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Pour arrêter le processus de migration par le biais d’Azure CLI, utilisez la commande suivante :

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Terminer la migration (mode continu)

Si vous démarrez LRS en mode continu, assurez-vous que votre application et la charge de travail SQL Server ont été arrêtées pour empêcher la génération de tout nouveau fichier de sauvegarde. Assurez-vous que la dernière sauvegarde de votre instance SQL Server a été chargée sur votre compte Stockage Blob Azure. Surveillez la progression de la restauration sur votre instance managée et vérifiez que la dernière sauvegarde en queue de journal a été restaurée.

Une fois la dernière sauvegarde en queue de journal restaurée sur votre instance managée, lancez le basculement manuel pour terminer la migration. Une fois le basculement terminé, la base de données est disponible pour l’accès en lecture et en écriture sur l’instance managée.

Pour terminer le processus de migration en mode continu du service LRS avec PowerShell, utilisez la commande suivante :

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Pour terminer le processus de migration en mode continu du service LRS avec Azure CLI, utilisez la commande suivante :

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Résoudre les problèmes LRS

Après avoir démarré LRS, utilisez l’une des cmdlets de supervision suivantes pour afficher l’état de l’opération :

• Pour PowerShell : get-azsqlinstancedatabaselogreplay
• Pour Azure CLI : az_sql_midb_log_replay_show

Si, après un certain temps, le service LRS ne parvient pas à démarrer et présente une erreur, recherchez les problèmes les plus courants :

• Une base de données existante sur votre instance managée a-t-elle le même nom que celui que vous essayez de migrer à partir de votre instance SQL Server ? Résolvez ce conflit en renommant l’une des bases de données.
• Les autorisations accordées au jeton SAS sont-elles Lecture et Liste uniquement ?
• Avez-vous copié le jeton SAS pour LRS après le point d’interrogation (?), le contenu ressemblant à sv=2020-02-10... ? 
• Le délai de validité du jeton SAS est-il correct pour la fenêtre de temps du démarrage et de l’arrêt de la migration ? Il peut y avoir des décalages en raison des différents fuseaux horaires utilisés pour votre déploiement SQL Managed Instance et le jeton SAS. Essayez de regénérer le jeton SAS en étendant la validité de la période de temps avant et après la date actuelle.
• Lors du démarrage de plusieurs restaurations Log Replay en parallèle ciblant le même conteneur de stockage, assurez-vous que le même jeton SAS valide est fourni pour chaque opération de restauration.
• Le nom de la base de données, le nom du groupe de ressources et le nom de l’instance gérée sont-ils correctement orthographiés ?
• Si vous avez démarré le service LRS en mode autocomplétion, le nom du dernier fichier de sauvegarde spécifié était-il valide ?
• Le chemin d’accès URI de sauvegarde contient-il des mots clés backup ou backups ? Renommez le conteneur ou les dossiers qui utilisent backup ou backups en tant que mots clés réservés.

Étapes suivantes

• En savoir plus sur la migration vers Azure SQL Managed Instance à l’aide de la fonctionnalité de liaison.
• En savoir plus sur la migration de SQL Server vers Azure SQL Managed Instance.
• En savoir plus sur les différences entre SQL Server et SQL Managed Instance.
• En savoir plus sur les meilleures pratiques en termes de coût et de taille des charges de travail migrées vers Azure.