Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
S’applique à :
SQL Server sur Windows
Dans SQL Server 2016 (13.x) et versions ultérieures, certaines modifications sont activées uniquement une fois que le niveau de compatibilité de la base de données a changé. Cette opération a été effectuée pour plusieurs raisons :
Étant donné que la mise à niveau est une opération unidirectionnelle (il est impossible de faire passer le format de fichier à une version antérieure), le fait de séparer l’activation de nouvelles fonctionnalités pour en faire une opération distincte dans la base de données peut être intéressant. Il est possible de rétablir un paramètre à un niveau de compatibilité de base de données antérieur. Le nouveau modèle réduit le nombre d’éléments devant se produire lors de l’interruption d’une fenêtre.
Les modifications apportées au processeur de requêtes peuvent avoir des effets complexes. Même si une modification « bonne » du système peut être idéale pour la plupart des charges de travail, elle peut entraîner une régression inacceptable sur une requête importante pour d’autres personnes. La séparation de cette logique du processus de mise à niveau permet des fonctionnalités, telles que le Magasin des requêtes, d’atténuer rapidement les régressions de choix de plan ou même de les éviter complètement dans les serveurs de production.
Les comportements suivants sont attendus pour SQL Server 2017 (14.x) lorsqu’une base de données est attachée ou restaurée, et après une mise à niveau sur place :
- Si le niveau de compatibilité d'une base de données utilisateur est à 100 ou supérieur avant la mise à niveau, il reste le même après la mise à niveau.
- Si le niveau de compatibilité d’une base de données utilisateur était à 90 avant la mise à niveau, dans la base de données mise à niveau, le niveau de compatibilité est défini à 100, ce qui correspond au niveau de compatibilité le plus bas pris en charge dans SQL Server 2017 (14.x).
- Les niveaux de compatibilité des bases de données
tempdb,model,msdbetResourcesont définis sur le niveau de compatibilité actuel après la mise à niveau. - La base de données système
masterconserve le niveau de compatibilité qu'elle avait avant la mise à niveau.
Le processus de mise à niveau permettant d’activer la nouvelle fonctionnalité du processeur de requêtes concerne le modèle de maintenance post-lancement du produit. Certains de ces correctifs sont publiés sous l’indicateur de trace 4199. Les clients ayant besoin de correctifs peuvent les accepter sans provoquer de régressions inattendues pour d’autres clients. Le modèle de maintenance post-mise en production pour les correctifs logiciels du processeur de requêtes est documenté dans KB974006. À compter de SQL Server 2016 (13.x), le passage à un nouveau niveau de compatibilité implique que l’indicateur de trace 4199 n’est plus nécessaire, car ces correctifs sont désormais activés par défaut dans le dernier niveau de compatibilité. Par conséquent, dans le cadre du processus de mise à niveau, il est important de vérifier que 4199 n’est pas activé une fois le processus de mise à niveau terminé.
Notes
L’indicateur de trace 4199 est toujours nécessaire pour activer les nouveaux correctifs de processeur de requête publiés après RTM, le cas échéant.
Pour plus d’informations sur le flux de travail recommandé pour mettre à niveau le processeur de requêtes vers la dernière version du code, consultez Conserver la stabilité des performances pendant la mise à niveau vers une section SQL Server plus récente des scénarios d’utilisation du Magasin des requêtes.
À compter de SQL Server Management Studio 18, les utilisateurs peuvent être guidés dans le flux de travail recommandé à l’aide de l’Assistant Paramétrage des requêtes. Pour plus d’informations, consultez Mettre à niveau les bases de données à l’aide de l’Assistant Paramétrage des requêtes.