23Sep 2014 by Grant Fritchey 8 Comments

SQL Server Query Performance Tuning

SQL Server, T-SQL
The latest update to my book, SQL Server Query Performance Tuning was released last week. This is the fourth edition of the book, and the third edition that I've been responsible for. At the urging of my editor, Jonathan Gennick, I have completely restructured the book for this release. The chapters have been broken up and rearranged so that they're smaller, more easily consumed. Yes, I've worked with my technical editor, Joe Sack, to add lots of new information and to ensure that the existing information is more accurate and more useful. But, we've also added new chapters on topics that weren't given enough attention in the previous versions of the book, such as parameter sniffing. It can certainly seem like these book releases are just some incremental changes on top of…
Read More
16Sep 2014 by Grant Fritchey No Comments

PASS Summit 2014 Pre-Conference Seminar

PASS, T-SQL
I'm putting on a pre-conference seminar (also known as a pre-con) at the PASS Summit this year. I'm really honored to be able to present this and I'm pretty excited about it. So, if you want to talk query tuning, let's get together at the Summit. For a few fun facts about the event, check out this Q&A over at PASS. To register for the event and my pre-con, go here now.
Read More
03Sep 2014 by Grant Fritchey 12 Comments

Left or Right?

SQL Server, T-SQL
No, this is not about politics. It's about your WHERE clause... and your JOIN criteria... and your HAVING clause. It's about a canard that still makes the rounds occasionally. Please, help me put this statement to sleep for once and all: A function on the left side of the equals sign can lead to performance problems Well, you know, it's sort of true. But then, a function on the right side of the equals sign can also lead to performance problems. In short, it's not the placement of the function that causes issues, it's the function that causes issues. Let's take a look at a really simple example: SELECT a.AddressID, a.AddressLine1, AddressLine2 FROM Person.Address AS a WHERE a.AddressLine1 = 'Downshire Way'; This simple query results in an equally simple execution plan: Now,…
Read More
20Aug 2014 by Grant Fritchey 2 Comments

The Red Gate Way…

DevOps, PASS, Professional Development, Redgate Software, SQL Server, T-SQL
As companies go, Red Gate is a little different. That is readily apparent in our tools and the philosophy behind them, ingeniously simple. But, we do a lot of other things too. There's the Simple-Talk web site where we publish serious articles on all aspects of development and database administration across platforms and programming languages. There's SQL Server Central, the single largest SQL Server community on the planet. There's Ask SQL Server where you can get direct answers to your direct questions about SQL Server. If all that's not enough, there are all the books, which we give away for free, on, again, all aspects of programming and database administration. But, we like to do more, so we also bring you training, the Red Gate way, at the SQL in…
Read More
14Aug 2014 by Grant Fritchey No Comments

A Full Day of Query Tuning

SQL Server, T-SQL
I'm excited to able to say that I've been given the opportunity to put on a full day workshop at SQL Connections on Friday, September 19th, 2014. The title is "Query Performance Tuning in SQL Server 2014", but I assure you we're going to cover things that are applicable if you're still working on SQL Server 2005. We'll start the day covering the different mechanisms you have to capture query metrics. We'll go over dynamic management objects and extended events that are incredibly important to you in understanding which queries you need to tune. We'll get an introduction into how the optimizer works and the importance that statistics, indexes and constraints play in helping the optimizer make the choices it makes. I promise, execution plans will be covered throughout the…
Read More
15Jul 2014 by Grant Fritchey 2 Comments

Execution Plan Details

PASS, SQL Server, T-SQL
I wouldn't say it's common knowledge that you should look at execution plans when tuning queries, but it's not exactly uncommon knowledge either. But, people tend to get focused on just looking at the graphical part of the plan and there's just not enough information there. Let's take a look at a query: SELECT pc.Name, ps.Name, v.Name, pr.ReviewerName, p.Name, v.ModifiedDate, p.Color FROM Production.Product AS p LEFT JOIN Production.ProductReview AS pr ON pr.ProductID = p.ProductID JOIN Production.ProductSubcategory AS ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID JOIN Production.ProductCategory AS pc ON pc.ProductCategoryID = ps.ProductCategoryID JOIN Purchasing.ProductVendor AS pv JOIN Purchasing.Vendor AS v ON v.BusinessEntityID = pv.BusinessEntityID ON pv.ProductID = p.ProductID WHERE v.ModifiedDate = '2006-02-17 00:00:00.000' AND p.Color LIKE 'Y%'; This generates an execution plan that looks like this: Neither v.ModifiedDate nor p.Color have indexes.…
Read More
02Jul 2014 by Grant Fritchey 5 Comments

Statistics and Natively Compiled Procedures

T-SQL
Statistics are one of the single most important driving factors for the behavior of the query optimizer. The cardinality estimates stored within the statistics drive costing and costing drives the decision making of the optimizer. So, how does this work with the new SQL Server 2014 natively compiled procedures? Differently. In-memory tables do not maintain their statistics automatically. Further, you can't run DBCC SHOW_STATISTICS to get information about those statistics, so you can't tell if they're out of date or not or what the distribution of the data is within them. So, if I create some memory optimized tables, skip loading any data into them and then run this standard query: SELECT a.AddressLine1, a.City, a.PostalCode, sp.Name AS StateProvinceName, cr.Name AS CountryName FROM dbo.Address AS a JOIN dbo.StateProvince AS sp ON sp.StateProvinceID =…
Read More
25Jun 2014 by Grant Fritchey 2 Comments

The Utility of Execution Plans in Natively Compiled Procedures

T-SQL
I'm actually having problems identifying the utility of execution plans when working with natively compiled procedures. Or, put another way, why bother? I've posted a couple of times on natively compiled procedures and SQL Server execution plans. I've found the differences interesting and enlightening, but I'm seriously questioning why I should bother, at least currently. I'm sure there will be many changes to the behaviors of the natively compiled procedures and their relationship with execution plans. But right now, well, let's look at an example. I have three simple tables stored in-memory. Here's the definition of one: CREATE TABLE dbo.Address ( AddressID INT IDENTITY(1, 1) NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 50000), AddressLine1 NVARCHAR(60) NOT NULL, AddressLine2 NVARCHAR(60) NULL, City NVARCHAR(30) COLLATE Latin1_General_100_BIN2 NOT NULL, StateProvinceID INT…
Read More
05Jun 2014 by Grant Fritchey 2 Comments

Natively Compiled Procedures and Execution Plans

T-SQL
The combination of in-memory tables and natively compiled procedures in SQL Server 2014 makes for some seriously screaming fast performance. Add in all the cool functionality around optimistic locking, hash indexes and all the rest, and we're talking about a fundamental shift in behavior. But... Ah, you knew that was coming. But, you can still write bad T-SQL or your statistics can get out of date or you can choose the wrong index, or any of the other standard problems that come up that can negatively impact all those lovely performance enhancements. Then what? Well, same as before, take a look at the execution plan to understand how the optimizer has resolved your queries. But... Yeah, another one. But, things are a little different with the natively compiled procedures and…
Read More
01Apr 2014 by Grant Fritchey 15 Comments

SQL Server 2014 New Defaults

T-SQL
Today, April 1st, 2014, marks the release of SQL Server 2014. There are tons and tons of great new methods and functions and processes within the product. We're all going to be learning about them for quite a while to come. One of the most exciting though is one of the changes to the defaults. In the past there's been a lot of debate around how best to configure your databases. What cost threshold should be set for parallelism, the max degree of parallelism, memory settings, auto growth, and all sorts of other settings affect how your databases work. But, Microsoft has finally done something smart. They've bowed to the pressure of hundreds and hundreds of DBAs, Database Developers and Developers around the world. They've finally done the one thing…
Read More