3. Ineffective Indexes Insert, Update and Delete operations will be slower if you have too many indexes on your table Indexes are stored on the disk, the more indexes you have, the more disk space you use
4. sys.dm_db_index_usage_stats Counts of different types of index operations Time each type of operation last performed. Requires VIEW SERVER STATE permission Counters reset to empty when SQL Server Service is restarted If the database is detached or shutdown, all rows associated with that DB are removed Information gathered is real-time
6. On to the code… Pick a table and view its indexes Take a look at the current usage Run code that targets each index and see when the index was last used Recheck the usage View index usage for entire database How to disable an index How to enable an index How to drop an index
8. Conclusion Use sys.dm_db_index_usage_stats DMV to easily identify real-time index usage stats Identify indexes that are rarely or never used Disable for a time before dropping If disabled indexes aren’t missed – drop them to save disk space
9. Resources Click on the Word icon to the right to access the SQL code used in the practical element of this session. Download AdventureWorks2008 DBs for free here: http://tinyurl.com/c6y6a3 BOL sys.dm_db_index_usage_stats information page: http://tinyurl.com/qpfa4d Useful blog article on managing indexes at a more detailed level: http://tinyurl.com/38fb5v Blog: http://nzgirlgeek.blogspot.com Web: www.aucklandsql.com www.girlgeekdinners.co.nz Email: amanda@aucklandsql.com
From SQL Server 2005 onwards, we have been able to use DMVs to identify which of our indexes are effective and which of our indexes can be disabled. This short talk will cover, at a very high level, how and why you should be checking the effectiveness of your indexes.
When fixingperformance issues on a database there are quite a few DBAs and developers out there whose first thought is – ‘let’s add another index’. We need to stop and think before adding another index; surely we should check to see if the indexes we’ve already got are doing their job correctly and make sure they’re being effectively used and maybe we could also get rid of any indexes that are a waste of disk space and aren’t doing anything constructive. I’ve worked with developers in the past who were of the impression that the more indexes you stick on a table the better, and even when performance was bad they continued to add more indexes as if they were some sort of database sticky plaster. So what happens if we’ve got too many indexes on a table?
If you have too many indexes on a table then you run the risk of causing performance issues with the very thing you are using to try and fix the performance issues. As index size on the disk is dependent up on the table size, number of columns and type of columns,toomany indexes may = slower performance. What we need to do is find out which indexes are useful and which are not, then we get rid of the useless ones, free up some disk space and also make ongoing maintenance much less of a headache. But how can we do this? From SQL Server 2005 onwards this task is much simpler as you can use DMVs to help investigate index usage stats. We’re going to look at one of these DMVs in this presentation.
The DMV we’re going to be using in the demonstration is sys.dm_db_index_usage_stats. I’ve provided a link at then end of this talk for the relevant MSDN page. This DMV returns a lot of information – user and system seeks, scans, lookups and updates along with the times these occurred. You can evaluate at table or database level.
What information does this DMV return? These are the columns returned by the DMV.Data types and descriptions of each of these items can be found on the MSDN page for this DMV – details at the end.
We’ll be using the AdventureWorks2008 DB for during the code example stage – this is free to download from codeplex and there is a link provided at the end of this presentation. What I’m going to do is show you the information returned by sys.dm_db_index_usage_stats, we will then run some select statements so that you can see how the results change. You will also be able to see when the index was last used. You can use this information to find indexes that are sitting around using up disk space but not being used, however, don’t drop indexes willynilly – they may not have been used for a while but what if one of those indexes that aren’t being used are only triggered when Joe Bloggs updates some data in an obscure table once a fortnight. The best option is to disable the index for a period to see what effect this has on the database. If after a set period of time (perhaps base this on the last used value – if it was a month ago, wait a month) you see no degradation in performance, then you should be able to safely drop the index.
Using sys.dm_db_index_usage_stats DMV you can identify indexes which are used often by queries and also indexes which are rarely used. Any indexes that are rarely or never used, disable the indexes for some time and see is there is any performance degradation.If there is no performance degradation then you can go ahead and drop the index there by saving disk space and improving performance during Insert, Update and Delete operations.