Performances de migration : Base de référence des performances de SQL Server vers Azure SQL Managed Instance

  • Article

S’applique à : Azure SQL Managed Instance

Créez une ligne de base des performances pour comparer les performances de votre charge de travail s’exécutant sur SQL Managed Instance avec votre charge de travail d’origine s’exécutant sur SQL Server.

Créer une ligne de base

Dans l’idéal, les performances sont similaires ou meilleures après la migration. Il est donc important de mesurer et d’enregistrer les valeurs de performances de la ligne de base sur la source, puis de les comparer à l’environnement cible. Une ligne de base des performances est un ensemble de paramètres qui définissent votre charge de travail moyenne sur votre source.

Sélectionnez un ensemble de requêtes qui sont importantes pour la charge de travail de votre entreprise et représentatives de celle-ci. Mesurez et documentez la durée minimale/moyenne/maximale et l’utilisation de l’UC pour ces requêtes, ainsi que les métriques de performances sur le serveur source, telles que l’utilisation moyenne/maximale de l’UC, la latence d’E/S de disque moyenne/maximum, le débit, l’IOPS, l’espérance de vie moyenne/maximale d’une page et la taille moyenne/maximale de tempdb.

Les ressources suivantes peuvent vous aider à définir une ligne de base des performances :

  • Monitoring de l’utilisation du processeur
  • Analysez l’utilisation de la mémoire et déterminez la quantité de mémoire utilisée par différents composants, tels que le pool de mémoires tampons, le cache du plan, le pool de stockage en colonne, l’OLTP en mémoire, etc. Par ailleurs, vous devez rechercher les valeurs moyennes et maximales du compteur de performance de la mémoire Espérance de vie d’une page.
  • Analysez l’utilisation des E/S disque sur l’instance SQL Server source à l’aide de la vue sys.dm_io_virtual_file_stats ou des compteurs de performance.
  • Analysez les performances des requêtes et des charges de travail en examinant les vues de gestion dynamique (ou Magasin des requêtes si vous effectuez une migration à partir de SQL Server 2016 et versions ultérieures). Identifiez la durée moyenne et l’utilisation de l’UC des requêtes les plus importantes dans votre charge de travail.

Tout problème de performances sur l’instance SQL Server source doit être résolu avant la migration. Migrer des problèmes connus sur un nouveau système peut provoquer des résultats inattendus et invalider toute comparaison de performance.

Comparer les performances

Une fois que vous avez défini une base de référence, comparez les performances de charges de travail similaires sur l’instance SQL Managed Instance cible. Pour des raisons de précision, il est important que l’environnement SQL Managed Instance soit comparable à l’environnement SQL Server autant que possible.

Il existe des différences dans l’infrastructure SQL Managed Instance qui rendent improbable la correspondance exacte des performances. Certaines requêtes peuvent s’exécuter plus rapidement que prévu, tandis que d’autres peuvent être plus lentes. L’objectif de cette comparaison est de vérifier que les performances de charge de travail dans l’instance gérée correspondent à celles de SQL Server (en moyenne) et d’identifier les requêtes critiques dont les performances ne correspondent pas à vos performances d’origine.

La comparaison des performances est susceptible d’entraîner les résultats suivants :

  • Les performances de charge de travail sur l’instance gérée s’alignent sur celles enregistrées sur votre serveur SQL source ou leur sont supérieures. En l’occurrence, vous confirmez que la migration est une réussite.

  • La majorité des paramètres de performance et les requêtes dans la charge de travail fonctionnent comme prévu, avec quelques exceptions entraînant une dégradation des performances. Dans ce cas, identifiez les écarts et leur degré d’importance. S’il existe quelques requêtes importantes accusant une détérioration des performances, cherchez à savoir si les plans SQL sous-jacents ont été modifiés ou si les requêtes ont atteint les limites des ressources. Vous pouvez atténuer ce problème en appliquant quelques conseils aux requêtes critiques (par exemple, modifier le niveau de compatibilité, l’estimateur de cardinalité héritée) soit directement, soit à l’aide des repères de plan. Vérifiez que les statistiques et les index sont à jour et équivalents dans les deux environnements.

  • La plupart des requêtes sont plus lentes sur l’instance gérée par rapport à votre instance SQL source. Dans ce cas, essayez d’identifier les causes racines de cette différence, comme l’atteinte de certaines limites de ressources : limites des E/S, de mémoire ou du débit du journal d’instance par exemple. Si aucune limite de ressources n’est à l’origine de cette différence, essayez de changer le niveau de compatibilité de la base de données ou de changer des paramètres de base de données, comme l’estimation de la cardinalité existante, puis réexécutez le test. Examinez les recommandations fournies par les vues de l’instance gérée ou de Magasin des requêtes pour identifier les requêtes dont les performances ont diminué.

SQL Managed Instance dispose d’une fonction intégrée de correction automatique du plan qui est activée par défaut. Cette fonctionnalité garantit que les requêtes qui fonctionnaient correctement par le passé ne se dégraderont pas à l’avenir. Si cette fonctionnalité n’est pas activée, exécutez la charge de travail avec les anciens paramètres afin que SQL Managed Instance puisse connaître la ligne de base des performances. Ensuite, activez la fonctionnalité et réexécutez la charge de travail avec les nouveaux paramètres.

Modifiez les paramètres de votre test ou effectuez une mise à niveau vers des niveaux de service supérieurs afin d’atteindre la configuration optimale pour les performances de charge de travail qui répondent à vos besoins.

Superviser les performances

SQL Managed Instance fournit des outils avancés de surveillance et de résolution des problèmes, et vous devez les utiliser pour analyser les performances de votre instance. Voici quelques-unes des principales métriques pour analyser :

  • L’utilisation de l’UC sur l’instance pour déterminer si le nombre de vCores que vous avez approvisionnés convient pour votre charge de travail.
  • L’espérance de vie d’une page sur votre instance managée pour déterminer si vous avez besoin de mémoire supplémentaire.
  • Des statistiques telles que INSTANCE_LOG_GOVERNOR  ou  PAGEIOLATCH qui identifient les problèmes d’E/S de stockage, plus particulièrement au niveau Usage général, où vous devrez peut-être pré-allouer des fichiers pour obtenir de meilleures performances d’E/S.

À propos de l’installation

Lorsque vous comparez les performances, tenez compte des points suivants :

  • Les paramètres correspondent entre la source et la cible. Vérifiez que les différents paramètres de l’instance, de la base de données et de tempdb sont équivalents entre les deux environnements. Les différences de configuration, de niveaux de compatibilité, de paramètres de chiffrement, d’indicateurs de trace, etc., peuvent toutes fausser les performances.

  • Le stockage est configuré conformément aux meilleures pratiques. Par exemple, pour Usage général, vous devrez peut-être pré-allouer la taille des fichiers pour améliorer les performances.

  • Il existe des différences d’environnement clés pouvant entraîner des écarts de performances entre l’instance gérée et SQL Server. Identifiez les risques pertinents pour votre environnement qui pourraient avoir une incidence sur les performances.

  • Le magasin des requêtes et le réglage automatique doivent être activés sur votre instance SQL Managed Instance, car ils vous aident à mesurer les performances de la charge de travail et à atténuer automatiquement les éventuels problèmes de performances.

Contenu connexe