Requêtes sans bon plan trouvé

J'ai une base de données SQL Server 2012. J'ai remarqué la valeur de Reason for early termination of statement optimizationcertaines requêtes et tout a donné Good Enough Plan Found. Maintenant mes questions sont:

1. Quels sont tous les types possibles de «Raison de l'arrêt précoce de l'optimisation des relevés». J'ai fait cette recherche dans msdn mais je n'ai pas obtenu la liste complète des valeurs.

2. Existe-t-il un événement DMV ou étendu pour répertorier toutes les requêtes pour lesquelles l'optimisation a été interrompue pour des raisons autres que Good Enough Plan Found? J'ai fait référence à deux articles qui n'énumèrent pas la liste complète des possibilités. [En outre, ils me donnent des résultats différents dans ma base de données].

   • Recherche: Délai d'expiration de la compilation des requêtes
   • Identifier les plans de requête qui ne sont pas assez bons

• Limite de mémoire dépassée

  L'optimiseur a été contraint d'arrêter de chercher de meilleures alternatives de plan en raison de la pression de la mémoire. La raison de cela doit être étudiée et corrigée, puis la compilation des requêtes doit être tentée à nouveau. Le plan renvoyé peut très bien ne pas être celui que l'optimiseur aurait sélectionné si la condition de mémoire faible n'existait pas.

• Temps libre

  Cette raison est très mal comprise .

  L'optimiseur de requêtes vise à trouver rapidement un plan raisonnable . Il n'effectue pas une recherche exhaustive pour trouver le meilleur plan possible. De par sa conception, il évite de consacrer plus de temps à l'optimisation que nécessaire. L'une de ces fonctionnalités qui fonctionne pour garantir que c'est le «temps mort» (pas une mesure du temps).

  L'optimiseur se définit un «budget d'exploration» basé sur la complexité de la requête logique, les estimations de cardinalité et le coût estimé du plan le moins cher trouvé jusqu'à présent (le cas échéant). Les requêtes plus complexes avec une cardinalité plus élevée reçoivent un budget plus élevé.

  Si ce budget est dépassé lors d'une de ses phases de recherche, la phase se termine. Cela fait partie de la conception et du fonctionnement normal de l'optimiseur. Les requêtes qui nécessitent plus d'efforts d'optimisation l'obtiennent; ceux qui ne le font pas.

  Considérez «Time Out» comme «Bon plan suffisamment trouvé».

• Bon plan suffisant trouvé

  Cela signifie exactement la même chose qu'une raison vierge. C'est simplement une bizarrerie historique que les plans avec un coût inférieur à 0,909090 ... (1 / 1,1) sont étiquetés de cette façon. Rien ne s'arrête tôt ou n'est autrement géré de manière spéciale ou différent dans le code d'optimisation lorsque cette raison apparaît.

Mis à part la limite de mémoire dépassée, aucune des «raisons de résiliation anticipée» ne signifie beaucoup (voire rien) pour le réglage des requêtes ou l'analyse des performances. Je les ignore généralement.

Conseil

Cibler les efforts de réglage des requêtes en fonction de mesures de performances réelles (temps écoulé, utilisation CPU / mémoire, ... tout ce qui est important dans le contexte). Si une requête est trop lente pour son objectif, passez du temps à la rendre plus rapide. Mesurez les performances réelles, comparez-les à la ligne de base et à l'historique, et ciblez l'effort de réglage sur les écarts importants.

Stockez des données propres et garanties dans un schéma relationnel approprié, avec des statistiques et des index utiles, et des requêtes bien écrites et optimisées.

Si vous accédez à http://schemas.microsoft.com/sqlserver/2004/07/showplan/showplanxml.xsd (qui est le lien que vous verrez si vous ouvrez un plan d'exécution au format xml), vous verrez le trois raisons énumérées, qui sont:

• Temps libre
• MemoryLimitExceeded
• GoodEnoughPlanFound

Les articles que vous mentionnez semblent corrects pour trouver ces événements, avez-vous un problème spécifique? La seule chose à garder à l'esprit est que ces DMV ne capturent pas toutes les commandes SQL jamais exécutées sur le serveur et ne sont réinitialisées au redémarrage du serveur. Vous pouvez piéger showplan xml avec des événements étendus et l'interroger, mais cela me semble exagéré.

Je ne m'inquiéterais pas trop de GoodEnoughPlanFound, semble que l'optimiseur fasse son travail (de trouver rapidement un bon plan) assez bien.

HTH