SQL Saturday in New England

October 4, 2010 at 9:41 am (PASS, SQLServerPedia Syndication) (, , , , , )

Adam Machanic (blog|twitter) has put on a SQL Saturday/Data camp event in New England for the last two years. I’ve helped him both years. It’s been very successful. In January we had over 300 attendees, making it one of the larger SQL Saturday events. But, with a single exception (thank you Tim Ford (blog|twitter)), we’ve only had local speakers. Mind you, we’re somewhat lucky with speakers here in New England and have several MVPs and others who are truly excellent when presenting.

I’m taking over from Adam to lead the effort for this year, and due to my schedule we’re moving the event to the spring sometime. We were thinking about maybe making it the the weekend before SQL Rally. But, I’ve got a question for all of you who present at SQL Saturday events. Will you show up? Will you be more, or less, likely to come if it’s near SQL Rally. Will you be likely to come, period, full stop? While I strongly believe Adam has put on a magnificent show for two years running, for some reason we just haven’t received the community lovin’ that the other SQL Saturday events have had. Since I’m the one in charge (although Adam is still pitching in, and I’m getting help from the magnificent Mike Walsh (blog|twitter)), I’d like to make it as good a show as Adam has, so I need the other great presenters to show up, in addition to our fantastic local talent.

Comments, suggestions, questions, feedback?

PS: I hate asking questions like this on the blog, but I’m trying to collect some information so I can make a decision. Feedback is a gift, so if you want skip buying me a present for Yule this year, post a comment.

Permalink 11 Comments

How to Tell if Execution Plans are Reused

October 4, 2010 at 8:00 am (SQL Server 2005, SQL Server 2008, SQLServerPedia Syndication, TSQL) (, , , , , )

I try to watch the search phrases that point people to the blog because sometimes, you get a sense of what problems people are running into. The latest question or phrase I’ve seen a lot lately is along the lines of “how do you know if an execution plan is being reused.”

Since compiling an execution plan can be an extremely expensive operation, it’s worth your time to understand how well a given plan is getting reused. If you’ve seen me present, I’ll frequently talk about the application that had a query with an 86 table join. Recompiles on that thing were frequent and extremely costly. The only good news was, they were recompiles. If we weren’t getting plan reuse it would have been an even worse system than it was.

There are a number of ways you can see if a plan is being reused. One of the easiest is to hit the DMOs that look into the plan cache. You can look at either sys.dm_exec_procedure_stats or sys.dm_exec_query_stats. These DMOs are somewhat different and somewhat the same. Actually, they sort of cross each other. For sys.dm_exec_procedure_stats, you get aggregate information about stored procedures. For sys.dm_exec_query_stats you get aggregate information about queries, which, may be run within stored procedures. So either or both could be useful depending on what you’re attempting to measure. However, both return a very useful counter, execution_count. Quite simply, that tells you that the plan, whether for the statement or the procedure, is being reused. To get maximum gain out using either of these, you’ll want to combine them with other DMOs. Something along these lines can show you the plans for procedures that have been running against a system, ordered by the number of times they’ve been reused:

SELECT deps.execution_count ,
OBJECT_NAME(deps.object_id, deps.database_id) 'Procedure' ,
deqp.query_plan
FROM sys.dm_exec_procedure_stats AS deps
CROSS APPLY sys.dm_exec_query_plan(deps.plan_handle) AS deqp
ORDER BY deps.execution_count DESC

The only thing wrong with using the DMO like this is that you can only see what’s currently in cache. This means no history, depending on how volatile the cache is on your system.

Another way to tell if a plan is being reused, is to set up a server side trace and capture the event for the SP:CacheMiss or SP:CacheHit. This is pretty straight forward. If the query was not in, it generates a miss event. If it was there, it generates a hit. But, this has to be running in order for you to know if you had a hit or a miss. The good news is, if it’s running, you’ve got historical information since this captures the event as it occurs.

You can also catch recompile events using SQL:StmtRecompile. Yes, you can get SP:Recompile if you’re only ever dealing with procedures, but if you’ve got any kind of ad-hoc querying going on in the system or triggers, you’ll miss recompile events. Basically, because recompiles are at the statement level starting in 2005, BOL recommends only using SQL:StmtRcompile.

That’s pretty much it. Using these methods in the appropriate place will let you know if the plan is being reused or not.

Permalink 1 Comment