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. Étudiez attentivement les sections Limitations et Bonnes pratiques pour garantir une migration réussie.

Important

• Avant de migrer des bases de données vers le niveau de service Critique pour l’entreprise, tenez compte de ces limitations, qui ne s’appliquent pas au niveau de service Usage général.
• 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.

Avant de migrer des bases de données vers le niveau de service Critique pour l’entreprise, tenez compte de ces limitations, qui ne s’appliquent pas au niveau de service Usage général.

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.
• Même si l’activation de CHECKSUM pour les sauvegardes n’est pas obligatoire, elle est vivement recommandé pour empêcher la migration involontaire des bases de données endommagées et pour accélérer les opérations de restauration.

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 Read et List générées pour le conteneur Stockage Blob ou une identité managée pouvant accéder au conteneur. L’octroi d’autorisations supérieures à Read et List entraîne l’échec du LRS.
• 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.
• Pour empêcher le retard ou l’interruption de la migration, configurez une fenêtre de maintenance afin que les mises à jour système soient planifiées à un jour et une heure spécifiques en dehors de la fenêtre de migration.
• 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é.
• Pour empêcher la migration involontaire d’une base de données endommagée et pour une restauration plus rapide de la base de données, activez CHECKSUM lorsque vous effectuez vos sauvegardes. Bien que SQL Managed Instance effectue un contrôle d’intégrité de base sur les sauvegardes sans CHECKSUM, l’interception de toutes les formes d’altération des données n’est pas garantie. Effectuer des sauvegardes avec CHECKSUM est la seule façon de s’assurer que la sauvegarde restaurée sur SQL Managed Instance n’est pas endommagée. La vérification de l’intégrité de base sur les sauvegardes sans CHECKSUM augmente le temps de restauration d’une base de données.
• Lors de la migration vers le niveau de service Critique pour l’entreprise, tenez compte d’un délai prolongé de la disponibilité de la base de données après basculement, pendant que les bases de données sont allouées à des réplicas secondaires. Pour les bases de données particulièrement volumineuses avec des exigences de temps d’arrêt minimales, envisagez d’abord de migrer vers le niveau de service Usage général, puis de procéder à la mise à niveau vers le niveau de service Critique pour l’entreprise, ou d’utiliser la liaison Managed Instance pour migrer vos données.
• Le chargement de milliers de fichiers de base de données à restaurer peut entraîner des temps de migration excessifs et même une défaillance. Consolidez les bases de données en réduisant le nombre de fichiers pour accélérer le processus de migration et garantir son succès.

Configurer une fenêtre de maintenance

Les mises à jour système pour SQL Managed Instance prennent le pas sur les migrations de bases de données en cours.

L'impact sur la migration varie en fonction du niveau de service :

• Dans le niveau de service Usage général, 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.
• Dans le niveau de service Critique pour l’entreprise, toutes les migrations LRS en attente sont annulées et redémarrées automatiquement après l’application 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. Par exemple, pour une migration débutant le lundi, configurez la fenêtre de maintenance personnalisée le dimanche afin de maximiser le temps disponible pour terminer la migration.

La configuration d’une fenêtre de maintenance n’est pas obligatoire, mais est fortement recommandée pour les bases de données volumineuses.

Remarque

Bien qu’une fenêtre de maintenance permette de contrôler la prévisibilité des mises à jour planifiées, elle ne garantit pas l’absence de basculements non planifiés ni de mises à jour correctives de sécurité. Un basculement non planifié ou un correctif de sécurité (prioritaire sur toutes les autres mises à jour) peut toujours interrompre votre migration.

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 SQL Managed Instance 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, le message suivant peut s’afficher dans le journal des erreurs de SQL Managed Instance :

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 Create (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 :

Notes

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.

   

Notes

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 il est recommandé pour éviter la migration d'une base de données endommagée et garantir des temps de restauration plus rapides.

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é.

Remarque

Lorsque vous migrez plusieurs bases de données, chaque base de données doit se trouver dans son propre dossier. 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. Des dossiers imbriqués dans des dossiers de base de données ne sont pas pris en charge.

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 en cours par le biais de PowerShell, utilisez la commande suivante :

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

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

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

Pour suivre des détails supplémentaires d’une requête ayant échoué, utilisez la commande PowerShell Get-AzSqlInstanceOperation ou utilisez la commande Azure CLI az sql mi op show.

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"

Limites

Tenez compte des limitations suivantes quand vous effectuez une migration avec LRS :

• 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.
• Pendant le processus de migration, des bases de données en cours de restauration ne peuvent pas être utilisées pour l’accès en lecture seule sur SQL Managed Instance.
• 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.
• Seuls les fichiers de base de données .bak, .loget .diff sont pris en charge par LRS. Les fichiers Dacpac et bacpac ne sont pas pris en charge.
• Vous devez configurer une fenêtre de maintenance pour planifier les mises à jour système à un jour et une heure spécifiques. Prévoyez d’exécuter et d’achever les migrations en dehors de la fenêtre de maintenance planifiée.
• Les sauvegardes de base de données effectuées sans CHECKSUM sont associées aux limitations suivantes :
  • Elles peuvent potentiellement entraîner la migration de bases de données endommagées.
  • Leur restauration prend plus de temps que celle des sauvegardes de bases de données réalisées avec la fonctionnalité CHECKSUM activée.
• Le jeton de signature d’accès partagé (SAS) utilisé par LRS doit être généré pour l’ensemble du conteneur Stockage Blob Azure et doit avoir les autorisations Read et List uniquement. Par exemple, si vous accordez des autorisations Read, List et Write, LRS ne démarre pas en raison de l’autorisation Write supplémentaire.
• L’utilisation de jetons SAS créés avec des autorisations définies via une stratégie d’accès stockée n’est pas prise en charge. Suivez les instructions de cet article pour spécifier manuellement les autorisations Lecture et Liste pour le jeton SAP.
• Vous devez placer les fichiers de sauvegarde de différentes bases de données dans des dossiers distincts dans le compte Stockage Blob dans une structure de fichier plat. Les dossiers imbriqués dans des dossiers de base de données ne sont pas pris en charge.
• Si vous utilisez le mode autocomplétion, l’ensemble de la chaîne de sauvegarde doit être disponible à l’avance sur le compte Stockage Blob. Il n’est pas possible d’ajouter de nouveaux fichiers de sauvegarde en mode autocomplétion. Utilisez le mode continu si vous devez ajouter de nouveaux fichiers de sauvegarde en cours de migration.
• Vous devez démarrer LRS séparément pour chaque base de données qui pointe vers le chemin d’URI complet contenant un dossier de base de données individuel.
• Le chemin d’URI de sauvegarde, le nom du conteneur ou les noms de dossiers ne doivent pas contenir backup ou backups, qui sont des mots clés réservés.
• 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 service LRS peut prendre en charge jusqu’à 100 processus de restauration simultanés pour une seule instance gérée.
• Un travail LRS unique peut s’exécuter pendant un maximum de 30 jours, après quoi il sera automatiquement annulé.
• Il est possible d’utiliser un compte de stockage Azure derrière un pare-feu. Pour cela, une configuration supplémentaire est nécessaire, et le compte de stockage et l’instance managée doivent se trouver dans la même région ou dans deux régions jumelées. Pour en savoir plus, consultez Configurer un pare-feu.
• Le nombre maximal de bases de données que vous pouvez restaurer en parallèle est de 200 par abonnement unique. Dans certains cas, il est possible d’augmenter cette limite en ouvrant un ticket de support.
• Le chargement de milliers de fichiers de base de données à restaurer peut entraîner des temps de migration excessifs et même une défaillance. Consolidez les bases de données en réduisant le nombre de fichiers pour accélérer le processus de migration et garantir son succès.

Remarque

Si vous avez besoin qu’une base de données soit accessible en lecture seule pendant la migration, avec un délai de migration beaucoup plus long et un temps d’arrêt minimal, envisagez d’utiliser la fonctionnalité de liaison Managed Instance comme solution de migration recommandée.

Limitations lors de la migration vers le niveau de service Critique pour l’entreprise

Lors de la migration vers SQL Managed Instance dans le niveau de service Critique pour l’entreprise, tenez compte des limitations suivantes :

• Lors de la migration de bases de données volumineuses, un temps d’arrêt considérable peut survenir, car les bases de données ne sont pas disponibles après le basculement, mais qu’une fois allouées à des réplicas secondaires dans le niveau de service Critique pour l’entreprise. Les solutions de contournement sont répertoriées dans la section Basculement prolongé.
• La migration redémarre automatiquement depuis le début si elle est interrompue par un basculement non planifié, une mise à jour système ou un correctif de sécurité, compliquant ainsi la planification d'une migration prévisible sans surprises de dernière minute.

Important

Ces limitations s’appliquent uniquement lors de la migration vers le niveau de service Critique pour l’entreprise, et non vers le niveau de service Usage général.

Basculement prolongé dans le niveau de service Critique pour l’entreprise

Si vous migrez vers une instance managée SQL dans le niveau de service Critique pour l’entreprise, tenez compte du délai d’ajout des bases de données sur le réplica principal, pendant que les bases de données sont allouées à des réplicas secondaires. Ceci est particulièrement vrai pour les fichiers volumineux.

La migration vers SQL Managed Instance dans le niveau de service Critique pour l’entreprise prend plus de temps que dans le niveau de service Usage général. Une fois le basculement effectué dans Azure, les bases de données ne sont pas disponibles tant qu'elles n'ont pas été allouées aux trois réplicas secondaires depuis le réplica principal, ce qui peut prendre un certain temps en fonction de la taille de la base de données. Plus la base de données est grande, plus l’essaimage des réplicas secondaires peut prendre de temps (jusqu’à plusieurs heures).

Si la disponibilité des bases de données dès la fin du basculement est cruciale, envisagez les solutions de contournement suivantes :

• Migrez d’abord vers le niveau de service Usage général, puis effectuez une mise à niveau vers le niveau de service Critique pour l’entreprise lors d’une fenêtre de maintenance ultérieure. La mise à niveau de votre niveau de service est une opération en ligne qui maintient vos bases de données accessibles jusqu’à un court basculement, qui constitue la dernière étape de l’opération de mise à niveau.
• Utilisez la liaison Managed Instance pour effectuer une migration en ligne vers une instance Critique pour l’entreprise sans avoir à attendre que les bases de données soient disponibles après le basculement.

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 en cours :

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

Pour passer en revue les détails relatifs à une opération ayant échoué :

• Pour PowerShell : Get-AzSqlInstanceOperation
• Pour Azure CLI : az sql mi op 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 ? L’octroi d’autorisations supérieures à Read et List entraîne l’échec du LRS.
• 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.