Partager via

Tutoriel : Migrer SQL Server vers SQL Server sur les machines virtuelles Azure avec DMS

  • Article

Vous pouvez utiliser Azure Database Migration Service et l’extension de migration Azure SQL dans Azure Data Studio pour migrer des bases de données d’une instance locale SQL Server vers SQL Server sur des machines virtuelles Azure (SQL Server 2016 et versions ultérieures) avec un temps d’arrêt minimal.

Pour connaître les méthodes de migration de base de données qui peuvent nécessiter une configuration manuelle, consultez Migration d’une instance de SQL Server vers SQL Server sur les machines virtuelles Azure.

Dans ce tutoriel, vous migrez la base de données AdventureWorks2022 d’une instance SQL Server locale vers une machine virtuelle SQL Server sur Azure avec un temps d’arrêt minimal à l’aide d’Azure Data Studio avec Azure Database Migration Service.

Ce tutoriel propose des options de migration en ligne et hors ligne, y compris un temps d’arrêt acceptable pendant le processus de migration.

Dans ce tutoriel, vous allez apprendre à :

  • Lancer l’Assistant Migration vers Azure SQL dans Azure Data Studio.
  • Effectuer une évaluation de vos bases de données SQL Server sources.
  • Collecter les données de performance de votre SQL Server source.
  • Obtenir une recommandation de SQL Server sur la référence SKU de machine virtuelle Azure la mieux adaptée à votre charge de travail.
  • Spécifier les détails de votre SQL Server source, l’emplacement de la sauvegarde et votre SQL Server cible sur les machines virtuelles Azure.
  • Créer une instance d’Azure Database Migration Service et installer le runtime d’intégration autohébergé pour accéder au serveur source et aux sauvegardes.
  • Démarrer et superviser la progression de votre migration.
  • Effectuer le basculement de la migration lorsque vous êtes prêt.

Prérequis

Avant de commencer le tutoriel :

  • Téléchargez et installez Azure Data Studio.

  • Installez l’extension de migration Azure SQL à partir de la place de marché Azure Data Studio.

  • Disposer d’un compte Azure affecté à l’un des rôles intégrés suivants :

    • Contributeur pour l’instance cible SQL Server sur des machines virtuelles Azure et pour le compte de stockage où vous chargez vos fichiers de sauvegarde de base de données à partir d’un partage réseau SMB (Server Message Block)

    • Rôle lecteur pour le groupe de ressources Azure qui contient l’instance cible SQL Server sur des machines virtuelles Azure ou pour votre compte Stockage Azure

    • Rôle de propriétaire ou de contributeur pour l’abonnement Azure

    En guise d’alternative à l’utilisation de l’un de ces rôles intégrés, vous pouvez attribuer un rôle personnalisé.

    Important

    Un compte Azure n’est requis que lorsque vous configurez les étapes de migration. Un compte Azure n’est pas nécessaire pour l’évaluation ou pour afficher les recommandations Azure dans l’Assistant Migration dans Azure Data Studio.

  • Créer une instance cible de SQL Server sur les machines virtuelles Azure.

    Important

    Si vous disposez d’une machine virtuelle Azure existante, elle doit être inscrite avec l’extension SQL IaaS Agent en mode Administration complète.

  • Assurez-vous que les connexions que vous utilisez pour connecter l’instance source SQL Server sont membres du rôle serveur sysadmin ou disposent de l’autorisation CONTROL SERVER.

  • Fournissez un partage réseau SMB, un partage de fichiers de compte Stockage Azure ou un conteneur d’objets blob de compte Stockage Azure contenant vos fichiers de sauvegarde complète de base de données et de sauvegarde des journaux de transactions suivants. Database Migration Service utilise l’emplacement de sauvegarde pendant la migration de la base de données.

    • L’extension de migration Azure SQL pour Azure Data Studio n’effectue pas de sauvegardes de base de données et n’initie aucune sauvegarde de base de données en votre nom. Au lieu de cela, le service utilise des fichiers de sauvegarde de base de données existants pour la migration.

    • Si vos fichiers de sauvegarde de base de données sont fournis sur un partage réseau SMB, vous devez créer un compte Stockage Azure qui permet au service Database Migration Service de charger les fichiers de sauvegarde de base de données et de les utiliser pour la migration. Veillez à créer le compte de stockage Azure dans la même région que celle où vous créez votre instance de Database Migration Service.

    • Vous pouvez écrire chaque sauvegarde dans un fichier de sauvegarde distinct ou dans plusieurs fichiers de sauvegarde. L’ajout de plusieurs sauvegardes, comme des journaux de transaction et complets à un seul support de sauvegarde n’est pas pris en charge.

    • Vous pouvez fournir des sauvegardes compressées pour réduire le risque de rencontrer des problèmes de migration de sauvegardes volumineuses.

  • Assurez-vous que le compte de service exécutant l’instance source SQL Server dispose des autorisations en lecture et en écriture sur le partage réseau SMB qui contient les fichiers de sauvegarde de base de données.

  • Si vous migrez une base de données protégée par Transparent Data Encryption (TDE), le certificat de l’instance source SQL Server doit être migré vers SQL Server sur des machines virtuelles Azure avant de migrer les données. Pour en savoir plus, consultez Déplacer une base de données protégée par TDE vers une autre instance SQL Server.

    Conseil

    Si votre base de données contient des données sensibles protégées par la fonctionnalité Always Encrypted, le processus de migration effectue automatiquement la migration de vos clés Always Encrypted vers votre instance cible de SQL Server sur les machines virtuelles Azure.

  • Si vos sauvegardes de base de données se trouvent dans un partage de fichiers réseau, fournissez un ordinateur sur lequel installer l’IR auto-hébergé pour accéder et migrer les sauvegardes de base de données. L’Assistant Migration vous fournit le lien de téléchargement et les clés d’authentification pour télécharger et installer votre IR auto-hébergé.

    En prévision de la migration, vérifiez que les règles de pare-feu sortantes et les noms de domaine suivants sont activés sur l’ordinateur où vous installez le runtime d’intégration autohébergé :

    Noms de domaine Port sortant Description
    Cloud public : {datafactory}.{region}.datafactory.azure.net
    ou*.frontend.clouddatahub.net

    Azure Government : {datafactory}.{region}.datafactory.azure.us
    Microsoft Azure utilisé par 21Vianet : {datafactory}.{region}.datafactory.azure.cn    		 443 Requis par l’IR auto-hébergé pour se connecter à Database Migration Service.
    Pour une fabrique de données nouvellement créée dans un cloud public, recherchez le nom de domaine complet (FQDN) de votre clé de runtime d’intégration auto-hébergée, au format {datafactory}.{region}.datafactory.azure.net.
    Pour une fabrique de données existante, si vous ne voyez pas le nom de domaine complet dans votre clé d’intégration auto-hébergée, utilisez *.frontend.clouddatahub.net à la place.
    download.microsoft.com 443 Exigé par le runtime d’intégration auto-hébergé pour télécharger les mises à jour. Si vous avez désactivé la mise à jour automatique, vous pouvez ignorer la configuration de ce domaine.
    .core.windows.net 443 Utilisé par l’IR auto-hébergé qui se connecte au compte de stockage Azure pour charger les sauvegardes de base de données à partir de votre partage réseau

    Conseil

    Si vos fichiers de sauvegarde de base de données sont déjà fournis dans un compte de stockage Azure, l’IR auto-hébergé n’est pas requis pendant le processus de migration.

  • Lorsque vous utilisez l’IR auto-hébergé, assurez-vous que l’ordinateur sur lequel le runtime est installé peut se connecter à l’instance SQL Server et au partage de fichiers réseau source où se trouvent les fichiers de sauvegarde.

  • Activez le port de sortie 445 pour autoriser l’accès au partage de fichiers réseau. Pour plus d’informations, consultez Recommandations relatives à l’utilisation d’un runtime d’intégration auto-hébergé.

  • Si vous utilisez Azure Database Migration Service pour la première fois, assurez-vous que le Microsoft.DataMigration fournisseur de ressources est inscrit dans votre abonnement.

Ce tutoriel décrit une migration hors connexion de SQL Server vers SQL Server sur les machines virtuelles Azure.

Ouvrez l’Assistant Migration vers Azure SQL dans Azure Data Studio.

Pour ouvrir l’Assistant Migrer vers Azure SQL :

  1. Dans Azure Data Studio, accédez à Connexions. Sélectionnez et connectez-vous à votre instance locale SQL Server. Vous pouvez également vous connecter à SQL Server sur une machine virtuelle Azure.

  2. Cliquez avec le bouton droit sur la connexion au serveur, puis sélectionnez Gérer.

  3. Dans le menu du serveur sous Général, sélectionnez Migration Azure SQL.

  4. Dans le tableau de bord de l’extension de migration Azure SQL, sélectionnez Migrer vers Azure SQL pour ouvrir l’Assistant Migration.

    Capture d’écran montrant comment ouvrir l’Assistant Migrer vers Azure SQL.

  5. Sur la première page de l’Assistant, démarrez une nouvelle session ou reprenez une session précédemment enregistrée.

Exécuter une évaluation de base de données, collecter les données de performances et obtenir les recommandations Azure

  1. Dans Étape 1 : Bases de données à évaluer dans l’Assistant Migrer vers Azure SQL, sélectionnez les bases de données à évaluer. Ensuite, sélectionnez Suivant.

  2. Dans Étape 2 : Résultats et recommandations de l’évaluation, effectuez les étapes suivantes :

    1. Dans Choisissez votre cible Azure SQL, sélectionnez SQL Server sur des machines virtuelles Azure.

      Capture d’écran montrant une confirmation d’évaluation.

    2. Sélectionnez Afficher/Sélectionner pour afficher les résultats de l’évaluation.

    3. Dans les résultats de l’évaluation, sélectionnez la base de données, puis passez en revue le rapport d’évaluation pour vous assurer qu’aucun problème n’a été détecté.

    4. Sélectionnez Obtenir la recommandation Azure pour ouvrir le volet de recommandations.

    5. Sélectionnez Collecter les données de performance maintenant. Choisissez un dossier sur votre ordinateur local pour stocker les journaux de performances, puis sélectionnez Démarrer.

      Azure Data Studio collecte les données de performances jusqu’à ce que vous arrêtiez la collecte ou fermiez Azure Data Studio.

      Après 10 minutes, Azure Data Studio indique qu’une recommandation est disponible pour SQL Server sur des machines virtuelles Azure. Une fois la première recommandation générée, vous pouvez sélectionner Redémarrer la collecte de données pour continuer à exécuter le processus de collecte des données et affiner les recommandations SKU. Une évaluation étendue est particulièrement utile si vos modèles d’utilisation varient au fil du temps.

    6. Dans la cible SQL Server sur des machines virtuelles Azure sélectionnée, choisissez Afficher les détails pour ouvrir le rapport de recommandation de référence SKU détaillé :

    7. Dans Passer en revue les recommandations pour SQL Server sur des machines virtuelles Azure, passez en revue la recommandation. Pour enregistrer une copie de la recommandation, cochez la case Enregistrer le rapport de recommandations.

  3. Sélectionnez Fermer pour fermer le sous-onglet de recommandations.

  4. Sélectionnez Suivant pour poursuivre la migration de votre base de données dans l’Assistant.

Configurer les paramètres de migration

  1. Dans Étape 3 : Cible Azure SQL dans l’Assistant Migrer vers Azure SQL, sélectionnez votre compte Azure, votre abonnement Azure, la région ou l’emplacement Azure, ainsi que le groupe de ressources qui contient l’instance SQL Server sur des machines virtuelles Azure cible. Ensuite, sélectionnez Suivant.

  2. Dans Étape 4 : Mode de migration, sélectionnez Migration hors connexion, puis Suivant.

    Notes

    En mode de migration hors connexion, la base de données SQL Server source ne doit pas être utilisée pour l’activité d’écriture pendant que les fichiers de sauvegarde de base de données sont restaurés l’instance cible de SQL Server sur les machines virtuelles Azure. Le temps d’arrêt de l’application persiste du début du processus de migration jusqu’à ce qu’il soit terminé.

  3. Dans Étape 5 : Configuration de la source de données, sélectionnez l’emplacement de vos sauvegardes de base de données. Vos sauvegardes de base de données peuvent se trouver sur un partage réseau local ou dans un conteneur d’objets blob de stockage Azure.

    Notes

    Si vos sauvegardes de base de données se trouvent sur un partage réseau local, vous devez configurer le runtime d’intégration autohébergé à l’étape suivante de l’Assistant. Un runtime d’intégration autohébergé est nécessaire pour accéder aux sauvegardes de votre base de données source, vérifier la validité du jeu de sauvegarde et charger ce dernier vers le compte Stockage Azure.

    Si vos sauvegardes de base de données se trouvent déjà dans un conteneur Azure Storage Blob, vous n’avez pas besoin de configurer le runtime d’intégration autohébergé.

  • Pour les sauvegardes situées sur un partage réseau, entrez ou sélectionnez les informations suivantes :

    Nom Description
    Informations d’identification de la source - Nom d’utilisateur Informations d’identification (authentification Windows et SQL) permettant de se connecter à l’instance source de SQL Server et de valider les fichiers de sauvegarde.
    Informations d’identification de la source - Mot de passe utilisateur Informations d’identification (authentification Windows et SQL) permettant de se connecter à l’instance source de SQL Server et de valider les fichiers de sauvegarde.
    Emplacement de partage réseau qui contient les sauvegardes Emplacement de partage réseau qui contient les fichiers de sauvegarde complète et de sauvegarde des journaux de transactions. Les fichiers non valides ou les fichiers de sauvegarde du partage réseau qui n’appartiennent pas au jeu de sauvegarde valide sont automatiquement ignorés durant le processus de migration.
    Compte d’utilisateur Windows avec accès en lecture à l’emplacement du partage réseau Informations d’identification Windows (nom d’utilisateur) du compte ayant accès en lecture au partage réseau pour récupérer les fichiers de sauvegarde.
    Mot de passe Informations d’identification Windows (Mot de passe) du compte ayant accès en lecture au partage réseau pour récupérer les fichiers de sauvegarde.
    Nom de la base de données cible Vous pouvez modifier le nom de la base de données cible pendant le processus de migration.

  • Pour les sauvegardes stockées dans un conteneur d’objets blob du Stockage Azure, entrez ou sélectionnez les informations suivantes :

    Nom Description
    Nom de la base de données cible Vous pouvez modifier le nom de la base de données cible pendant le processus de migration.
    Détails du compte de stockage Groupe de ressources, compte de stockage et conteneur où se trouvent les fichiers de sauvegarde.
    Dernier fichier de sauvegarde Nom de fichier de la dernière sauvegarde de la base de données que vous migrez.

    Important

    Si la fonctionnalité de contrôle de bouclage est activée et que le SQL Server source et le partage de fichiers se trouvent sur le même ordinateur, la source ne peut pas accéder au partage de fichiers à l’aide du FQDN. Pour résoudre ce problème, désactivez la fonctionnalité du contrôle de bouclage.

  • L’extension de migration Azure SQL pour Azure Data Studio n’exige plus de configurations spécifiques au niveau des paramètres réseau de votre compte Stockage Azure pour la migration de vos bases de données SQL Server vers Azure. Cependant, selon l’emplacement de sauvegarde de votre base de données et la configuration souhaitée des paramètres réseau du compte de stockage, quelques étapes sont nécessaires pour permettre à vos ressources d’accéder au compte Stockage Azure. Consultez le tableau suivant pour découvrir les différents scénarios de migration et les différentes configurations réseau :

    Scénario Partage réseau SMB Conteneur de compte Stockage Azure
    Activé à partir de tous les réseaux Aucune étape supplémentaire Aucune étape supplémentaire
    Activé à partir de réseaux virtuels et d’adresses IP sélectionnés Voir 1a Voir 2a
    Activé à partir de réseaux virtuels et d’adresses IP sélectionnés + point de terminaison privé Voir 1b Voir 2b

1a – Configuration réseau de Stockage Blob Azure

Si votre runtime d’intégration auto-hébergé (SHIR) est installé sur une machine virtuelle Azure, consultez la section 1b – Configuration réseau de Stockage Blob Azure. Si votre runtime d'intégration auto-hébergé (SHIR) est installé sur votre réseau local, vous devez ajouter votre adresse IP cliente de la machine d’hébergement dans votre compte Stockage Azure comme suit :

Capture d’écran qui montre les informations réseau du compte de stockage.

Pour appliquer cette configuration spécifique, connectez-vous au portail Azure à partir de la machine SHIR, ouvrez la configuration du compte Stockage Azure, sélectionnez Réseau, puis cochez la case Ajouter l’adresse IP de votre client. Sélectionnez Enregistrer pour rendre la modification persistante. Pour les étapes restantes, consultez la section 2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé).

1b – Configuration réseau de Stockage Blob Azure

Si votre SHIR est hébergé sur une machine virtuelle Azure, vous devez ajouter le réseau virtuel de la machine virtuelle au compte Stockage Azure, car la machine virtuelle a une adresse IP non publique qui ne peut pas être ajoutée à la section Plage d’adresses IP.

Capture d’écran qui montre la configuration du pare-feu réseau du compte de stockage.

Pour appliquer cette configuration spécifique, localisez votre compte Stockage Azure. Ensuite, dans le panneau Stockage des données, sélectionnez Réseau, puis cochez la case Ajouter un réseau virtuel existant. Dans le nouveau panneau qui s’ouvre, sélectionnez l’abonnement, le réseau virtuel et le sous-réseau de la machine virtuelle Azure qui héberge le runtime d’intégration. Vous trouverez ces informations dans la page Vue d’ensemble de la machine virtuelle Azure. Il se peut que le sous-réseau indique Point de terminaison de service obligatoire. Si c’est le cas, sélectionnez Activer. Une fois que tout est prêt, enregistrez les mises à jour. Pour les étapes restantes nécessaires, reportez-vous à la section 2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé).

2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé)

Si vos sauvegardes sont placées directement dans un conteneur Stockage Azure, toutes les étapes précédentes sont inutiles, car aucun runtime d’intégration ne communique avec le compte Stockage Azure. Cependant, il nous reste encore à vérifier que l’instance cible de SQL Server peut communiquer avec le compte Stockage Azure pour restaurer les sauvegardes à partir du conteneur. Pour appliquer cette configuration spécifique, suivez les instructions de la section 1b – Configuration réseau de Stockage Blob Azure, en spécifiant le réseau virtuel de l’instance SQL cible au moment de compléter la fenêtre contextuelle « Ajouter un réseau virtuel existant ».

2b – Configuration réseau de Stockage Blob Azure (point de terminaison privé)

Si vous avez configuré un point de terminaison privé sur votre compte Stockage Azure, suivez les étapes décrites dans la section 2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé). Cependant, vous devez sélectionner le sous-réseau du point de terminaison privé, et pas seulement le sous-réseau cible SQL Server. Vérifiez que le point de terminaison privé est hébergé dans le même réseau virtuel que l’instance cible de SQL Server. Si ce n’est pas le cas, créez un autre point de terminaison privé en suivant le processus de la section Configuration du compte Stockage Azure.

Créer une instance de Database Migration Service

Dans Étape 6 : Azure Database Migration Service dans l’Assistant Migrer vers Azure SQL, créez une instance Azure Database Migration Service ou réutilisez une instance existante que vous avez créée précédemment.

Notes

Si vous avez précédemment créé une instance Database Migration Service à l’aide du Portail Azure, vous ne pouvez pas réutiliser l’instance dans l’Assistant de migration dans Azure Data Studio. Vous pouvez réutiliser une instance uniquement si vous l’avez créée à l’aide d’Azure Data Studio.

Utiliser une instance existante de Database Migration Service

Pour utiliser une instance existante de Database Migration Service :

  1. Dans Groupe de ressources, sélectionnez le groupe de ressources qui contient une instance existante de Database Migration Service.

  2. Dans Azure Database Migration Service, sélectionnez une instance existante de Database Migration Service qui se trouve dans le groupe de ressources sélectionné.

  3. Sélectionnez Suivant.

Créer une instance de Database Migration Service

Pour créer une instance de Database Migration Service :

  1. Dans Groupe de ressources, créez un groupe de ressources pour contenir une nouvelle instance de Database Migration Service.

  2. Sous Azure Database Migration Service, sélectionnez Créer.

  3. Dans Créer Azure Database Migration Service, entrez un nom pour votre instance de Database Migration Service, puis sélectionnez Créer.

  4. Sous Configurer le runtime d’intégration, effectuez les étapes suivantes :

    1. Sélectionnez le lien Télécharger et installer le runtime d’intégration pour ouvrir le lien de téléchargement dans un navigateur web. Téléchargez le runtime d’intégration, puis installez-le sur un ordinateur qui remplit les conditions préalables pour se connecter à l’instance SQL Server source.

      Une fois l’installation effectuée, le Gestionnaire de configuration de Microsoft Integration Runtime s’ouvre automatiquement pour débuter le processus d’inscription.

    2. Dans le tableau Clé d’authentification, copiez l’une des clés d’authentification fournies dans l’Assistant et collez-la dans Azure Data Studio. Si la clé d’authentification est valide, une icône de contrôle verte apparaît dans le Gestionnaire de configuration Integration Runtime. Une coche verte indique que vous pouvez vous Inscrire.

      Après avoir enregistré le runtime d’intégration auto-hébergé, fermez Microsoft Integration Runtime Configuration Manager.

      Notes

      Pour plus d’informations sur l’utilisation du runtime d’intégration auto-hébergé, consultez Créer et configurer un runtime d’intégration auto-hébergé.

  5. Dans Créer Azure Database Migration Service dans Azure Data Studio, sélectionnez Tester la connexion pour valider que l’instance de Database Migration Service nouvellement créée est connectée au runtime d’intégration auto-hébergé nouvellement enregistré.

  6. Revenez à l’Assistant Migration dans Azure Data Studio.

Démarrer la migration de base de données

Dans Étape 7 : Résumé de l’Assistant Migrer vers Azure SQL, passez en revue la configuration que vous avez créée, puis sélectionnez Démarrer la migration pour démarrer la migration de base de données.

Surveiller la migration de base de données

  1. Dans Azure Data Studio, dans le menu du serveur sous Général, sélectionnez Migration Azure SQL pour accéder au tableau de bord de vos migrations Azure SQL.

    Sous État de la migration de base de données, vous pouvez suivre les migrations en cours, terminées et ayant échoué (le cas échéant), ou vous pouvez afficher toutes les migrations de base de données.

    Capture d’écran du tableau de bord de migration de surveillance.

  2. Sélectionnez Migrations de base de données en cours pour afficher les migrations actives.

    Pour obtenir plus d’informations sur une migration spécifique, sélectionnez le nom de la base de données.

    Le volet des détails de la migration affiche les fichiers de sauvegarde et leur état correspondant :

    Statut Description
    Arrivé Le fichier de sauvegarde est arrivé à l’emplacement de sauvegarde de la source et a été validé.
    Chargement Le runtime d’intégration charge le fichier de sauvegarde vers le service Stockage Azure.
    Chargé Le fichier de sauvegarde a été chargé dans le stockage Azure.
    Restauration Le service restaure le fichier de sauvegarde sur SQL Server sur des machines virtuelles Azure.
    Restauré Le fichier de sauvegarde a été correctement restauré sur le Serveur SQL sur des machines virtuelles Azure.
    Canceled Le processus de migration a été annulé.
    Ignoré Le fichier de sauvegarde a été ignoré, car il n’appartient à aucune chaîne de sauvegarde de base de données valide.

Une fois toutes les sauvegardes de base de données restaurées sur l’instance SQL Server sur des machines virtuelles Azure, un basculement de migration automatique est lancé par Database Migration Service pour garantir que la base de données migrée est prête à être utilisée. L’état de la migration passe de En cours à Réussi.

Limites

-Si vous migrez une base de données unique, les sauvegardes de base de données doivent être placées dans une structure de fichiers plats à l’intérieur d’un dossier de base de données (contenant un dossier racine conteneur), et les dossiers ne peuvent pas être imbriqués, car cela n’est pas pris en charge.

-Lors de la migration de plusieurs bases de données à l’aide du même conteneur de Stockage Blob Azure, vous devez placer les fichiers de sauvegarde de différentes bases dans des dossiers distincts dans le conteneur.

-Le remplacement des bases de données existantes à l’aide de DMS dans votre SQL Server cible sur une machine virtuelle Azure n’est pas pris en charge.

-La configuration de la haute disponibilité et de la récupération d’urgence sur votre cible pour qu’elle corresponde à la topologie source n’est pas prise en charge par DMS.

Les objets serveur suivants ne sont pas pris en charge :

  • travaux de l'Agent SQL Server
  • Informations d'identification
  • Packages SSIS
  • Audit de serveur

-Vous ne pouvez pas utiliser un runtime d’intégration auto-hébergé existant créé à partir d’Azure Data Factory pour les migrations de base de données avec DMS. Au départ, le runtime d’intégration auto-hébergé doit être créé à l’aide de l’extension de migration Azure SQL dans Azure Data Studio, et il peut être réutilisé pour des migrations de base de données supplémentaires.

-Les machines Virtuelles avec SQL Server 2008 et les versions antérieures ne sont pas pris en charge pour la migration vers SQL Server sur des machines virtuelles Azure.

-Si vous utilisez une machine virtuelle avec SQL Server 2012 ou SQL Server 2014, vous devez stocker vos fichiers de sauvegarde de base de données source sur un conteneur Azure Storage Blob au lieu d’utiliser l’option de partage réseau. Stockez les fichiers de sauvegarde en tant qu’objets blob de pages, car les objets blob de blocs ne sont pris en charge que dans SQL 2016 et versions ultérieures.

-Vous devez vous assurer que l’extension IAAS SQL Agent dans la machine virtuelle Azure cible est en mode Complet au lieu du mode Léger.

-La migration vers Azure SQL VM à l'aide de DMS utilise l'agent SQL IaaS en interne. Et l’extension d’agent IaaS SQL prend uniquement en charge la gestion de l’instance de serveur par défaut ou de l’instance nommée unique.

-Vous pouvez migrer un maximum de 100 bases de données vers la même machine virtuelle Azure SQL Server que la cible en utilisant une ou plusieurs migrations simultanément. De plus, une fois qu’une ou plusieurs migrations de 100 bases de données est terminée, attendez au moins 30 minutes avant de commencer une nouvelle migration vers la même machine virtuelle Azure SQL Server que la cible. De plus, chaque opération de migration (démarrer la migration, basculement) pour chaque base de données prend quelques minutes de manière séquentielle. Par exemple, la migration de 100 bases de données peut prendre environ 200 (2 x 100) minutes pour créer les files d’attente de migration et environ 100 (1 x 100) minutes pour transférer les 100 bases de données (sans compter le temps de sauvegarde et de restauration). Par conséquent, la migration devient plus lente à mesure que le nombre de bases de données augmente. Vous devez soit planifier une fenêtre de migration plus longue à l’avance sur la base de tests de migration rigoureux, soit partitionner un grand nombre de bases de données en lots lors de leur migration vers une machine virtuelle Azure SQL Server.

-Outre la configuration du réseau/pare-feu de votre compte de stockage Azure pour permettre à votre machine virtuelle d’accéder aux fichiers de sauvegarde. Vous devez également configurer la mise en réseau/le pare-feu de votre SQL Server sur une machine virtuelle Azure pour autoriser la connexion sortante à votre compte de stockage.

-Vous devez conserver la SQL Server cible sur la machine virtuelle Azure sous tension pendant que la migration SQL est en cours. En outre, lors de la création d’une migration, basculez ou annulez la migration.

Messages d’erreur possibles

Échec de la connexion pour l’utilisateur « NT Service\SQLIaaSExtensionQuery »

Erreur : Login failed for user 'NT Service\SQLIaaSExtensionQuery

Raison : SQL Server instance est en mode mono-utilisateur. L’une des raisons possibles est que la SQL Server cible sur une machine virtuelle Azure est en mode de mise à niveau.

Solution : attendez que le SQL Server cible sur la machine virtuelle Azure quitte le mode de mise à niveau et recommencez la migration.

Échec de la création d’une tâche de restauration

Erreur : Ext_RestoreSettingsError, message: Failed to create restore job.;Cannot create file 'F:\data\XXX.mdf' because it already exists.

Solution : connectez-vous au SQL Server cible sur la machine virtuelle Azure et supprimez le fichier XXX.mdf. Ensuite, redémarrez la migration.

Contenu connexe