Le plan d'exécution estimé montrent nécessaire indices?

Ok,

Je ne sais pas si je suis fou ou pas, mais je n'ai pas l'Estimation de exexution plan d'utilisation pour vous montrer ce que les Indices dont vous auriez besoin pour améliorer vos performances? J'ai utilisé lors de mon ancien poste, mais maintenant il semble que je dois à l'aide de l'assistant paramétrage. Je n'ai pas l'esprit de l'assistant paramétrage, mais je l'ai fait avant était si simple!

Grâce

InformationsquelleAutor Limey | 2012-05-24
  1. 7

    Dans les deux SSMS 2008 et dans SSMS 2012 voir cela fonctionne bien pour les deux estimées et réelles de plans.

    Voici un petit exemple pour montrer que les estimées et réelles de plans d'exécution seront à la fois de montrer l'absence d'index:

    USE tempdb;
GO

CREATE TABLE dbo.smorg(blamp INT);
GO

INSERT dbo.smorg(blamp) SELECT n FROM
(
  SELECT ROW_NUMBER() OVER (ORDER BY c1.object_id)
  FROM sys.all_objects AS c1, sys.all_objects AS c2

) AS x(n);
GO

    Maintenant mettre en évidence ce et choisir le plan d'exécution estimé, ou tourner sur le plan d'exécution réel et frapper Exécuter:

    SELECT blamp FROM dbo.smorg WHERE blamp BETWEEN 100 AND 105;

    Vous devriez voir un index manquant recommandation. Et vous allez le voir ici:

    SELECT * 
    FROM sys.dm_db_missing_index_details 
    WHERE [object_id] = OBJECT_ID('dbo.smorg');

    Vous pouvez en savoir plus sur la DMV ici:

    http://msdn.microsoft.com/en-us/library/ms345434.aspx

    Aussi, vous devriez enquêter sur SQL Sentry Plan d'Explorer (disclaimer: je travaille pour SQL Sentry). C'est un outil gratuit qui montre l'absence d'index pour l'estimation des plans (si ils sont dans le XML fournies par SQL Server), ne pas avoir de bugs comme SSMS (où il répète la même recommandation sur plusieurs lots, même les lots qui ne mentionnent pas les mêmes tables), et génère de réels plans d'exécution sans tirant tous les résultats à travers le réseau vers le client - il juste de rejets (ainsi le réseau de données et les frais généraux ne sont pas comptabilisés dans le plan d'analyse).

    • Ok, mais j'étais proche. c'est ce que je suis à la recherche de rapport à l'aide de l'assistant paramétrage.
    • hmmmm....J'ai essayé et sa ne montrant pas les indices nécessaires. Je me suis même offert un moyen d'une clé primaire juste pour s'assurer.
    • Le plan d'exécution n'est pas en montrant un index manquant? C'est peut-être parce que le missing_indexes DMV ne sais pas l'index est manquant, ou parce que le plan est si trivial que l'optimiseur ne pense pas qu'un index serait utile. Juste parce que votre table ne dispose pas d'un index cluster ne signifie pas que chaque requête serait à l'avantage de celui-ci. Avez-vous regarder dans sys.dm_db_missing_index_details manuellement pour voir si ce tableau est encore là? C'est là que les informations contenues dans le plan vient de...
    • Je n'ai que deux enregistrements dans cette table, et ses pour un jeter de la table que je ne suis pas à l'aide de mes requêtes. Donc, si Mon plan d'exécution a un problème et j'ai besoin d'un indice, il doit apparaître dans ce tableau?
    • Dans ce cas, le plan est sans doute trop trivial pour exiger un index. Si votre requête t ont un problème, alors oui un index qui aurait mieux pris en charge la requête sera noté dans le DMV.
    • Imagine que ça doit être bien pratique pour interroger la table et voir ce que les indices qui vous manque?
    • Ainsi, l'exécution d'une requête vous sera généralement exécuter. En disant SELECT * FROM table sera probablement vous donner des recommandations pour la couverture de l'indice qu'aucun de vos requêtes en réalité. De vérifier la DMV périodiquement comme il va stocker les résultats basées sur les requêtes de votre charge de travail. sys.dm_db_index_usage_details pouvez également vous parler de gaspillage index (ceux avec beaucoup de mises à jour, mais peu ou pas de lit).
    • Mon système ne peut pas trouver sys.dm_db_index_usage_details, est-ce peut-être une affaire de 2012?
    • Je crois que j'ai trouvé ce que tu voulais dire dans sys.dm_db_index_usage_stats
    • Yep, désolé pour la faute de frappe

    InformationsquelleAutor Aaron Bertrand