13Aug 2008 by Grant Fritchey 18 Comments

View vs. Table Valued Function vs. Multi-Statement Table Valued Function

T-SQL
About five years ago, I was checking an app before it went to production. I hadn't seen the app before then and a junior dba had worked with the developers designing and building the app. It didn't use a single stored procedure or view. Instead, it was built entirely of multi-statement UDF's. These UDF's called other UDF's which joined to UDF's... It was actually a very beautiful design in terms of using the functions more or less like objects within the database. Amazing. It also would not, and could not, perform enough to function, let alone scale. It was a horror because they thought they were done and ready to go to production, but no one had ever tested more than a couple of rows of data in any of…
Read More
08Aug 2008 by Grant Fritchey No Comments

SQLPLAN Glitch

SQL Server, T-SQL
While I was doing some work for Andy Warren (more on this after Sept 1st), I came across an interesting little glitch when saving XML execution plans out as SQLPlan files. It's easy enough to replicate. Just get an XML execution plan from your query: SET STATISTITCS XML ON; SELECT... Click on the link to open the XML plan. Click on the "File" menu and then the "Save As" menu item. It opens the familiar file save window. Click on the "Save as type" drop down and switch to "All Files (*.*)" Save the file with an extension of ".sqlplan." Good. Now you've got an execution plan file that can be opened and viewed as a GUI execution plan. Without closing the XML, try to open this new plan. You…
Read More
06Aug 2008 by Grant Fritchey No Comments

Deadlocks vs. Blocks

SQL Server, T-SQL
It makes me crazy when I interview someone who has five or more years as a DBA, but they don't know the difference between a block and a deadlock. It's a complete showstopper for me. If you don't know this, you're an entry-level DBA, don't talk to me about your years of experience. Sorry, but there it is. Here's someone that's kinder than I am in every way. Not only have they cut people slack on this question, but he's provided a well done answer to the question. For those who may interview with me in the future, go and read this and understand it.
Read More
09Jul 2008 by Grant Fritchey No Comments

Serious Error

T-SQL
When I wrote the book "Dissecting SQL Server Execution Plans" I knew I was going to get things wrong. Several people have pointed out things over the last couple of months. They've all been in the details. None of them were serious errors of fact. Andy Warren just found a huge one. In the section on Table Hints I detail how to apply an INDEX() hint. It's on page 123 in the electronic version or 124 of the first print version. I state that index number starts at 0 with the clustered index. That's just flat wrong. A clustered index is always 1. A 0 indicates a heap. Other indexes will have values greater than 1. If you were to supply a 0 to the INDEX() hint, as shown in the book, it forces either…
Read More
02Jul 2008 by Grant Fritchey 1 Comment

Code from "Dissecting SQL Server Execution Plans"

T-SQL
This is the complete code listing from the book "Dissecting SQL Server Execution Plans." You need a copy of AdventureWorks. Please note, AdventureWorks changes. It changed three times while I wrote the book. These changes can be very subtle causing variations in statistics which will make some of the queries generate execution plans in a different manner than what was published in the book. Some of these changes can be pretty radical causing the queries to not work at all. Also, the book went through quite a few edits including rearranging the order in which sections appear. This listing is the order in which things were written and it might vary from the book. In other words, caveat emptor, your mileage may vary, keep your hands and feet inside the vehicle…
Read More
01Jul 2008 by Grant Fritchey 10 Comments

Constant Scan in Execution Plans

SQL Server, T-SQL
I see a lot of searches from people apparently trying to find out what having a Constant Scan in their execution plan means. I can understand why. Here's the definition from the Books Online: The Constant Scan operator introduces one or more constant rows into a query. A Compute Scalar operator is often used to add columns to a row produced by a Constant Scan operator. OK. Very precise and yet, unless you know what the sentence means, reading it can be pretty confusing. The key is to see what Compute Scalar means: The Compute Scalar operator evaluates an expression to produce a computed scalar value. This may then be returned to the user, referenced elsewhere in the query, or both. An example of both is in a filter predicate…
Read More
23Jun 2008 by Grant Fritchey No Comments

Breaking Down Complex Execution Plans

SQL Server, T-SQL
Peter Ward, the editor at SQL Server Performance, has published an article of mine on Breaking Down Complex Execution Plans. I go way beyond the blog entry below and show how the estimated costs in execution plans can mess you up, how to use the XML in execution plans to search through them for costly operations or operations that have mismatched estimated rows & actual rows and some other tips and tricks. Hopefully it's worth a read.
Read More
13Jun 2008 by Grant Fritchey 1 Comment

Why are Subqueries Dangerous?

T-SQL
If you go around to the various forums, you'll see postings, including some I've put up, that say using subqueries, especially correlated subqueries in the SELECT statements of queries is bad because it effectively acts as a cursor. I got called on it. So I had to do a bit of research. Books Online talks about it right off when describing subqueries. That's not proof though. I did some more looking around. Adam Machanic does a nice job of slicing up Functions, which are basically the same thing. But it's not exactly the same. I kept looking. This blog entry is just flat wrong, but the second comment points out the fallacy. Jeff Moden would also like this example since it shows the disparity between the actual cost of queries…
Read More