Ma recherche sur le sujet m'a amené ici, donc je voudrais juste partager mon expérience récente sur le sujet.
J'utilisais SQL 2014, alors je me suis dit que je serais à l'abri de devoir me soucier un peu de 4199 ... mais ce n'était tout simplement pas vrai ...
Comment diagnostiquer si vous avez besoin de 4199
Si votre requête semble ne pas fonctionner correctement , en particulier lorsque vous pensez qu'elle ne devrait pas, essayez également d'ajouter ce qui suit à la fin de celle-ci pour voir si cela résout tous vos problèmes, car vous pourriez avoir besoin de 4199 («Activer tous les correctifs de Query Optimizer». )
SELECT SomeColumn
FROM SomeTable
OPTION(QUERYTRACEON 4199)
Dans ma situation, j'avais une clause du top 10 faisant exploser une requête qui fonctionnait bien sans, ce qui m'a fait penser qu'il se passait quelque chose de louche, et que 4199 pourrait aider.
Environ 4199
Tous les correctifs de bogue / performances de SQL Server Query Optimizer créés après la sortie de la nouvelle version majeure sont masqués et bloqués. C'est au cas où ils pourraient réellement nuire à un autre programme théoriquement parfaitement optimisé. Donc, installez les mises à jour comme vous le pouvez, les modifications réelles de l'optimiseur de requête ne sont pas activées par défaut. Par conséquent, une fois qu'une seule correction ou amélioration a été effectuée, 4199 devient une nécessité si vous souhaitez en profiter. Comme de nombreux correctifs apparaissent, vous finirez par l'activer lorsque l'un d'eux vous affecte. Ces correctifs sont généralement liés à leurs propres indicateurs de trace, mais 4199 est utilisé comme maître "Activer chaque correctif".
Si vous savez de quels correctifs vous avez besoin, vous pouvez les activer à la pièce au lieu d'utiliser 4199. Si vous souhaitez activer tous les correctifs, utilisez 4199.
Ok, donc vous voulez 4199 globalement ...
Créez simplement un travail d'agent SQL qui s'exécute chaque matin avec la ligne suivante pour activer l'indicateur de trace globalement. Cela garantit que si quelqu'un les a éteints ou etc., ils se rallument. Cette étape de travail a un sql assez simple:
DBCC TRACEON (4199, -1);
Où -1 spécifie la partie globale dans DBCC TRACEON. Pour plus d'informations, voir:
https://msdn.microsoft.com/en-us/library/ms187329.aspx?f=255&MSPPError=-2147217396
"Recompilation" des plans de requête
Dans ma dernière tentative, j'ai dû activer 4199 globalement, puis supprimer également les plans de requête mis en cache existants :
sp_recompile 'dbo.SomeTable'
https://msdn.microsoft.com/en-us/library/ms181647.aspx?f=255&MSPPError=-2147217396
Où la procédure stockée de recompilation trouve tous les plans de requête relatifs à l'objet de base de données (comme une table) et supprime ces plans de requête, ce qui nécessite la prochaine tentative d'exécution d'une requête similaire pour les compiler.
Donc, dans mon cas, 4199 a empêché la création des mauvais plans de requête, mais j'ai également dû supprimer ceux qui étaient toujours mis en cache via sp_recompile. Choisissez n'importe quelle table de la requête connue affectée et vous devriez être prêt à réessayer cette requête, en supposant que vous avez maintenant activé globalement 4199 et effacé le plan de requête mis en cache incriminé.
En conclusion sur 4199
Lorsque vous utilisez des index, une optimisation de plan de requête intelligente devient importante pour utiliser ces index intelligemment, et en supposant qu'avec le temps, une correction du processus d'optimisation de requête soit publiée, vous êtes généralement dans l'eau potable pour simplement exécuter avec 4199 activé globalement, tant que vous réalisez qu'un nouveau correctif peut ne pas fonctionner aussi bien avec une base de données hautement optimisée qui était optimisée dans l'environnement précédent avant ledit correctif. Mais que fait 4199? Il active simplement tous les correctifs.