Targeted Index Performance Improvements

Question

Targeted Index Performance Improvements

ianstirk

Ten Centuries

Points: 1310
More actions
September 17, 2009 at 12:20 am

#204693

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

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

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

MattTheDBA SSC Eights! Points: 960 More actions · Answer 1

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?

ianstirk Ten Centuries Points: 1310 More actions · Answer 2

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

Ian

MattTheDBA SSC Eights! Points: 960 More actions · Answer 3

MattTheDBA

SSC Eights!

Points: 960

September 17, 2009 at 3:17 am

#1054850

Cheers 🙂

Toby White SSCertifiable Points: 6187 More actions · Answer 4

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.

ianstirk Ten Centuries Points: 1310 More actions · Answer 5

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.

Thanks

Ian

rja.carnegie SSC Eights! Points: 923 More actions · Answer 6

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.

Mister Sachmo SSCommitted Points: 1618 More actions · Answer 7

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

ianstirk Ten Centuries Points: 1310 More actions · Answer 8

Hi,

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

Thanks

Ian

JJ B SSCertifiable Points: 5100 More actions · Answer 9

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.

Thanks!

rja.carnegie SSC Eights! Points: 923 More actions · Answer 10

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...

Christoph D Say Hey Kid Points: 693 More actions · Answer 11

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 😉

curious_sqldba SSC-Dedicated Points: 36494 More actions · Answer 12

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

ianstirk Ten Centuries Points: 1310 More actions · Answer 13

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 www.manning.com/stirk 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

Ian

curious_sqldba SSC-Dedicated Points: 36494 More actions · Answer 14

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?