sys.dm_db_index_usage_stats

This is the second article about the dynamic managment views in SQL Server 2005, to see all of them click here

Today we are going to talk about the sys.dm_db_index_usage_stats dynamic managment view
This view is extremely helpful in a couple of ways, I will list some of them
It can help you identify if an index is used or not
You can also find out the scan to seek ratio
Another helpful thing is the fact that the last seek and scan dates are in the view, this can help you determine if the index is still used


So let's get started shall we?


CREATE TABLE TestIndex(id INT identity,
SomeID INT not null,
SomeDate DATETIME not null)
GO

CREATE CLUSTERED INDEX IX_TestIndexID ON TestIndex(SomeID)
GO

CREATE NONCLUSTERED INDEX IX_TestIndexDate ON TestIndex(SomeDate)
GO

INSERT TestIndex VALUES(1,GETDATE())
GO
INSERT TestIndex VALUES(2,GETDATE()-1)
GO


--Run the sys.dm_db_index_usage_stats query
SELECT
TableName = OBJECT_NAME(s.[object_id]),
IndexName = i.name,
s.last_user_seek,
s.user_seeks,
CASE s.user_seeks WHEN 0 THEN 0
ELSE s.user_seeks*1.0 /(s.user_scans + s.user_seeks) * 100.0 END AS SeekPercentage,
s.last_user_scan,
s.user_scans,
CASE s.user_scans WHEN 0 THEN 0
ELSE s.user_scans*1.0 /(s.user_scans + s.user_seeks) * 100.0 END AS ScanPercentage,
s.last_user_lookup,
s.user_lookups,
s.last_user_update,
s.user_updates,
s.last_system_seek,
s.last_system_scan,
s.last_system_lookup,
s.last_system_update,*
FROM
sys.dm_db_index_usage_stats s
INNER JOIN
sys.indexes i
ON
s.[object_id] = i.[object_id]
AND s.index_id = i.index_id
WHERE
s.database_id = DB_ID()
AND OBJECTPROPERTY(s.[object_id], 'IsMsShipped') = 0
AND OBJECT_NAME(s.[object_id]) = 'TestIndex';

After each of the select queries below run the sys.dm_db_index_usage_stats query above

--user_updates should be 2 but user_seeks,user_scans, user_lookups should be 0
SELECT *
FROM TestIndex
WHERE ID =1
--IX_TestIndexID user_scans = 1


SELECT *
FROM TestIndex
WHERE SomeID =1
--IX_TestIndexID user_seeks = 1

SELECT *
FROM TestIndex
WHERE SomeDate > GETDATE() -1
AND SomeID =1
--IX_TestIndexID user_seeks = 2


--let's force the optimizer to use the IX_TestIndexDate index
SELECT *
FROM TestIndex WITH (INDEX = IX_TestIndexDate)
WHERE SomeDAte > GETDATE() -1
--IX_TestIndexDate user_seeks = 1


IX_TestIndexID
SeekPercentage = 66.66% and ScanPercentage = 33.33

As you can see I have added the following code
CASE s.user_seeks WHEN 0 THEN 0
ELSE s.user_seeks*1.0 /(s.user_scans + s.user_seeks) * 100.0 END AS SeekPercentage
CASE s.user_scans WHEN 0 THEN 0
ELSE s.user_scans*1.0 /(s.user_scans + s.user_seeks) * 100.0 END AS ScanPercentage

This is helpful to determine the seek/scan ratio if you have mostly scans then maybe you have to look at your queries to optimize them


If you run the sys.dm_db_index_usage_stats query again you will se that the user_updates column is 2, that's because we inserted 2 rows (2 batches)

Let's do this

UPDATE TestIndex
SET SomeID = SomeID + 1
--(2 row(s) affected)

Now user_updates is 3 since we used 1 batch that modified 2 rows

Now restart your server and run the same query again. as you can see the resultset is empty this is because the counters are initialized to empty whenever the SQL Server (MSSQLSERVER) service is started. In addition, whenever a database is detached or is shut down (for example, because AUTO_CLOSE is set to ON), all rows associated with the database are removed.
When an index is used, a row is added to sys.dm_db_index_usage_stats if a row does not already exist for the index. When the row is added, its counters are initially set to zero.

When you run this query

SELECT *
FROM TestIndex

You will see a row again after you run the sys.dm_db_index_usage_stats query
Also note that every individual seek, scan, lookup, or update on the specified index by one query execution is counted as a use of that index and increments the corresponding counter in this view. Information is reported both for operations caused by user-submitted queries, and for operations caused by internally generated queries, such as scans for gathering statistics.

The user_updates counter indicates the level of maintenance on the index caused by insert, update, or delete operations on the underlying table or view. You can use this view to determine which indexes are used only lightly all by your applications. You can also use the view to determine which indexes are incurring maintenance overhead. You may want to consider dropping indexes that incur maintenance overhead, but are not used for queries, or are only infrequently used for queries.


sys.dm_db_index_usage_stats

database_id smallint
ID of the database on which the table or view is defined.

object_id int
ID of the table or view on which the index is defined

index_id int
ID of the index.

user_seeks bigint
Number of seeks by user queries.

user_scans bigint
Number of scans by user queries.

user_lookups bigint
Number of lookups by user queries.

user_updates bigint
Number of updates by user queries.

last_user_seek datetime
Time of last user seek

last_user_scan datetime
Time of last user scan.

last_user_lookup datetime
Time of last user lookup.

last_user_update datetime
Time of last user update.

system_seeks bigint
Number of seeks by system queries.

system_scans bigint
Number of scans by system queries.

system_lookups bigint
Number of lookups by system queries.

system_updates bigint
Number of updates by system queries.

last_system_seek datetime
Time of last system seek.

last_system_scan datetime
Time of last system scan.

last_system_lookup datetime
Time of last system lookup.

last_system_update datetime
Time of last system update.