Partage via

Certification de compatibilité

  • Article

S’applique à : SQL Server Azure SQL Database Azure SQL Managed Instance

La certification de compatibilité permet aux entreprises de mettre à niveau et de moderniser une base de données SQL Server locale, dans le cloud et à la périphérie, éliminant ainsi les risques de compatibilité des applications.

Le même Moteur de base de données alimente à la fois SQL Server et Azure SQL Database (avec Azure SQL Managed Instance). Ce moteur de base de données partagé signifie qu’une base de données utilisateur peut être déplacée sans interruption entre les instances locales de SQL Server et d’Azure SQL Database, tandis que le code d’application qui s’exécute dans la base de données en Transact-SQL continue de fonctionner comme dans son système source.

Pour chaque nouvelle version de SQL Server, le niveau de compatibilité par défaut est défini sur la version du Moteur de base de données. Toutefois, le niveau de compatibilité des versions précédentes est conservé pour assurer la compatibilité continue des applications existantes. Cette matrice de compatibilité peut être consultée ici. Par conséquent, une application qui était certifiée pour fonctionner avec une version de SQL Server donnée était en fait certifiée pour fonctionner sur le niveau de compatibilité par défaut de cette version.

Par exemple, le niveau de compatibilité de base de données 130 était la valeur par défaut dans SQL Server 2016 (13.x). Comme les niveaux de compatibilité forcent des comportements spécifiques Transact-SQL fonctionnels et d’optimisation de requêtes, une base de données certifiée pour fonctionner sur SQL Server 2016 (13.x) a été implicitement certifiée sur le niveau de compatibilité de base de données 130. Cette base de données peut fonctionner telle quelle sur une version plus récente de SQL Server (comme SQL Server 2019 (15.x)) et Azure SQL Database, tant que le niveau de compatibilité de la base de données conserve la valeur 130.

Il s’agit d’un principe fondamental pour le modèle d’opération d’intégration continue Microsoft Azure SQL Database. Le Moteur de base de données est en permanence amélioré et mis à niveau dans Azure, mais comme les bases de données existantes conservent leur niveau de compatibilité actuel, elles continuent de fonctionner comme prévu même après les mises à niveau apportées au Moteur de base de données sous-jacent.

C’est également la manière dont SharePoint Server 2016 et SharePoint Server 2019 sont certifiés sur SQL Server et Azure SQL Managed Instance, ce qui vous permet de déployer n’importe quel Moteur de base de données SQL Server qui peut utiliser les niveaux de compatibilité de base de données pris en charge pour ces versions de SharePoint Server. Pour plus d’informations, consultez Configuration matérielle et logicielle requise pour une solution SharePoint Server 2016 et Configuration matérielle et logicielle requise pour une solution SharePoint Server 2019.

Gestion des risques de mise à niveau avec la certification de compatibilité

L’utilisation de la certification de compatibilité est une approche intéressante de la modernisation des bases de données. Avec une certification basée sur le niveau de compatibilité, les développeurs définissent les exigences techniques pour qu’une application soit prise en charge sur SQL Server et Azure SQL Database, mais dissocient le cycle de vie de l’application du cycle de vie de la plateforme de base de données. Cela permet aux entreprises de garder le Moteur de base de données SQL Server à jour comme demandé par les stratégies de cycle de vie, de tirer parti des nouvelles améliorations en matière de scalabilité et de performances qui ne sont pas dépendantes du code et de connecter les applications pour conserver leur état opérationnel pendant les mises à niveau.

Les possibilités de nuire aux fonctionnalités et aux performances est le principal facteur de risque pour toutes les mises à niveau. La certification de compatibilité représente la tranquillité d’esprit en termes de gestion de ces risques de mise à niveau :

  • En ce qui concerne le comportement de Transact-SQL, tout changement implique la recertification de l’application pour vérifier qu’elle est correcte. Toutefois, le paramètre de niveau de compatibilité de la base de données fournit une compatibilité descendante avec les versions antérieures de SQL Server uniquement pour la base de données spécifiée, et non pour l’ensemble du serveur. En conservant le niveau de compatibilité de la base de données en l’état, les requêtes d’application existantes continuent d’afficher le même comportement avant et après la mise à niveau du moteur de base de données. Pour plus d’informations sur les niveaux de compatibilité et le comportement Transact-SQL, consultez Utilisation des niveaux de compatibilité pour la compatibilité descendante.

  • En ce qui concerne les performances, étant donné que des améliorations sont apportées à l’optimiseur de requête avec chaque version, il est possible que vous rencontriez des différences de plan de requête entre différentes versions du Moteur de base de données. Les différences de plan de requête dans l’étendue d’une mise à niveau se traduisent généralement en risques quand certaines modifications peuvent nuire à une requête ou à une charge de travail donnée. À leur tour, ces risques sont souvent ce qui conduit au besoin de recertification de l’application, qui peut retarder les mises à niveau et poser des problèmes de cycle de vie et de support.

    L’atténuation des risques de mise à niveau est la raison pour laquelle les améliorations de l’optimiseur de requête sont limitées au niveau de compatibilité par défaut d’une nouvelle version (autrement dit, le niveau de compatibilité le plus élevé disponible pour une nouvelle version). La certification de compatibilité comprend la protection de la forme du plan de requête : la notion de maintien d’un niveau de compatibilité de base de données en l’état immédiatement après une mise à niveau du Moteur de base de données signifie que le modèle d’optimisation des requêtes utilisé pour créer des plans de requête dans la nouvelle version est le même qu’avant la mise à niveau et que la forme du plan de requête ne doit pas changer.

    Pour plus d’informations, consultez la section Qu’est-ce qu’une forme de plan de requête ? de cet article.

Pour plus d’informations sur les niveaux de compatibilité, consultez Utilisation des niveaux de compatibilité pour la compatibilité descendante.

Important

Pour une application existante déjà certifiée pour un niveau de compatibilité donné, mettez à niveau le Moteur de base de données SQL Server et conservez le niveau de compatibilité de base de données précédent. Il n’est pas nécessaire de recertifier une application dans ce scénario. Pour plus d’informations, consultez Niveaux de compatibilité et mises à niveau du moteur de base de données plus loin dans cet article.

Pour un nouveau travail de développement ou quand une application existante demande d’utiliser de nouvelles fonctionnalités, comme le Traitement de requêtes intelligent, ainsi que de nouvelles instructions Transact-SQL, mettez à niveau le niveau de compatibilité de base de données vers la dernière version disponible dans SQL Server, puis recertifiez votre application pour qu’elle fonctionne avec ce niveau de compatibilité. Pour plus d’informations sur la mise à niveau du niveau de compatibilité de base de données, consultez Bonnes pratiques pour la mise à niveau du niveau de compatibilité de base de données.

Qu’est-ce qu’une forme de plan de requête ?

La forme d’un plan de requête correspond à la représentation visuelle des différents opérateurs qui composent un plan de requête. Cela inclut les opérateurs tels que les recherches, les analyses, les jointures et les tris, ainsi que les liens entre ces opérateurs qui indiquent le flux des données et l’ordre des opérations qui doivent être exécutées pour produire le jeu de résultats prévu. La forme du plan de requête est déterminée par l’optimiseur de requête.

Pour que les performances des requêtes soient prévisibles pendant une mise à niveau, l’un des objectifs fondamentaux est de veiller à utiliser la même forme de plan de requête. Vous pouvez ainsi ne pas modifier le niveau de compatibilité de la base de données immédiatement après une mise à niveau, même si le Moteur de base de données sous-jacent a une version différente. Si aucune autre modification n’a été apportée à l’écosystème d’exécution de la requête (modifications importantes au niveau des ressources disponibles, distribution des données sous-jacentes), les performances d’une requête ne devraient pas changer.

Toutefois, la conservation de la forme d’un plan de requête n’est pas le seul facteur qui peut avoir des répercussions sur les performances après une mise à niveau. Si vous déplacez la base de données vers un Moteur de base de données plus récent et apportez des modifications environnementales, vous pouvez introduire d’autres facteurs qui auront un impact immédiat sur les performances d’une requête, même si le plan de requête conserve la même forme d’une version à l’autre. Ces modifications peuvent être les suivantes : augmentation ou diminution du nombre de ressources mémoire et processeur disponibles dans le nouveau Moteur de base de données, modifications apportées à la configuration du serveur ou de la base de données ou modifications apportées à la distribution des données qui affectent la façon dont un plan de requête est créé. Il est donc important de comprendre que la conservation du niveau de compatibilité de la base de données empêche les modifications de la forme du plan de requête, mais qu’elle n’offre aucune protection contre les autres aspects environnementaux qui influencent les performances des requêtes, dont certaines sont apportées par l’utilisateur.

Pour plus d’informations, consultez le Guide d’architecture de traitement des requêtes.

Avantages de la certification de compatibilité

La certification de base de données présente plusieurs avantages immédiats, comme une approche basée sur la compatibilité plutôt qu’une approche de version nommée :

  • Dissociation de la certification de l’application de la plateforme. En raison de son moteur de base de données partagé, vous n’avez pas besoin de gérer des processus de certification distincts dans Azure et localement pour les applications qui ont juste besoin d’exécuter des requêtes Transact-SQL.
  • Réduction des risques de mise à niveau car, pendant la modernisation de la plateforme de base de données, les cycles de mise à niveau de l’application et de la couche de plateforme de base de données peuvent être séparés pour réduire les interruptions et améliorer la gestion des changements.
  • Mise à niveau sans modification du code. Il est possible de procéder à une mise à niveau de SQL Server ou Azure SQL Database vers une nouvelle version sans modification du code, en conservant le même niveau de compatibilité que le système source, et sans avoir à recertifier immédiatement jusqu’à ce que l’application doive utiliser les améliorations disponibles uniquement dans un niveau de compatibilité de base de données plus élevé.
  • Amélioration de la gestion et de la scalabilité sans nécessiter de modifications d’application, en utilisant des améliorations qui ne sont pas contrôlées par le niveau de compatibilité de la base de données. Dans SQL Server, citons par exemple :

Les nouvelles bases de données sont néanmoins toujours définies sur le niveau de compatibilité par défaut de la version du Moteur de base de données. Toutefois, quand une base de données est restaurée ou attachée à partir d’une version antérieure de SQL Server vers une nouvelle version de SQL Server ou Azure SQL Database, la base de données conserve son niveau de compatibilité existant.

Important

Avant de déplacer une base de données vers une nouvelle version de SQL Server ou Azure SQL Database, vérifiez si le niveau de compatibilité de la base de données est toujours pris en charge. La matrice de prise en charge du niveau de compatibilité de la base de données peut être consultée ici.

Lors de la mise à niveau d’une base de données ayant un niveau de compatibilité inférieur à celui autorisé (par exemple, 90 qui était la valeur par défaut dans SQL Server 2005 (9.x)), son niveau de compatibilité est défini sur la valeur la plus basse autorisée (100).

Pour déterminer le niveau de compatibilité actuel, interrogez la colonne compatibility_level de sys.databases.

Niveaux de compatibilité et mises à niveau du Moteur de base de données

Pour mettre à niveau le Moteur de base de données vers la dernière version tout en conservant le niveau de compatibilité de base de données qui existait avant la mise à niveau et son état de capacité de prise en charge, il est recommandé de procéder à une validation de la surface d’exposition fonctionnelle statique du code d’application dans la base de données (objets de programmabilité comme les procédures, fonctions, déclencheurs stockés et autres) et dans l’application (en utilisant une trace de charge de travail qui capture le code dynamique envoyé par l’application).

Vous pouvez effectuer cette opération facilement en utilisant l’outil Assistant Migration de données Microsoft (DMA). L’absence d’erreurs dans la sortie de l’outil DMA liées à l’absence ou à l’incompatibilité de fonctionnalités protège l’application contre des régressions fonctionnelles dans la nouvelle version cible. Si des modifications sont nécessaires pour garantir que votre base de données fonctionnera dans la nouvelle version, l’Assistant Migration de données vous permettra d’identifier les modifications nécessaires et les solutions de contournement disponibles. Pour plus d’informations, consultez Vue d’ensemble de l’Assistant Migration de données.

Conseil

Cette validation fonctionnelle est particulièrement importante quand vous migrez une base de données avec une version héritée (comme SQL Server 2008 R2 (10.50.x) ou SQL Server 2012 (11.x)) vers une nouvelle version de SQL Server ou Azure SQL Database, car votre code d’application peut utiliser des instructions Transact-SQL qui ne sont plus prises en charge et ne sont donc pas protégées par le niveau de compatibilité de base de données. Toutefois, quand vous passez d’une version plus récente (comme SQL Server 2016 (13.x)) à SQL Server 2019 (15.x) ou Azure SQL Database, il n’y a pas de risque que les instructions Transact-SQL ne soient plus prises en charge. Pour plus d’informations sur les transactions Transact-SQL qui ne sont plus prises en charge, consultez Utilisation du niveau de compatibilité pour la compatibilité descendante.

Notes

DMA prend en charge le niveau de compatibilité de base de données 100 et supérieur. L’utilisation de SQL Server 2005 (9.x) en tant que version source est exclue.

Important

Microsoft recommande de procéder à un test minime de façon à vérifier que la mise à niveau réussit tout en conservant le niveau de compatibilité de base de données précédent. Il vous appartient de déterminer ce à quoi correspond un test minime pour vos propres application et scénario.

Important

Microsoft assure une protection de la forme du plan de requête quand :

  • La nouvelle version (cible) de SQL Server s’exécute sur du matériel comparable à celui sur lequel la précédente version (source) SQL Server s’exécutait.
  • Le même niveau de compatibilité de base de données pris en charge est utilisé sur la version cible de SQL Server et sur la version source de SQL Server.
  • Les mêmes base de données et charge de travail sont utilisées à la fois au niveau du SQL Server cible et du SQL Serversource.

Toute régression de la forme du plan de requête (par rapport à la version source de SQL Server) qui se produit dans les conditions précédentes sera traitée. Contactez le Support technique Microsoft si c’est le cas.

Voir aussi