Partage via

Bonnes pratiques pour l’exécution de l’Assistant Migration de données

  • Article

Important

L’Assistant Migration de données (DMA) est déconseillé. Pour les options de migration des données de SQL Server vers Azure SQL, consultez Options de migration pour SQL Server vers Azure SQL.

Cet article fournit des informations sur les meilleures pratiques pour l’installation, l’évaluation et la migration.

Installation

N’installez pas et n’exécutez pas l’Assistant Migration de données directement sur l’ordinateur hôte SQL Server.

Évaluation

  • Exécutez les évaluations de bases de données de production pendant les heures creuses.
  • Exécutez les évaluations Problèmes de compatibilité et Recommandations de fonctionnalités séparément afin de réduire la durée de ces évaluations.

Migration

  • Effectuez la migration des serveurs pendant les heures creuses.

  • Lors d’une migration de base de données, fournissez un emplacement de partage unique accessible par le serveur source et par le serveur cible, et évitez les opérations de copie si possible. Les opérations de copie peuvent provoquer des retards si le fichier de sauvegarde est volumineux. Les opérations de copie augmentent également le risque d’échec de la migration, car elles impliquent une étape supplémentaire. Lorsqu’un emplacement unique est fourni, l’Assistant Migration de données ignore l’opération de copie.

    Par ailleurs, afin d’éviter les échecs de migration, veillez à fournir les autorisations appropriées pour le dossier partagé. Les autorisations appropriées sont spécifiées dans l’outil. Si vous exécutez une instance SQL Server avec des informations d’identification de service réseau, attribuez les autorisations appropriées sur le dossier partagé au compte d’ordinateur de l’instance SQL Server.

  • Activez l’option Chiffrer la connexion lorsque vous vous connectez aux serveurs source et cible. L’utilisation du chiffrement TLS accroît la sécurité des données transmises sur les réseaux entre l’Assistant Migration de données et l’instance SQL Server, ce qui est particulièrement utile lors d’une migration de connexions SQL. Si le chiffrement TLS n’est pas utilisé et que le réseau est compromis par une personne malveillante, les connexions SQL en cours de migration peuvent être interceptées et/ou modifiées à la volée par l’attaquant.

    Toutefois, si tous les accès impliquent une configuration intranet sécurisée, le chiffrement peut s'avérer superflu. L’activation du chiffrement ralentit les performances, en raison de la surcharge supplémentaire requise pour chiffrer et déchiffrer les paquets. Pour plus d’informations, veuillez vous reporter à Chiffrement des connexions à SQL Server.

  • Vérifiez les contraintes non approuvées sur la base de données source et la base de données cible avant de migrer des données. Après la migration, analysez à nouveau la base de données cible pour voir si des contraintes sont devenues non approuvées dans le cadre du déplacement des données. Corrigez les contraintes non approuvées si nécessaire. Laisser les contraintes non approuvées peut entraîner des plans d’exécution médiocres et affecter les performances.