T-SQL - OPTION (FAST x) et indicateur de trace 8722

J'ai cherché longtemps et je n'ai toujours pas trouvé la réponse à mon problème.

Notre Dynamics AX génère des requêtes avec l'indicateur de requête OPTION (FAST x), ce qui oblige parfois à utiliser un mauvais plan d'exécution. Les développeurs disent que c'est par défaut et qu'il est difficile de changer (doit être corrigé sur toutes les formes potentiellement).

Je cherchais donc un moyen de remplacer ces indices à l'aide d'indicateurs de trace. J'ai trouvé le charmant indicateur de trace 8722 qui prétend faire en sorte que SQL Server ignore certains conseils de requête, en particulier ceux de la clause OPTION.

Cependant, cela ne fonctionne pas dans mon cas. J'ai également essayé d'activer l'indicateur de trace 8602 (désactiver les indices d'index), mais ma requête fonctionne toujours avec l'indice FAST x (il est beaucoup plus lent que lorsque je supprime réellement la clause OPTION).

J'ai également essayé de vider le cache du plan, en vain.

Des idées? Suis-je en train de manquer quelque chose?

PS J'ai activé les indicateurs de trace à l'échelle mondiale, il s'agit de l'édition développeur de SQL Server 2012

sql-server performance sql-server-2012

— Nelson 2.0
source

Comment avez-vous activé les indicateurs de trace? L'avez-vous activé via le démarrage du serveur ou en utilisant dbcc traceon? dbcc traceon est un indicateur de trace par connexion, donc l'activer dans une connexion client n'affecte pas les autres connexions serveur. Pour l'activer sur le serveur, vous devez ajouter -T <traceflagnumber> à la ligne de commande de démarrage. Je pense que vous pourrez peut-être utiliser un traceon dbcc (flag1, flag2, ..., - 1) pour l'appliquer à l'ensemble du serveur, mais je ne l'ai jamais essayé.

— Mike

Bonjour Mike, j'ai activé les indicateurs de trace à l'échelle mondiale à l'aide de DBCC TRACEON (8722, -1), puis j'ai vérifié l'état avec DBCC TRACESTATUS. Peut-être que l'indicateur de trace n'est plus officiellement pris en charge ou que je dois réellement le mettre dans le paramètre de démarrage et redémarrer le service, ou qu'il fait l'objet de CU3 (j'exécute 2012 SP2 RTM).

Autant que je sache, les drapeaux de trace 8722, 8755 et 8602 n'ont jamais été officiellement documentés. La dernière fois que je me souviens qu'ils étaient efficaces, c'était dans SQL Server 2000, il n'est donc pas très surprenant que vous constatiez qu'ils sont ignorés dans SQL Server 2012.

Pour des modèles de requête spécifiques, il est souvent possible de supprimer l' FAST nindice à l'aide des repères de plan. Même ainsi, la meilleure solution consiste à amener les développeurs AX à le corriger du côté des applications.

— Paul White 9
source