Entity Framework was squirting raw SELECT statements at the database and causing deadlocks.
To fix, I captured the query text with sp_BlitzLock and executed it in Plan Explorer.
Plan Explorer confirmed that the data was being retrieved using a non-clustered index combined with the clustered-index (ahah!)
The Plan Explorer / Index Analysis tab, showed the non-clustered index had failed to retrieve over 15 columns.
I was able to create a new index that covered 100% of the columns within the Index Analysis screen.
I executed the query again to confirm it was no longer using the clustered index, and was therefore quicker and less likely to cause a deadlock.
I notice the output from sp_BlitzLock surfaces object_id’s in the query column.
It is a simple matter to decode object_id’s like …
… where SomeNumber is the object id.
Sometimes its hard to see the wood for the trees. With over 30 indexes on a table of 50 columns I searched for some graphical way to list the columns against each index so I could easily see a) indexes that were totally encapsulated in a larger one. And b) almost identical indexes where a column (or two) could be added to one so the smaller could be dropped.
Initially it was sp_BlitzIndex that named the tables with too many indexes. The results from which I ran in SentryOne’s Plan Explorer like … select * from dbo.order_items; … or whatever.
Some time later :), in the Index Analysis tab I was able to choose tics to show every column and hey presto! The exact graphical tool I wanted 🙂 And a bonus of an easy way to manipulate them.
But watch out! you need another tool to rank the read/write ratio of each index before you start making changes (I use my old ‘indexmaint’ script).