Now, I will admit up front that I haven't technically tried out all of their bits and pieces of the following tool, but over the past week I have made a lot of use of some of the indexing suggestions by "hacking" out the code that generates the index create statements from the sys.dm_db_missing_index_group_stats dynamic management view. Let me just say upfront: "Wow!" I have seen some very wild index suggestions come from it, and today I took a few of the examples and applied them. We saw a 30-50% improvement over the test without the indexes.
The blog was: Fun for the day - Automated Auto-Indexing! and was posted back in June! I have been dying to try it out, but I am generally not one for building elaborate testing scenarios, so it has been a blog entry just circling waiting to see the light.
Well, over the last few days we have really started hammering on my companies product, preparing to ship it and one of the tools I used was their auto-indexing query that you can download from that blog entry. It uses 3 dynamic management views that are awfully cool: sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_groups and sys.dm_db_missing_index_details to build a set of actual create table statements (ok, a few other tables are involved, but still)
I am not promising you it will be the answer to all of your indexing problems, especially since it only considers what indexes it would have liked to have had to answer a query. It doesn't have a clue what your read/write ratio is. I hope to try out the full blown automatic index generation package with SQL Agent jobs to automatically tune my data warehouse and operation data stores in the future. Any place with only reads (when not loading, of course) should be almost a no brainer...
So you add all of these indexes to improve performance, but as you know, indexes improve performance, but they also hurt write performance. In this blog:
How can SQL Server 2005 help me evaluate and manage indexes?
The Microsoft team with the only name longer than the name of my book (Microsoft SQL Server Development Customer Advisory Team) gives lots of interesting queries to assist with performance tuning. For example, this query:
--- rarely used indexes appear first
declare @dbid int
select @dbid = db_id()
select objectname = object_name(s.object_id)
, s.object_id
, indexname = i.name
, i.index_id
, user_seeks
, user_scans
, user_lookups
, user_updates
from sys.dm_db_index_usage_stats s
join sys.indexes i
on i.object_id = s.object_id
and i.index_id = s.index_id
where database_id = @dbid
and objectproperty(s.object_id , 'IsUserTable') = 1
order by (user_seeks + user_scans + user_lookups + user_updates) asc
Lists how often indexes are used, from least to most. Obviously these are tools that we need to consider using when we tune a new system, but we will certainly want to really watch stuff like this during early days when a system hits production to look at trimming back indexes that are purely for performance that are never being used for such. Stats like this are useless unless you have a totally full load and have gone through real life situations, unlike the previous, “what might have helped” queries from the automatic indexing stuff.
SQL Server keeps getting better and better, and these sorts of thing are some of the primary evidence. If you haven't started to look at the dynamic management views, you should. If only to google them and check out what the blogs are saying about them.
Crossposted to http://drsql.spaces.live.com