September 15, 2013 at 10:01 pm
Hello. I was making some minor changes to indexes the other day. The next day I noticed our Work Files Per Minute counter for the instance I was working on had jumped from about 20k to 175k. Looking at historical data, this counter has always been down around 20k and the jump occured at the exact time I was making changes to indexes.
I kept a log of the "major" index changes I made, and I have undone time, but to no avail: the counter is still north of 150k, always.
I understand Work Files per Minute are generated from hash joins, which I most certainly could have affected by changing indexes around.
Is there a way for my to track down which query plans are generating the increased number of hash joins, or some how see what exactly is creating these work files?
Thanks!
-DaveL
September 16, 2013 at 3:53 pm
dave-L (9/15/2013)
...Is there a way for my to track down which query plans are generating the increased number of hash joins, or some how see what exactly is creating these work files?...
You sure can check the plans in cache, and search the XML for "Hash Match" occuring.
This might give you a start
SELECT * FROM sys.dm_exec_cached_plans AS dm_exec_cached_plans
CROSS APPLY sys.dm_exec_sql_text(dm_exec_cached_plans.plan_handle) dm_exec_sql_text
CROSS APPLY sys.dm_exec_query_plan(dm_exec_cached_plans.plan_handle) dm_exec_query_plan
you can then use the nodes function to serach the XML from the plan
Andreas
---------------------------------------------------
MVP SQL Server
Microsoft Certified Master SQL Server 2008
Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.insidesql.org/blogs/andreaswolter
www.andreas-wolter.com
September 17, 2013 at 3:20 pm
When you add an index on a table, all query plans for that table are flushed from the cache and the queries are recompiled. If you have queries on the pattern "give me all that happened today", it is not unlikely that statistics will say "there is nothing today", why SQL Server will choose a plan from that. But unfortunately, you have a million rows for today.
So updating the statistics for the concerned tables can help. Then again, it is necessarily the statistics on the concerned tables that are out of whack.
Since searching the query plans for hash joins requires a lot of XQuery, I would be lazy and look in dm_exec_query_stats to find querys with a lot of physical IO. Preferably by sampling some hours apart and compute the delta.
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply