24May 2016 by Grant Fritchey 3 Comments

On the Buckeye Blitz!

T-SQL
In just a few weeks I'll be doing the Buckeye Blitz. That is, a tour of user groups in Ohio (aka, the Buckeye state, after a tree, not a sports team), one per day across a week. Here's how it breaks down: Cleveland: 6/13 Toledo: 6/14 Columbus: 6/15 Cincinnati: 6/16 I'll be talking on this topic at each of the groups: Change Your Habits: Tips to Tune Your T-SQL T-SQL proides many different ways to accomplish the same task, and as you might expect, some ways are better than others. In this session, you will learn specific techniques, that when followed make you a better T-SQL developer. The session is jam-packed with practical examples and is designed for administrators and developers who want to bring their T-SQL skills to the…
Read More
16May 2016 by Grant Fritchey 8 Comments

Query Store, Forced Plans, and New Plans

Azure, SQL Server 2016
I love questions. I recently received one about new plans in the Query Store (available in Azure SQL Database now and in SQL Server 2016 after June 1). Let's say you have selected a plan that you want to force. You set it up. Now, let's say the plan ages out of cache or even goes through a recompile. During the recompile, due to out of date statistics or skew in the statistics, you would, under normal circumstances, get a new plan. However, with Query Store and plan forcing, the plan that's going to be used is the plan that is being forced. But, does that other plan, the one not used, get stored in Query Store? I have no idea. Let's find out. The Setup To start with, a small stored procedure…
Read More
03May 2016 by Grant Fritchey 5 Comments

Implicit Conversion and Performance

SQL Server, SQL Server 2016, T-SQL
Letting SQL Server change data types automatically can seriously impact performance in a negative way. Because a calculation has to be run on each column, you can't get an index seek. Instead, you're forced to use a scan. I can demonstrate this pretty simply. Here's a script that sets up a test table with three columns and three indexes and tosses a couple of rows in: CREATE TABLE dbo.ConvertTest ( BigIntColumn BIGINT NOT NULL, IntColumn INT NOT NULL, DateColumn VARCHAR(30) ); CREATE INDEX BigIntIndex ON dbo.ConvertTest (BigIntColumn); CREATE INDEX IntIndex ON dbo.ConvertTest (IntColumn); CREATE INDEX DateIndex ON dbo.ConvertTest (DateColumn); WITH Nums AS (SELECT TOP (1000000) ROW_NUMBER() OVER (ORDER BY (SELECT 1 )) AS n FROM master.sys.all_columns ac1 CROSS JOIN master.sys.all_columns ac2 ) INSERT INTO dbo.ConvertTest (BigIntColumn, IntColumn, DateColumn ) SELECT Nums.n, Nums.n,…
Read More
18Jan 2016 by Grant Fritchey 15 Comments

Removing All SQL Server Query Store Data

Azure, SQL Server 2016
While setting up example code for my presentation at SQL Cruise (which is going to be a fantastic event), I realized I wanted to purge all the data from my Query Store, just for testing. I did a series of searches to try to track down the information and it just wasn't there. So, I did what anyone who can phrase a question in less than 140 characters should do, I posted a question to Twitter using the #sqlhelp hash tag. Jamey Johnston (t|b) came through... and it was right there in the documentation that I had been reading, over and over. In fact, it was in the documentation in two different places. Reading is clearly a problem for me today. Just so that you know, it's actually really easy:…
Read More
09Sep 2015 by Grant Fritchey 16 Comments

Yes, Foreign Keys Help Performance

SQL Server
I created this example several years ago that illustrates how foreign key constraints can help performance. It's a contrived example. Granted. I feel like it illustrates the point. However, over the years, people have questioned one aspect of it. The optimizer uses the foreign keys to figure out which tables can be eliminated from the query, making for a more efficient plan and making the query run faster. The pushback has always been, "Yeah, Grant, but nobody writes T-SQL where they include extra tables that they don't need." My initial response, after I stop laughing, is to point out any number of ORM tools. But, you know what, let's assume that's correct. No one would ever create a giant catch-all view that has all their JOINs in one place so they don't have…
Read More
06Aug 2015 by Grant Fritchey 1 Comment

Reading Your Execution Plans

SQL Server
I'm putting the finishing touches on the all day seminar on execution plans that I'll be putting on at DevConnections this year. I have tons of examples to show you how to interpret execution plans as part of query performance tuning. We'll be able to fill our time. However, I've got a pretty high degree of flexibility on which examples I use. With that in mind, I'd love it if you could bring in your own execution plans that you'd like some help reading. I won't guarantee a solution for your query problems, but I promise to read through it and make some suggestions. If you have an execution plan that you don't mind sharing with the group and you'd like a little consulting time on tuning the query, bring it…
Read More
03Aug 2015 by Grant Fritchey 6 Comments

Differences Between Actual & Estimated Plans

SQL Server, T-SQL
I have, in the past, made way too much of the need for Actual Plans when doing performance troubleshooting. The primary reason for this is to get the Actual Plan in order to see the differences between the Actual and Estimated Row Counts as a means of understanding how the optimizer saw the data. But, is that the only thing that's different between Actual & Estimated Plans? Well, pretty much, yeah. I took two fairly average execution plans from SQL Server 2014 and ran them through Altova's XML Spy, which does XML comparisons similar to how Redgate SQL Compare will compare two data structures for you. Here is every single difference I found. Everything was additional information in the Actual Plan. In the information for the first operator, in my case,…
Read More
06Jul 2015 by Grant Fritchey 4 Comments

But I Don’t Have a Test Server…

Database Lifecycle Management, DevOps, SQL Server, T-SQL
I frequently see statements on forums along the lines of "I don't have a test server, so I'm going to do something I've never done before directly on my production servers..." This is usually followed by questions along the lines of: But that's OK and I won't get fired, right? So how do I know if it worked? Is that dangerous? The replies are: No. You should be fired You won't By All the Gods! Yes! It's stupidly, insanely, I don't really like my production server, my data, my boss, or my job, dangerous. Yes. I understand. You're working for a not-for-profit, so you can't afford tons of new servers. You're looking at a 50tb production server of which, you can't make a copy. Your bosses just don't want to spend the…
Read More
26May 2015 by Grant Fritchey 11 Comments

Database Engine Tuning Advisor

Azure, SQL Server, T-SQL
I would love to see the Database Engine Tuning Advisor (DTA) pulled from the product. Completely. Heck, I feel bad that I included a chapter on it in my query tuning book (all updated for SQL Server 2014 by the way). Let me tell you why we need to pull this tool. First, I understand its purpose. It's supposed to be a fast and easy way to get some performance tuning done for people who just don't have the time or knowledge to go through the full process of gathering metrics, evaluating poor performers, understanding root causes and applying indexes to fix those causes. I also readily acknowledge that it actually is an amazing piece of software. If you don't agree with that, go read this white paper. With those acknowledgements…
Read More
11May 2015 by Grant Fritchey 13 Comments

Is Performance Better With LEFT JOIN or RIGHT JOIN?

T-SQL
I tend to write my queries using LEFT JOIN. Why? Because logically I see it in my head like this: Give me all the rows from this table and only those rows that match from the other table. But, wouldn't this logic work just as well: Give me only the rows in this table that match the rows from this other table where I'm selecting all of them. I know. If I worked on it some more I could make that a better sentence, but I'm pretty sure the logic is still sound. Only matching rows from one data set, all the rows from another data set. In short, RIGHT JOIN. I read recently that we ought to be making everything into a LEFT JOIN because it performs better. I suspect…
Read More