Targeted Index Performance Improvements

  • Comments posted to this topic are about the item Targeted Index Performance Improvements

  • If this is run on a production server, would other queries interfer with the results. I assume because you are doing a snapshot, you do not want anything else to be running at the time?

  • Hi Mathew,

    The utility records all index activity on the database, not just that which belongs to the SQL you’re running.

    So it might be better to schedule the utility to run at a time when you know yours is the only SQL running, or run it on a stand-alone database where you can ensure the only SQL running is yours.

    Hope this helps


  • Cheers 🙂

  • I am trying to identify the advantage of using this utility versus an "Actual Execution Plan". It seems to give all the same information about which indexes where used, scans/seeks and row count. The execution plan has the additional advantage of only showing stats for the query in question.

  • Hi Toby,

    I would hope the output from this utility is much easier to read and interpret, with consolidated results for a batch of SQL. Additionally, the ‘Actual Executing Plan’ option can take quite a lot of resources and time to produce (and interpret).

    Also, there may be times when you want the results from all the SQL running on the box over a given time period, in this case reading and consolidating the individual plans would be troublesome.

    That said, you’ve quite rightly identified a degree of overlap.



  • I need to read this article carefully, but my immediate reaction is that the indexes that aren't used or don't even exist are the ones that should be considered for attention. And that's what the Tuning Wizard is for - that, and statistics. I will admit that I do not yet "get" statistics.

    I am often surprised when I design tables with carefully chosen indexes and SQL Server ignores them, whereas if I was still programming a database "row by agonising row" I myself would use the index strategy I designed for the query. Maybe it's the statistics. I look at the Execution Plan and I'm like, "Why aren't you using the nice index I made for you!" Incidentally, I'm single.

  • so this proc needs to be installed in each database where you want to run it?

  • Hi,

    yes the code uses sys.indexes, which is database specific, so it needs to run in each database separately.



  • Thank you for sharing your utility, taking the time to explain how it works, and going over the strengths and weaknesses. As you replied to a previous poster, your results are easy to read. This is a nice tool to add to the toolbox.


  • I suppose you could pass the database name as another parameter. I'm not sure what happens with a temporary stored procedure that looks in local-database objects if you try to run it against two different databases, does it keep looking in the first database? I have an idea I addressed that one time by making the whole body of the temp. s.p. be "dynamic SQL", i.e. EXEC sp_executesql...

    I also don't remember the scope of the trick for making a non-temporary procedure accessible anywhere like master procedures from Microsoft, or whatether it was a good idea. If you don't like typing too much and you don't want no mess withimaster then you could place utility procedures in a database with a convenient short name, maybe on a linked server likewise. Let's see, you'd need that procedure returning dynamic SQL text which you'd execute locally...

  • Hi,

    I have another query that offers nearly the same output but what I miss here are two informations.

    is_unique (sys.indexes) because sometimes you do have an unique index for consistency even if it is expensive.

    And the size of the index (I take it from sys.dm_db_partition_stats) so you may see if the index is necessary or not. If the Clustered has a size of lets say 1 GB, a specific index may be pretty good even if the ratio between seek and updates is 1/100.

    And if there are thousands of scans on a table with one page it does not matter or at least at the moment.

    Thanks for sharing this script, it helps to find the bad guys out there that are torturing the servers 😉

  • Thanks for the wonderful article Ian. As soon as i read this article i tested this out on one of our development environments. I compared the results from your code and from the execution plan. The results are not really the same. In the execution plan i can see there are many clustered scans going on and the result from your script doesn't show any scans at all. Mentioned below is my script:

    EXEC dbo.dba_ShowIndexUsage @SQLToRun ='exec usp_myproc @Id=1237405'

    This procedures has following objects:

    i) few functions

    ii) few views

    iii) few tables.

    Could you please say why is the output different or is it intended to use for different purpose? Thanks

  • Hi,

    I’m glad you liked the article. I’m wondering if the reason why the output doesn’t match the cached plan is because the plan contains information about all paths of execution. If the parameter you pass results in only a few paths being executed, then the results will not match ALL of the cached plan.

    You can discover a lot more about DMVs in my forthcoming book: SQL Server DMVs in Action which contains 100+ scripts like this one.

    Chapter 1 can be downloaded for free and includes scripts for:

    A simple monitor

    Finding your slowest queries

    Find your missing indexes

    Identifying what SQL is running now

    Quickly find a cached plan



  • Thanks for quick reply. I am trying to understand this in a better way, if your script doesn't match the indexes what are actually used then where can i use this script?

Viewing 15 posts - 1 through 15 (of 23 total)

You must be logged in to reply to this topic. Login to reply