Indicateur de trace 4199 - Activer globalement?
Cela peut tomber dans la catégorie d'opinion, mais je suis curieux de savoir si les gens utilisent indicateur de trace 4199 comme paramètre de démarrage pour SQL Server. Pour ceux qui l'ont utilisé, dans quelles circonstances avez-vous connu une régression des requêtes?
Cela semble certainement être un avantage potentiel en termes de performances dans tous les domaines.J'envisage de l'activer à l'échelle mondiale dans notre environnement de non-production et de le laisser reposer pendant quelques mois pour résoudre tous les problèmes.
Les correctifs de 4199 sont-ils intégrés à l'optimiseur par défaut en 2014 (ou 2016)? Bien que je comprenne le fait de ne pas introduire de modifications de plan inattendues, il semble étrange de garder tous ces correctifs cachés entre les versions.
Nous utilisons 2008, 2008R2 et surtout 2012.
Personnellement, chaque fois que je crée un nouveau serveur pour un nouveau projet, j'active toujours TF4199 globalement. La même chose s'applique lorsque je mets à niveau des instances existantes vers des versions plus récentes.
Le TF permet de nouveaux correctifs qui pourraient affecter le comportement de l'application, mais pour les nouveaux projets, le risque de régression n'est pas un problème. Pour les instances mises à niveau à partir des versions précédentes, les différences entre l'ancienne et la nouvelle version sont préoccupantes en elles-mêmes et le fait de devoir gérer la régression du plan est de toute façon attendu, donc je préfère me battre avec elle avec TF4199 activé.
En ce qui concerne les bases de données existantes, il n'y a qu'une seule façon de le savoir: le tester. Vous pouvez capturer une charge de travail sur la configuration existante et la relire après avoir activé l'indicateur. Les utilitaires RML peuvent vous aider à automatiser le processus, comme décrit dans cette réponse .
De toute évidence, l'indicateur affecte toute l'instance, vous devrez donc tester toutes les bases de données qui s'y trouvent.
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 mal fonctionner , en particulier lorsque vous pensez qu'elle ne devrait pas 't, puis essayez d'ajouter ce qui suit à la fin de celui-ci pour voir s'il résout tous vos problèmes, car vous pourriez avoir besoin 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 que quelque chose de louche se passait, 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
Plans de requête "Recompilation"
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, nécessitant la prochaine tentative d'exécuter 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'au fil du temps, une correction du processus d'optimisation de requête sera 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 pourrait 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.
Je voulais partager mon expérience avec l'indicateur de trace 4199.
Je viens de terminer le diagnostic d'un problème de performances sur un système client exécutant SQL Server 2012 SP3. Le client déplaçait une base de données de rapports de son serveur de production OLTP) vers un nouveau serveur. L'objectif du client était de supprimer la concurrence pour les ressources avec les requêtes OLTP. Malheureusement, le client a déclaré que le nouveau serveur de rapports était très lent.
Un exemple de requête exécutée sur le système OLTP terminé en 1,6 seconde. Le plan de requête a effectué une recherche d'index sur une table de 200 millions de lignes faisant partie d'une vue.
Sur le nouveau serveur, la même requête s'est terminée en 10 minutes 44 secondes. Il a effectué un balayage d'index sur la même table de ~ 200 millions de lignes.
Les données du serveur de rapports étaient une copie des données OLTP, il ne semblait donc pas y avoir de différence dans les données.
J'ai été perplexe jusqu'à ce que je me souvienne que notre logiciel (qui exécute leur OLTP) a activé certains indicateurs de trace au démarrage. L'un d'eux, 4199, je me suis souvenu était un correctif d'optimiseur de requête.
J'ai testé l'activation de l'indicateur de trace 4199 sur le nouveau serveur de rapports du client et la requête de rapports s'est terminée en 0,6 seconde. (Wow!) J'ai désactivé l'indicateur de trace, et la requête était de nouveau terminée en 10 min 44 sec. Activation du drapeau: retour à 0,6 seconde. Apparemment, l'activation de l'indicateur de trace a permis à l'optimiseur d'utiliser une recherche d'index dans la vue sur la table de 200 millions de lignes.
Dans ce cas, les optimisations de requête activées par l'indicateur de trace 4199 ont fait une énorme différence. Vos expériences peuvent varier. Cependant, sur la base de cette expérience, cela me semble certainement utile.