04Oct 2010 by Grant Fritchey 1 Comment

How to Tell if Execution Plans are Reused

SQL Server, T-SQL
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…
Read More
27Sep 2010 by Grant Fritchey 3 Comments

Parameter Name Size And Performance

SQL Server, T-SQL
I saw an odd statement the other day, "The size of the name of the parameter does not affect performance." My first thought was, "Well, duh!" But then, I had one of those, "Ah, but are you sure" thoughts. And you know what, I wasn't sure. If size of the parameter name did affect performance, I figured, the one sure place where that would be evident is in the size of the execution plan. Right? I mean, if there was an impact on memory, and hence on performance, that's probably where you'd see evidence of it. I wrote two queries: DECLARE @ThisIsAVeryVeryLongParameterNameThatIsTrulyRidiculousButItIllustratesThePointThatParameterLengthDoesNotAffectPerformance int SET @ThisIsAVeryVeryLongParameterNameThatIsTrulyRidiculousButItIllustratesThePointThatParameterLengthDoesNotAffectPerformance = 572 SELECT soh.SalesOrderID ,sod.SalesOrderDetailID FROM Sales.SalesOrderHeader AS soh JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID WHERE soh.SalesOrderID = @ThisIsAVeryVeryLongParameterNameThatIsTrulyRidiculousButItIllustratesThePointThatParameterLengthDoesNotAffectPerformance DECLARE @v int SET…
Read More
11Aug 2010 by Grant Fritchey No Comments

Viva Las Vegas!

SQL Server, T-SQL
I won't be going to Las Vegas, but I will be presenting to the Las Vegas SQL Server Users Group, S3OLV. The sesssion will be "Introduction to Execution Plans." Please swing by if you're in the area. I'm not sure if they'll make the LiveMeeting available to the public or if they'll record the session. But if they do, please attend that way too.
Read More
06Oct 2009 by Grant Fritchey No Comments

Hey, ho, where’d you go…

PASS
Ohio? I'm presenting on Thursday to the Columbus SQL Server Users Group, home of the newly minted MVP, Jeremiah Peschka (congrats again). It's to be a virtual presentation through live meeting. The topic is a Understanding Execution Plans. This time I hope that one of us remembers to hit the record button unlike last time when I did this presentation for the PASS AppDev Virtual Chapter. If you're in the area, come on down and meet me, virtually. Show runs from 6:30-8:30, although all that time is not my presentation, so I suspect Jeremiah has some more fun planned.
Read More
22Sep 2009 by Grant Fritchey No Comments

Gila Monster on Estimated vs. Actual Row Counts

SQL Server, T-SQL
I don't generally do lots of blog aggregation and cross post linking & stuff. It's just not something I'm that into. However, this time is an exception. Gail Shaw, Gila Monster to those who hang on out SQL Server Central, has posted an excellent explanation of times when Estimated and Actual row counts vary for a reason. I'm one of those who emphasises that differences between estimated & actual is an indication of... something. It could be out of date or missing statistics or it could be caused by query language like multi-statement table valued functions, but it's usually and indication of a problem. Except when it's not. Read Gail's explanation for more.
Read More
15Sep 2009 by Grant Fritchey 30 Comments

No Join Predicate

SQL Server, T-SQL
You could be looking at an execution plan on a query and see this message: Warning, No Join Predicate. With a very few exceptions (very few), that's not a warning, like "Mind the gap" or "Your Mileage May Vary" or "Never fight a land war in Asia." No. It's a screaming shout saying "BY ALL THE GODS IN VALHALA, YOU DON'T HAVE ANY JOIN PREDICATES IN THIS QUERY!" Seriously, that's exactly what it says. But, you might be asking yourself, that's what it says, but what does it mean? Please allow me to explain. The tables in your system, whether it's a classic BI star schema, or a highly normalized OLTP system, or even (shudder) ORM objects, are related to one another. Usually they're related through the use of primary…
Read More
09Sep 2009 by Grant Fritchey 8 Comments

Spools in Execution Plans

SQL Server, T-SQL
I got the question the other day, when are you likely to see a spool in an execution plan? Easy, whenever SQL Server needs to walk through the data multiple times, usually in JOIN operations... Yeah, well, once again, my flip answers are not quite the entire story. Spool operations are temporary storage of the data for later reuse in a query plan. There are two types of spool operations, eager spool and lazy spool. A spool is basically a temporary table created within the execution of the query that is used when it's likely that data will be needed again, and again during the execution of the query. This is not an explicit #temp temporary table, but a work table for operations within the processing necessary for a given query's…
Read More
17Jul 2009 by Grant Fritchey 15 Comments

Execution Plan Compile Termination

SQL Server, T-SQL
Recently I've been seeing a lot of people with bad execution plans, desperately trying to tune them, but they were unable to explain why they had such bad plans. More often than no these were larger queries, with a number of derived tables, CTE's, CROSS APPLY, etc. In most cases the statistics appeared to be fine (this is usually checked by comparing estimated & actual rows within the operations in the execution plan) and the plans themselves didn't look crazy, but the execution plans were flat out, not good. If you're looking at a plan and it doesn't make much sense, one option that most people don't check... SQL Server didn't have enough time to complete optimization. The optimizer is a pretty amazing bit of code. The scary volume of…
Read More
26Jun 2009 by Grant Fritchey No Comments

Re-evaluating Execution Plans (again)

SQL Server, T-SQL
I keep thinking I've got a handle on the way execution plans are dealt with in SQL Server. I had a pretty simplistic view of things, there's the estimated plan which comes out of the optimizer and there's the actual plan which comes out of the data engine. The one shows the best guess for what will happen based on the query and the underlying statistics. The other shows what actually happened based on the query and the real data, load on the server, available memory, you get the idea. This model is easy to explain and understand. Too bad it's not quite the way things work. If you query the dynamic management function sys.dm_exec_query_plan, you can see a query plan. Once you drill down on the XML, or browse…
Read More