Cet article répertorie les questions fréquemment posées sur l’utilisation d’Azure Database Migration Service, ainsi que les réponses associées.
Vue d’ensemble
Présentation d’Azure Database Migration Service
Azure Database Migration Service est un service complètement managé conçu pour permettre la migration homogène de plusieurs sources de base de données vers des plateformes de données Azure avec un temps d’arrêt minimal. Le service est actuellement en disponibilité générale, les efforts de développement en cours étant axés sur les aspects suivants :
- Fiabilité et performances.
- Ajout itératif de paires source/cible.
- Investissement continu dans les migrations sans problèmes.
Quelles sont les paires sources/cibles actuellement prises en charge par Azure Database Migration Service ?
Le service prend actuellement en charge diverses paires source/cible ou scénarios de migration. Pour obtenir la liste complète des états de chaque scénario de migration disponible, consultez l’article État des scénarios de migration pris en charge par Azure Database Migration Service.
Quelles sont les versions de SQL Server prises en charge comme sources par Azure Database Migration Service ?
Lors de la migration depuis SQL Server, les sources prises en charge pour Azure Database Migration Service sont SQL Server 2008 et versions ultérieures. Si vous utilisez Azure Data Studio avec l'extension SQL Migration, les sources prises en charge sont SQL Server 2008 à SQL Server 2022.
Lorsque vous utilisez Azure Database Migration Service, quelle est la différence entre une migration hors ligne et une migration en ligne ?
Vous pouvez utiliser Azure Database Migration Service pour effectuer des migrations en ligne et des migrations hors connexion. Dans le cas d’une migration hors connexion, le temps d’arrêt de l’application commence quand la migration commence. Dans le cas d’une migration en ligne, le temps d’arrêt est limité à la durée du basculement à la fin de la migration. Nous vous suggérons de tester une migration hors connexion pour déterminer si le temps d’arrêt est acceptable ; dans le cas contraire, privilégiez une migration en ligne.
Remarque
L’utilisation d’Azure Database Migration Service pour effectuer une migration en ligne nécessite la création d’une instance basée sur le niveau tarifaire Premium. Pour plus d’informations, consultez la page de tarification du service Azure Database Migration Service.
Comment Azure Database Migration Service se distingue des autres outils de migration de bases de données Microsoft, comme l’Assistant Migration de bases de données ou l’Assistant Migration SQL Server ?
Azure Database Migration Service est la méthode recommandée pour la migration de bases de données à grande échelle vers Microsoft Azure. Pour plus d'informations sur la comparaison d'Azure Database Migration Service avec d'autres outils de migration de bases de données Microsoft et pour obtenir des suggestions sur l'utilisation du service dans divers scénarios, consultez Différenciation des outils et services de migration de bases de données Microsoft.
Comment Azure Database Migration Service se distingue du produit Azure Migrate ?
Azure Migrate facilite la migration de machines virtuelles locales vers Azure IaaS. Le service évalue la pertinence de la migration et le dimensionnement en fonction des performances, et fournit des estimations de coût pour l’exécution de vos machines locales dans Azure. Azure Migrate est particulièrement utile pour les migrations de type lift-and-shift des charges de travail basées sur des machines virtuelles locales vers des machines virtuelles IaaS Azure. Toutefois, contrairement à Azure Database Migration Service, Azure Migrate n’est pas une offre de service de migration de bases de données spécialisée pour les plateformes de bases de données relationnelles Azure PaaS telles qu’Azure SQL Database ou Azure SQL Managed Instance.
Database Migration Service stocke-t-il les données client ?
Non. Le service de migration de base de données ne stocke pas les données client.
Comment puis-je m'assurer que DMS a migré toutes les données de la base de données source vers Azure SQL Targets ?
Pour les cibles Azure SQL VM et Azure SQL MI, DMS utilise la migration physique, c'est-à-dire l'utilisation de la sauvegarde et de la restauration. Comme décrit ci-dessous, le mode de migration choisi détermine la cohérence des données entre la source et la cible.
Migration hors connexion : lors de la migration hors connexion vers une machine virtuelle Azure SQL et des cibles Azure SQL MI, le temps d’arrêt de l’application commence lorsque la migration démarre. DMS restaurera tous les fichiers de sauvegarde sur la cible, tant que le ou les derniers fichiers de sauvegarde provenant de la source ont été transférés vers le stockage réseau SMB ou vers un conteneur d’objets blob Azure (conformément à la configuration de migration). Si la sauvegarde est effectuée avec l’option CHECKSUM, l’opération de restauration DMS effectue automatiquement la validation. En l’absence de CHECKSUM, l’intégrité de la sauvegarde est vérifiée explicitement avant la restauration. Cela garantit que le fichier de restauration est identique au fichier de sauvegarde et possède donc les mêmes données. Vous pouvez vérifier tous les fichiers de sauvegarde, y compris le nom du dernier fichier de sauvegarde de la source, avec le fichier de sauvegarde appliqué/restauré sur la cible affiché sur la page de surveillance de la migration DMS, et valider leur somme de contrôle respective.
Migration en ligne : pendant la migration en ligne vers une machine virtuelle Azure SQL et des cibles Azure SQL MI, les temps d’arrêt commencent une fois que vous lancez le basculement de la migration, ainsi que l’arrêt de l’application. DMS restaurera tous les fichiers de sauvegarde sur la cible, tant que le ou les derniers fichiers de sauvegarde provenant de la source ont été transférés vers le stockage réseau SMB ou vers un conteneur d’objets blob Azure (conformément à la configuration de migration). Une fois que vous avez appuyé sur le bouton basculement, DMS affiche le nombre de fichiers de sauvegarde en attente (le cas échéant) présents sur le stockage réseau SMB ou le conteneur d’objets blob Azure et qui n’ont pas encore été appliqués/restaurés sur la cible. Si la sauvegarde est effectuée avec l’option CHECKSUM, l’opération de restauration DMS effectue automatiquement la validation. En l’absence de CHECKSUM, l’intégrité de la sauvegarde est vérifiée explicitement avant la restauration. Cela garantit que le fichier de restauration est identique au fichier de sauvegarde et possède donc les mêmes données. Vous pouvez vérifier tous les fichiers de sauvegarde, y compris le nom du dernier fichier de sauvegarde de la source, avec le fichier de sauvegarde appliqué/restauré sur la cible affiché sur la page de surveillance de la migration DMS, et valider leur somme de contrôle respective.
Pour les cibles Azure SQL Database, DMS effectue une migration logique dans le cas d'Azure SQL Database, c'est-à-dire qu'il copie les données des tables de la base de données SQL source et les écrit dans les tables de la base de données Azure SQL Database cible. Comme DMS prend uniquement en charge la migration hors connexion vers Azure SQL Database, le temps d’arrêt de l’application démarre au démarrage de la migration. Vous pouvez surveiller et valider le nombre de lignes lues (à partir de la table de base de données source) et copiées (écrites dans la table Azure SQL DB cible) à partir de la page de surveillance de la migration. Comme confirmation supplémentaire, vous pouvez exécuter le TSQL ci-dessous pour obtenir la somme de contrôle à la fois dans les bases de données source et de destination, et valider la source et restaurer les données identiques.
"SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
Remarque : Si aucune application n’est écrite dans la base de données source ou cible. Vous pouvez également tirer parti d’outils tels que l’outil de comparaison de bases de données pour la comparaison des données.
Sécurité
Quels services sont créés et consommés lorsqu’une instance de DMS (classique) est créée et exécutée ?
La liste suivante contient les ressources Azure qui peuvent être créées en arrière-plan pour effectuer une migration de données. Les services utilisés peuvent varier selon le scénario de migration.
- Azure Monitor
- Microsoft Azure
- Stockage Azure
- Azure Service Bus
- Azure Data Factory.
Comment les métadonnées et les données client sont-elles extraites de la source et écrites dans la cible ?
En interne, DMS gère un magasin de métadonnées qui comprend des informations sur les emplacements réseau, les informations d'identification, les fichiers de sauvegarde et les tâches terminées. Les informations d'identification et les champs sélectionnés, comme les clés de compte, sont cryptés. Les données, comme les noms de tables pouvant être inclus dans la télémétrie, sont hachées. Les noms d'utilisateur peuvent apparaître en texte brut dans les journaux de service, mais les mots de passe ne le seront jamais. La télémétrie est cloisonnée par région, régie par des politiques de rétention et disponible uniquement pour le personnel autorisé de Microsoft à des fins de dépannage valides. Les noms de ressources Azure, comme les noms de serveurs et de bases de données, suivent les règles des ressources Azure.
DMS (Classic) utilise les rubriques Azure Service Bus pour faciliter la communication entre les couches de calcul. Les rubriques Azure Service Bus sont uniques à chaque instance DMS et toutes les données personnelles sont chiffrées.
Azure SQL Managed Instance et SQL Server sur les machines virtuelles Azure
Le schéma et les données sont migrés à l'aide de la sauvegarde et de la restauration. Les clients ont le choix de restaurer à partir d'un partage réseau ou directement à partir d'un conteneur de stockage. Un fichier contenant des données de performances Windows peut être utilisé pour fournir des suggestions facultatives (mais fortement recommandées) sur le dimensionnement de la charge de travail.
Azure SQL Database
Les migrations vers Azure SQL Database s'effectuent en deux étapes. La première étape est une migration de schéma. DMS (Classic) utilise SQL Management Objects (SMO) pour la migration de schéma. La deuxième étape est la migration proprement dite des données. SqlBulkCopy est utilisé pour effectuer la migration des données. DMS ne prend pas en charge la migration de schéma. Les données sont migrées à l'aide d'Azure Data Factory. Facultativement mais fortement recommandé, un fichier contenant des données de performances Windows peut être utilisé pour fournir des suggestions sur le dimensionnement de la charge de travail.
Base de données Azure pour PostgreSQL
Dans ce scénario, l'utilisateur final extrait les métadonnées, en l'occurrence le schéma, à l'aide des utilitaires de ligne de commande pg_dump
et pg_restore
. Lors de la configuration de la capture des données modifiées pour PostgreSQL, DMS utilise en interne pg_dump
et pg_restore
pour effectuer l'amorçage initial pour CDC. Les données sont stockées dans un stockage temporaire chiffré qui n'est accessible qu'à votre instance DMS. Un fichier contenant des données de performances Windows peut être utilisé pour fournir des suggestions facultatives (mais fortement recommandées) sur le dimensionnement de la charge de travail.
Azure Database pour MySQL
Dans ce scénario, l'extraction et la migration du schéma sont effectuées par DMS (Classic) à l'aide de mysql-net/MySqlConnector. Dans la mesure du possible, la réplication des journaux binaires MySQL est utilisée pour répliquer à la fois les modifications de données et de schéma. Le code personnalisé est utilisé pour synchroniser les modifications là où la réplication binlog ne peut pas être utilisée.
MongoDB vers Azure Cosmos DB
DMS extrait et insère les données d'un MongoDB dans Cosmos DB. Il offre également la possibilité d'extraire les données d'un dump BSON ou JSON.
Pour les dumps BSON, DMS utilise les données au format bsondump
dans le même dossier au sein d'un conteneur blob. DMS recherche uniquement les fichiers de métadonnées utilisant le format collection.metadata.json
.
Pour les dumps JSON, DMS lira les fichiers dans les dossiers du conteneur blob nommés d'après les bases de données contenant. Dans chaque dossier de base de données, DMS utilise uniquement les fichiers de données placés dans le sous-dossier data
. DMS examine uniquement les fichiers placés dans le sous-dossier metadata
et nommés en utilisant le format collection.json
des métadonnées.
Oracle vers Azure SQL Base de données
Dans ce scénario, le rapport AWR ou un fichier perfmon
Windows est utilisé pour fournir des suggestions facultatives (mais fortement recommandées) sur le dimensionnement de la charge de travail. L'utilisateur effectuant la migration utilise le Kit d'outils de conversion du schéma de la base de données pour effectuer une migration de schéma afin de préparer la base de données cible.
Oracle vers Azure Database pour PostgreSQL
Tout comme Oracle vers Azure SQL Database, dans ce scénario, le rapport AWR ou un fichier perfmon
Windows est utilisé pour fournir des suggestions facultatives (mais fortement recommandées) sur le dimensionnement de la charge de travail. La bibliothèque ora2pg
est utilisée pour extraire le schéma et migrer les données manuellement par l'utilisateur effectuant la migration.
Des points de terminaison publics sont-ils utilisés ?
DMS (Classic) s'appuie sur la configuration réseau du client. Si la source de migration utilise des points de terminaison privés, nous utilisons des points de terminaison privés, qui constituent la configuration préférée. Nous utilisons des points de terminaison publics s'ils constituent la seule option.
DMS utilise largement ADF en coulisses pour la planification et la coordination des déplacement des données. De plus, le runtime d'intégration auto-hébergé n'est pas différent de celui que vous utilisez probablement déjà pour vos propres pipelines ADF. Pour plus d'informations sur les problèmes de pare-feu et de serveur proxy, consultez Créer et configurer un runtime d'intégration auto-hébergé.
Toutes les données en transit et au repos sont-elles cryptées ?
Toutes les données clients sont cryptées au repos. Certaines métadonnées, notamment les noms de serveurs logiques et les noms de bases de données, ainsi que l'état et la progression de la migration, apparaissent dans les journaux de service qui ne sont pas chiffrés.
Toutes les données en transit sont protégées par défaut avec le cryptage TLS 1.2. Les anciens clients nécessitant des versions antérieures de TLS doivent avoir les versions requises activées sur la page du portail DMS (classique). Pour DMS, la machine sur laquelle le runtime d'intégration auto-hébergé est installé peut être configurée pour autoriser les paramètres TLS requis pour s'adapter aux clients existants. Pour plus d'informations sur la configuration TLS pour SQL Server, consultez KB3135244-Support TLS 1.2 pour Microsoft SQL Server.
Tous les services Azure qui sous-tendent DMS et DMS (Classic) utilisent-ils des points de terminaison privés ?
Dans la mesure du possible, des points de terminaison privés sont utilisés. Si les points de terminaison privés ne sont pas une option, les points de terminaison publics sont utilisés pour la communication entre les couches de service. Quel que soit le type de point de terminaison, toutes les ressources sont dédiées/portées à l'instance particulière de DMS et sécurisées avec des informations d'identification uniques.
Tous les services Azure qui sous-tendent DMS et DMS (Classic) utilisent-ils CMK pour les données au repos ?
Nous ne prenons pas en charge les clés gérées par le client pour le chiffrement des données au sein de notre plan de données ou de notre plan de contrôle. Cependant, toutes les données clients sont chiffrées au repos à l'aide de clés gérées par le service. Certaines métadonnées, notamment les noms de serveurs logiques et les noms de bases de données, ainsi que l'état et la progression de la migration, apparaissent dans les journaux de service sous forme non chiffrée.
Quel type de cryptage est utilisé pour les données en transit ?
Toutes les données en transit sont chiffrées par défaut avec le chiffrement TLS 1.2. La page du portail DMS (Classic) permet d'utiliser des versions plus anciennes de TLS pour les clients existants. Pour DMS, la machine sur laquelle le runtime d'intégration auto-hébergé est installé peut être configurée pour permettre la gestion des paramètres TLS afin de s'adapter aux clients existants. Pour plus d'informations sur la configuration TLS pour SQL Server, consultez KB3135244-Support TLS 1.2 pour Microsoft SQL Server.
Existe-t-il des données qui ne sont pas protégées par CMK, et quel type de données ? Par exemple, les métadonnées, les journaux, etc.
Nous n'exposons pas la possibilité de chiffrer les données sur notre plan de contrôle ou de données avec les clés gérées par le client. Toutes les données client sont supprimées au moment où l'instance DMS est supprimée, à l'exception des journaux de service. Les journaux de service DMS ne sont conservés que pendant 30 jours.
Comment DMS prend-il en charge les clés gérées par le client (CMK) ?
TDE
DMS prend en charge la migration des clés gérées par le client (CMK) vers Azure SQL pour Transparent Database Encryption (TDE). Pour obtenir des instructions étape par étape pour migrer vos clés TDE, consultez Tutoriel : Migrer des bases de données compatibles TDE (préversion) vers Azure SQL dans Azure Data Studio.
Cryptage cellulaire
Le chiffrement au niveau des cellules est géré au niveau du schéma. Les outils de migration de schéma migrent tous les objets de schéma, y compris les fonctions et procédures stockées nécessaires à la mise en œuvre du chiffrement au niveau des cellules.
Always Encrypted
DMS ne prend actuellement pas en charge la migration d’Always Encrypted via des scénarios dans lesquels des lignes de données individuelles sont migrées entre la source et la cible. Les colonnes chiffrées via Always Encrypted sont migrées comme prévu dans les scénarios qui utilisent la sauvegarde/restauration, comme le déplacement vers une machine virtuelle Azure SQL ou une instance Azure SQL Managed à partir d'une instance SQL Server existante.
DMS garantit-il que Microsoft Azure Access Control Service avec le contrôle d'accès géolocalisé ?
Nous n’implémentons aucun contrôle d’accès basé sur l’emplacement au-delà de ce qui est déjà disponible dans Azure. Toutes les données associées à une instance DMS résident dans la même région que la ressource DMS.
Comment DMS garantit-il que les données d’un environnement ne peuvent pas être déplacées vers un autre à l’aide de DMS ?
Nos services sont utilisés dans divers environnements avec différents contrôles internes et processus commerciaux. DMS déplace les données depuis et vers n'importe quel endroit auquel le compte qu'il utilise a accès. Il est de la responsabilité de l'utilisateur de comprendre les autorisations et les contrôles internes de l'environnement dans lequel il travaille. Il est particulièrement important de garantir que le compte que DMS utilise pour se connecter à la source a accès à toutes les données destinées à être migrées depuis la source.
Comment l’injection VNET dans DMS (Classic) est-elle utilisée ? Est-ce que cela donne à Microsoft accès à mon réseau ?
L’injection VNET est l’action d’ajouter une ressource Azure qui réside dans le locataire Microsoft à un sous-réseau dans un réseau virtuel sous le locataire client. Cette approche a été adoptée avec DMS pour nous permettre de gérer le calcul au nom du client, tout en conservant l'accès aux ressources du client. Étant donné que le réseau est sous abonnement client, Microsoft ne peut pas gérer la machine virtuelle au-delà de l'émission de commandes Démarrer, Arrêter, Supprimer ou Déployer. Toutes les autres actions de gestion nécessitant un accès à la VM nécessitent une requête d’assistance et une approbation initiées par le client.
Programme d’installation
Quels sont les prérequis pour utiliser Azure Database Migration Service ?
Il existe plusieurs prérequis pour garantir qu’Azure Database Migration Service s’exécute correctement lors de la migration de bases de données. Certaines des conditions préalables s’appliquent à tous les scénarios (paires source-cible) pris en charge par le service, tandis que d’autres sont propres à un scénario spécifique.
Les conditions préalables associées à Azure Database Migration Service communes à tous les scénarios de migration pris en charge incluent le besoin de :
- Créez un Réseau virtuel Microsoft Azure pour Azure Database Migration Service à l’aide du modèle de déploiement Azure Resource Manager, qui fournit une connectivité site à site à vos serveurs sources locaux via ExpressRoute ou un VPN.
- Vérifiez que vos règles de groupe de sécurité réseau du réseau virtuel ne bloquent pas le port 443 pour ServiceTags de ServiceBus, Stockage et Azure Monitor. Pour plus d’informations sur le filtrage du trafic de groupe de sécurité réseau de réseau virtuel, consultez l’article Filtrer le trafic avec les groupes de sécurité réseau.
- Lorsque vous utilisez une appliance de pare-feu devant vos bases de données sources, vous devrez peut-être ajouter des règles de pare-feu pour permettre à Azure Database Migration Service d’accéder aux bases de données sources pour la migration.
Pour obtenir la liste de tous les prérequis permettant des scénarios de migration spécifiques à l’aide d’Azure Database Migration Service, consultez les tutoriels associés dans la documentation d’Azure Database Migration Service.
Comment trouver l’adresse IP d’Azure Database Migration Service afin de créer une liste d’autorisation pour les règles de pare-feu utilisées pour accéder à ma base de données source pour la migration ?
Vous devrez peut-être ajouter des règles de pare-feu autorisant Azure Database Migration Service à accéder à votre base de données source pour la migration. L’adresse IP du service est dynamique, mais si vous utilisez ExpressRoute, cette adresse est attribuée en privé par votre réseau d’entreprise. Le moyen le plus simple d’identifier l’adresse IP appropriée est de regarder dans le même groupe de ressources que votre ressource Azure Database Migration Service provisionnée et y rechercher l’interface réseau associée. Habituellement, le nom de la ressource d'interface réseau commence par le préfixe NIC et est suivi d'une séquence de caractères et de chiffres uniques, par exemple, `NIC-jj6tnztnmarpsskr82rbndyp``. En sélectionnant cette ressource d’interface réseau, vous pouvez voir l’adresse IP qui doit être incluse dans la liste d’autorisation sur la page de présentation des ressources du portail Azure.
Par ailleurs, vous devez peut-être inclure la source du port que SQL Server écoute sur la liste d’autorisation. Par défaut, il s’agit du port 1433, mais le SQL Server source peut être configuré pour écouter d’autres ports également. Dans ce cas, vous devez aussi inclure ces ports sur la liste d’autorisation. Vous pouvez déterminer le port écouté par SQL Server à l’aide de la requête de vue de gestion dynamique :
SELECT DISTINCT
local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;
Vous pouvez également déterminer le port écouté par SQL Server en interrogeant le journal des erreurs SQL Server :
USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO
Comment configurer un Réseau virtuel Microsoft Azure ?
Même si plusieurs didacticiels Microsoft peuvent vous présenter le processus de configuration d’un réseau virtuel, la documentation officielle est disponible dans l’article Réseau virtuel Azure.
Usage
Quel est le récapitulatif des étapes nécessaires pour utiliser Azure Database Migration Service afin de migrer une base de données ?
Lors d’une migration de base de données classique et simple, vous effectuez les opérations suivantes :
- Créer des bases de données cibles.
- Évaluer vos bases de données sources.
- Pour les migrations homogènes, évaluez vos bases de données existantes avec DMA.
- Pour les migrations hétérogènes (à partir de sources concurrentes), évaluez vos bases de données existantes avec SSMA. Vous utilisez également SSMA pour convertir des objets de base de données et migrer le schéma vers votre plateforme cible.
- Créer une instance d’Azure Database Migration Service.
- Créer un projet de migration spécifiant la ou les bases de données sources, la ou les bases de données cibles, et les tables à migrer.
- Démarrer le chargement complet.
- Choisir la validation ultérieure.
- Effectuer un basculement manuel de votre environnement de production vers la nouvelle base de données cloud.
Résolution des problèmes et optimisation
Je mets en place un projet de migration dans DMS et je rencontre des difficultés à me connecter à ma base de données source. Que dois-je faire ?
Si vous avez des difficultés à vous connecter à votre système de base de données source quand vous travaillez sur la migration, créez une machine virtuelle dans le même sous-réseau de réseau virtuel que celui avec lequel vous avez configuré votre instance DMS. Dans la machine virtuelle, vous devez être en mesure d’effectuer un test de connexion, par exemple en utilisant un fichier UDL pour tester une connexion à SQL Server ou en téléchargeant Robo 3T pour tester les connexions MongoDB. Si le test de connexion réussit, vous ne devriez pas avoir de problème de connexion à votre base de données source. Si le test de connexion échoue, contactez votre administrateur réseau.
Pourquoi Azure Database Migration Service est-il arrêté ou indisponible ?
Si l’utilisateur arrête explicitement Azure Database Migration Service (DMS) ou si le service est inactif pendant 24 heures, le service est dans un état arrêté ou automatiquement mis en pause. Dans chaque cas, le service est indisponible et dans un état arrêté. Pour reprendre les migrations actives, redémarrez le service.
Existe-t-il des recommandations pour optimiser les performances d’Azure Database Migration Service ?
Vous pouvez effectuer quelques opérations pour accélérer la migration de votre base de données à l’aide du service :
Pour DMS (classique)-
- Utilisez le niveau tarifaire Usage général avec plusieurs processeurs lorsque vous créez votre instance de service pour permettre au service de tirer parti de multiples processeurs virtuels pour la parallélisation et le transfert plus rapide des données.
- Faites évoluer temporairement votre instance cible Azure SQL Database vers la référence SKU de niveau Premium pendant l’opération de migration des données afin de minimiser la limitation d’Azure SQL Database qui peut affecter les activités de transfert de données lors de l’utilisation de références SKU de niveau inférieur.
Pour DMS-
- Si vous copiez des sauvegardes du partage de fichiers local vers le stockage Blob Azure OU lors de la migration vers la base de données SQL Azure cible, DMS utilise le nœud SHIR comme calcul. Veillez donc à surveiller l’utilisation des ressources de ce nœud SHIR.
- Faites évoluer temporairement votre instance cible Azure SQL Database vers la référence SKU de niveau Premium pendant l’opération de migration des données afin de minimiser la limitation du disque Azure SQL Database qui peut affecter les activités de transfert de données lors de l’utilisation de références SKU de niveau inférieur.
- Pour plus d’informations, consultez le blog.