Partager via

Certification de compatibilité

S’applique à :SQL ServerAzure SQL DatabaseAzure 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.

Voici comment SharePoint Server 2016 et SharePoint Server 2019 certifient également sur SQL Server et Azure SQL Managed Instance. Vous pouvez déployer n’importe quel moteur de base de données SQL Server qui utilise 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. Lorsque les développeurs certifient en fonction du niveau de compatibilité, vous définissez les exigences techniques pour qu’une application soit prise en charge sur SQL Server et Azure SQL Database, tout en dissociant le cycle de vie de l’application de celui 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 principaux facteurs de risque pour toute mise à niveau sont la possibilité d’affecter négativement les fonctionnalités et les problèmes de performances. 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 par un risque, lorsqu’il est possible que certaines modifications puissent 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é inclut la protection des formes du plan de requête : la notion de maintien d’un niveau de compatibilité de base de données as-is, immédiatement après la mise à niveau d’un moteur de base de données, se traduit par l’utilisation du même modèle d’optimisation de requête dans la nouvelle version qu’avant la mise à niveau, et 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.

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 le nouveau travail de développement, ou lorsqu’une application existante nécessite l’utilisation de nouvelles fonctionnalités telles que le traitement intelligent des requêtes et une nouvelle instance Transact-SQL, envisagez de mettre à niveau le niveau de compatibilité de la base de données vers la dernière version disponible dans SQL Server et de récertifier 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 susceptible d’avoir des implications 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 également des modifications environnementales, vous pouvez introduire des facteurs qui ont un effet immédiat sur les performances d’une requête, même si le plan de requête conserve la même forme entre les versions. Ces modifications environnementales peuvent inclure le nouveau moteur de base de données disposant de ressources de mémoire et de processeur plus ou moins disponibles, des modifications apportées aux options de configuration du serveur ou de la base de données, ou des modifications apportées à la distribution des données qui affectent la création d’un plan de requête. 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, voici quelques exemples :

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.

Vérifier le niveau de compatibilité pris en charge

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 est visible dans les arguments de niveau de compatibilité ALTER DATABASE.

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 compatibility_level colonne dans 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 la base de données qui existait avant la mise à niveau et son état de prise en charge, vous devez effectuer la validation de surface fonctionnelle statique du code de l’application dans la base de données (objets de programmabilité tels que les procédures stockées, les fonctions, les déclencheurs et d’autres) et dans l’application (à l’aide d’une trace de charge de travail qui capture le code dynamique envoyé par l’application).

Cela peut être facilement effectué à l’aide du composant de migration SQL Server dans SQL Server Management Studio. L’absence d’erreurs dans la sortie du rapport, concernant les fonctionnalités manquantes ou incompatibles, protège l’application contre toutes les régressions fonctionnelles sur la nouvelle version cible. Si des modifications sont requises pour vous assurer que votre base de données fonctionnera dans la nouvelle version, l’outil vous permet de déterminer où les modifications sont nécessaires et les solutions de contournement disponibles.

Cette validation fonctionnelle est particulièrement importante lors du déplacement d’une base de données d’une version héritée (par exemple, SQL Server 2008 R2 (10.50.x) ou SQL Server 2012 (11.x)) vers une nouvelle version de SQL Server ou d’Azure SQL Database, car votre code d’application peut utiliser des Transact-SQL qui ne sont pas protégés par le niveau de compatibilité de la base de données. Mais lorsque vous passez d’une version plus récente (par exemple, SQL Server 2016 (13.x)) à SQL Server 2022 (16.x) ou Azure SQL Database, il n’y a pas de Transact-SQL à vous soucier. 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

Le composant de migration SQL Server prend en charge le niveau de compatibilité de la base de données 100 et versions ultérieures. L’utilisation de SQL Server 2005 (9.x) en tant que version source est exclue.

Nous vous recommandons d’effectuer un test minimal pour valider la réussite d’une mise à niveau, tout en conservant le niveau de compatibilité de la 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.

Protection du plan de requête

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é à la fois au niveau de SQL Server cible et de SQL Server source.

  • La même base de données et la même charge de travail sont utilisées à la fois au niveau du serveur SQL Server cible et de la source SQL Server.

Toute régression de forme de plan de requête (par rapport à la source SQL Server) qui se produit dans ces conditions sera traitée. Contactez le support technique Microsoft dans ce cas.

Contenu connexe