I've run into a few issues where a developer may have unintentionally created a stored procedure that hits a table twice for the same info. Usually, this is due to logic in the procedure and it's not that hard of a fix once it's found.
If I have the query I can go with SET STATISTICS IO ON and see the double work, but what if you don't have the query to start with.
One way I've gone about it is by using profiler to capture the scans and then drilling down from there.
Does anyone know of other ways to track down stored procedures using profiler that may be doing double work?
asked Nov 10 '09 at 10:59 AM in Default
I know this doesn't directly answer your question, but if you want to find every procedure that references a table more than once, this will work.
In SQL Server 2000, the syscomments system table contains the text for all stored procedures. For SQL Server 2005 and 2008, this has been replaced by sys.sql_modules. The biggest difference is that syscomments contains multiple rows for the same procedure if it is over 4000 characters. This is not necessary with sys.sql_modules because it uses the nvarchar(max) data type.
Please note: The following script will search the procedure text for whatever you specify for @TableName. If the name is something like "SpecialCustomerTable", you will probably get good results. However, it could return too matches if your table name is a common word used in comments or other places.
answered Nov 10 '09 at 11:57 AM
It's kind of hard to define "double work" because a given query might legitimately hit a table multiple times. However, one approach you could use is to query the plan cache using XQuery. You could look for plans that reference a table more than once. That's only going to capture the stuff in cache. Depending on your system and how fast it's flushing the cache, you might need to run the query more than once a day.
answered Nov 11 '09 at 09:35 AM
Grant Fritchey ♦♦