It's not enough to look at the longest running query. What if you have two queries, one runs for 5 minutes and the other runs for 5 seconds. Which do you tune? The first one, of course. But, let's add a little information to our thought experiment. The one that runs for 5 minutes is called 2AM, your local time, when there are almost no users on the system and the one that runs for 5 seconds is called 40 times a minute all day long. Now, which one do you tune? That's right, suddenly that 5 second query takes on a HUGE significance based on how often it's called. But how do you know how often a query is called? The easiest way to gather that information is not…
I saw this question and my immediate thought was "Well, duh, the execution plan is recreated by a recompile." But, someone a bit smarter than myself suggested that, in fact, no plan was stored in cache, forcing a new plan to be created each time the query was run. So, which is it? Does a plan get added to cache and then removed every time the procedure is called, or do you get nothing in cache and the "recompile" is actually a compile every time? As Mr. Owl says, let's find out. I have a small script that looks like this: CREATE TABLE [dbo].[Test]( [col] [varchar] (10) NULL ); CREATE TABLE [dbo].[Test2] ( [col] VARCHAR(10) NULL ); INSERT INTO dbo.Test (col) VALUES ('Val1'), ('Val2'), Â ('Val3') ; INSERT INTO dbo.Test2…
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…
In my previous post, Spatial Data Hurts My Brain, I showed how a query used the spatial index, but hurt performance. Several people jumped in to try to help out. Thanks to Bob Beauchamin, Isaac Kunin, Gail Shaw, and Valerie Yakich (via Twitter). I've definately learned a bit more than I knew previously about spatial data and spatial indexes. I've posted about it before, but it bears repeating, if you're just starting out, I can't recommend Alistair Aitchison's book, Beginning Spatial with SQL Server 2008, enough. Here's where I'm at. I think I was confusing/confused/confounded/something about what to expect from a spatial index. I'm going to present two queries and two indexes and try to explain why each works well, or not together, mainly as a means for enabling my…
I'm still barely scratching the surface working with spatial data in SQL Server 2008. We've ported some of the data into a table where we built a geography spatial data column and we're begginning to work with point data. The requirements from the developers are, so far, very simple. They'll feed me a point and I find all the locations "close" to it. We had to go round & round on what defines "close" but finally settled on, I think, 15km. The query to answer a question like this is ridiculously simple (a few object names have been changed): SELECT ebe.[Location].STDistance(@Location) AS Distance, ebe.[InterestId], ebe.[Location].Lat AS Latitude, ebe.[Location].Long AS Longitude, ebe.[OrgId] FROM dbo.[ebe] AS ebe WHERE ebe[OrgId] = @OrgId AND ebe.[Location].STDistance(@Location) < @CloseDistance I'm not even hard-coding the "close" value…
You read that correctly, three kinds of execution plans. You may have thought that all you had to deal with are estimated and actual, but there is one more. The estimated plan is the plan that comes out of the optimizer. It's based on statistics and indexes and known objects within the system. The actual plan is the plan that was used to execute the query and will show all the actual number of rows processed, etc. It might be different than the estimated plan because the stastics were off or for any number of other reasons. Those were the ones you knew about. There is also the plan that gets stored in the plan cache, the compiled plan. I lied. The compiled plan and the estimated plan are the…
This code is not in the same order as the book. A number of edits were done to the document after it was produced. USE [AdventureWorks]; GO --Listing 1 --Select --highlight this and click "Display Estimated Plan" on tool bar, right click & select from menu, --select from the Query menu above, or type CTL-L. SELECT * FROM [dbo].[DatabaseLog]; GO --Listing 2 --SelectJoin -- click "Include Actual Excecution Plan" on tool bar, highlight and execute SELECT e.[Title] ,a.[City] ,c.[LastName] + ',' + c.[FirstName] AS EmployeeName FROM [HumanResources].[Employee] e JOIN [HumanResources].[EmployeeAddress] ed ON e.[EmployeeID] = ed.[EmployeeID] JOIN [Person].[Address] a ON [ed].[AddressID] = [a].[AddressID] JOIN [Person].[Contact] c ON e.[ContactID] = c.[ContactID] ; --Listing 3 --SelectJoin2 SELECT e.[Title] ,a.[City] ,c.[LastName] + ',' + c.[FirstName] AS EmployeeName FROM [HumanResources].[Employee] e JOIN [HumanResources].[EmployeeAddress] ed ON…
I've seen this question posted in a lot places and I've seen the search come in to the blog: "How do you break down a complex execution plan?" The short answer; just like eating an elephant, one bite at a time. The longer answer... First you have to define what you mean by a complex execution plan. For example, I've seen 16 page stored procedures that consist of about 50 or more different statements executed in series (and I 've heard of worse). No single statement was very big, but trying to dig through all the statements to identify which may be causing slow execution was a problem. This is the easiest type of complex execution plan to solve. In SQL Server 2005 and 2008, when you turn on a graphical…
I was asked if I would look at a new tool from a company I hadn't heard of. It's SQL Inspect from Yohz Software. Nominally this is a SQL query editor. However, strictly as a query editor, especially when compared to what's available in SQL 2008 or what tools like Red Gate's SQLPrompt or SQLRefactor can do for you, it's not so hot. Luckily, that's not where its strengths lie. Instead, it's all about performance tuning your queries and it does this very well indeed. It takes a query and returns a tree structured execution plan, looking a bit like the old text plans, but much more sophisticated with roll-ups, etc. It shows you all the details of the operations, just like an execution plan, but immediately accessible on the screen,…