T-SQL

SQLTeach - Writing better queries presentation

Joe Webb — Thu, 15 May 2008 14:37:38 GMT

Here's a presentation that I gave yesterday afternoon at DevTeach/SQLTeach. It's called Tips & Tricks for Writing Better Queries. It's very similar to the presentation I gave a month or so ago at the Nashville SQL Server User Group meeting.

To everyone who attended the session - thanks for spending a part of your day with me. I hope it was worth your while. Please feel free to email me if you have any additional questions or comments. And please remember to login to your SQLTeach account and submit your session evals.

Cheers!

Joe

Finding Notification Services Instances

Joe Webb — Tue, 06 May 2008 20:31:03 GMT

As most you already know, Notification Services is not part of Microsoft SQL Server 2008. I think this is a shame since SSNS is really a great product. It may be rather complex at first glance, but it's a great product nonetheless. I'll probably devote a blog to it's abrupt deprecation at some point in the future.

In the meantime, if you're preparing to upgrade to SQL Server 2008, you should verify that you don't have any rogue SSNS instances running on any of your servers. I hope your environment is more controlled than that, but I've seen more than one shop where change control was, well in a word, uncontrolled.

So, how can you tell if a server has a SSNS installed on it? Run the following query in the msdb database. It'll list all SSNS instances installed on that SQL Server instance.

SELECT 
     InstanceName
    ,DatabaseName
FROM     msdb.NS90.NSInstances

Cheers!

Joe

Getting column information using T-SQL

Joe Webb — Sun, 27 Apr 2008 14:05:45 GMT

Ocassionally, I see a question in the MSDN Forums where someone wants to know how to retrieve a list of column information for a table using only T-SQL.

Although there are several ways in which to approach this, I like the following method.

SELECT 
   ORDINAL_POSITION
  ,COLUMN_NAME
  ,DATA_TYPE
  ,CHARACTER_MAXIMUM_LENGTH
  ,IS_NULLABLE
  ,COLUMN_DEFAULT
FROM   
  INFORMATION_SCHEMA.COLUMNS 
WHERE   
  TABLE_NAME = 'Product' 
ORDER BY 
  ORDINAL_POSITION ASC;

Do you have a different way of doing this that you'd like to share? If so, feel free to leave a comment, sharing your way and why you like it.

Cheers!

Joe

Tips & tricks for writing better queries presentation

Joe Webb — Fri, 04 Apr 2008 19:30:16 GMT

Thanks to all 60+ people who braved the flood warnings in Nashville to attend the SQL Server User Group meeting earlier today. I hope you found it to be worth your while. Some of your questions and comments at the end gave some some great ideas for future presentations. Thanks!

And thanks to Quest and RHT for sponsoring our meeting meeting today. If your in the Nashville areas, I'd encourage you to come on out for our next meeting, most likely sometime in May.

As promised, here's a link to the presentation materials, both the PowerPoint presentation and the demonstration code.

Cheers!

Joe

What SQL Server service pack do I have installed?

Joe Webb — Tue, 01 Apr 2008 22:27:49 GMT

If you've used SQL Server for a while, you're probably familiar with the @@version function. Selecting the function in a query window produces the following results on my system.

From this, you can quickly determine that I'm running SQL Server 2005 Developer Edition version 9.00.3054.00 on an Intel X86 processor. It may also appear that I've installed SQL Server SP2, however that is rather misleading. The "Service Pack 2" text in the above image refers to the operating system, not the SQL Server system.

To determine SQL Server's service pack level, use the built-in SERVERPROPERTY function with appropriate parameters - EDITION, PRODUCTLEVEL, and PRODUCTVERSION.

For example the following queries produce the results shown in the image below.

From this, you can see that I am indeed running SQL Server 2005 Developer Edition updated with Service Pack 2.

The SERVERPROPERTY function is part of SQL Server 2000 and greater. Prior to that, we had to resort to equating the product version to a service pack level. Here's a link to a KB article with more details for v7.0 and earlier.

Cheers!

Joe

Real world DBA podcast

Joe Webb — Tue, 25 Mar 2008 11:34:28 GMT

I recently worked with Buck Woody to turn one of my blog posts into a podcast. It's my first podcast! :) I recorded it about midnight one evening after everyone else in my family had retired for the evening. With the house so quiet, I didn't realize I was whispering until I heard it mixed with Buck's projecting and charismatic dialog. Here's a link to the podcast. I'd love to hear what you think and if you'd like to hear more of these.

If you're not familiar with Buck Woody's work in the SQL Server community, I would encourage you to head on over to his blog site - http://blogs.msdn.com/buckwoody/. He's putting together some great content, a mix of traditional blog posts and podcasts, called the Real world DBA. Good stuff!

Cheers!

Joe

Does order matter in a JOIN clause?

Joe Webb — Fri, 29 Feb 2008 15:15:11 GMT

A very astute SQL Server professional and reader of this blog posed the following question in a comment to a prior posting entitled "Does the order of criteria the WHERE clause matter?" The comment, submitted through Plaxo Pulse, is not available outside the Pulse community so I've included it below since it's the genesis of today's post.

"What if you were using join statements? Does it matter what order your columns are used in the ON statement? ~ Ariel M."

There are several derivatives of the original question:

Does the order of tables referenced in the ON clause of the JOIN matter?
Does the order of tables referenced in the FROM clause matter?
Does the order of columns referenced in the ON clause of the JOIN matter when multiple columns are used in the JOIN?

I'll address questions 2 and 3 in another post; for now let's consider the first question. To paraphrase and exemplify the question: Will the following two queries produce differing execution plans and thus varying performance? Or does the Query Optimizer take this into account as it analyzes a statement before choosing an execution plan?

--Query #1
SELECT 
     c.Customer_ID
    ,c.Last_Name
    ,c.First_Name
    ,s.Order_ID
    ,s.Order_Date
FROM
    dbo.Customers AS c JOIN
    dbo.Sales_Orders AS s 
	ON s.Customer_ID = c.Customer_ID

--Query #2
SELECT 
     c.Customer_ID
    ,c.Last_Name
    ,c.First_Name
    ,s.Order_ID
    ,s.Order_Date
FROM
    dbo.Customers AS c JOIN
    dbo.Sales_Orders AS s 
	ON c.Customer_ID = s.Customer_ID

Notice that the only difference in the two queries lies in the ON clause of the JOIN. The first query references Sales then Customers while the second reverses the order.

To answer this question, let's look at the execution plan as provided by SQL Server Management Studio. The first query produces the following execution plan.

In this query, SQL Server has chosen a Clustered Index Scan of the Sales_Orders table and an Index Scan for the Customers table. The two tables are joined using a Hash Match Inner Join.

Now, let's look at the execution plan for the second query.

Query #2 produced the exact same execution plan! So, we can conclude from this simple example that the order of tables referenced in the ON clause of a JOIN doesn't affect the performance of a query.

As an aside, though, both execution plans use a Hash Match Inner Join. Generally speaking this is not the most efficient join type for SQL Server; Loop Join is much more efficient. When you see a Hash Join in a query execution plan, consider your indexes. A Hash Join is frequently an indicator of inefficient indexing. I'll delve more deeply into this in another post.

Cheers!

Joe

Does the order of criteria the WHERE clause matter?

Joe Webb — Fri, 22 Feb 2008 16:37:03 GMT

Recently, I demonstrated that the order of columns in a composite index greatly determines its usefulness. Microsoft SQL Server can efficiently resolve queries using a composite index if the search criteria includes the first column in the index. If the search criteria omits the first column and includes only subsequent columns, the index is of no use to SQL Server for resolving that query. To see the proof, refer to this post.

The example I used in the prior post included the following query as a basis for the discussion.

SELECT         
	* 
FROM
	Customers 
WHERE
	Last_Name = 'smith' AND
	First_Name = 'Jake'

One reader noted the order of the search criteria in the WHERE clause and wondered if it has any impact on the applicability of a composite index. In other words, would the following query still make use of the composite index?

SELECT         
	* 
FROM         
	Customers 
WHERE         
	First_Name = 'Jake' AND         
	Last_Name = 'smith'

Great observation! To answer that question, let's once again look at the query execution plan for the first query.

From this execution plan, we can see that the query optimizer found the composite index named ix_Customer_Name to be useful in resolving the query. This is certainly to be expected since the order of search criteria in the WHERE clause exactly matched the order of columns in the composite index.

In the second query, however, the order of columns in the search criteria in the WHERE clause is reversed as compared to the composite index. Let's look at the execution plan so see if that makes any difference to SQL Server.

This query produced the exact same execution plan as the prior query. Why?

Generally speaking, the order of criteria in the WHERE clause is evaluated and optimized by the query optimizer prior to creating an execution plan. This is good. However, I would encourage you to review the query execution plan for each query prior to putting it into production. You may have some unique expressions or circumstances in your scenario that may be the exception to this rule.

Cheers!

Joe

Does the order of columns in an index matter?

Joe Webb — Wed, 13 Feb 2008 16:43:08 GMT

A single column index is fairly straightforward to understand. You may have heard it compared to the index in the back of a technical book. When you want to find some information in the book, say DBCC INPUTBUFFER, you turn to the index in the back of the book and look up DBCC INPUTBUFFER. The index doesn't actually contain the information on DBCC INPUTBUFFER, it has a pointer to the page in the book where the command is described. So, what do you do? You turn to that page and read all about how DBCC INPUTBUFFER may be used. This is a good analogy for a single column non-clustered index.

Composite Indexes

In Microsoft SQL Server, you can also create an index that contains more than one column. These are known as composite indexes. A good analogy for a composite index is the telephone book.

A telephone book lists every individual in the area who has a publicly available telephone number. It's organized not by one column, but two: last name, first name. (Ignoring the middle initial that is sometimes listed but most often treated as an extension of the person's first name). If you wanted to look up someone in the telephone book, you'd first navigate to the last name and then the first name. For example to find Jake Smith, you'd first locate the Smiths, then within the Smiths, you'd find Jake. The same holds true for a composite SQL Server index.

This is all good to know, but how does it really affect query resolution?

Well, let's consider an example. Let's assume you have a Customers table as described below.

CREATE TABLE Customers
        (
         Customer_ID INT NOT NULL
                         IDENTITY(1,1)
        ,Last_Name VARCHAR(20) NOT NULL
        ,First_Name VARCHAR(20) NOT NULL
        ,Email_Address VARCHAR(50) NULL
        )

It has a clustered index on Customer_ID and composite index on the Last_Name, First_Name columns as shown below.

CREATE CLUSTERED INDEX ix_Customer_ID 
	ON Customers(Customer_ID)

CREATE INDEX ix_Customer_Name 
	ON Customers(Last_Name, First_Name)

Finding a specific row

To find a specific row, we could execute the following query.

SELECT
        *
FROM
        Customers
WHERE
        Last_Name = 'smith' AND 
        First_Name = 'Jake'

It should be pretty obvious that the ix_Customer_Name index would work well to satisfy this query. A quick look at the execution plan confirms our expectations.

Finding a last name

Now, let's broaden our search a bit to retrieve all customers whose last name is Smith. The following query may be executed for this.

SELECT
        *
FROM
        Customers
WHERE
        Last_Name = 'smith'

Looking at the query execution plan, we can see that SQL Server did indeed use the ix_Customer_Name composite index; it performed an index seek to find the rows that satisfied the query, then it used a Key Lookup to retrieve the non-indexed column information. You'll notice that this time, however, more work was expended in the Key Lookup than in the Index Seek.

Returning to our telephone book analogy, we can see why this index was deemed efficient by the Query Optimizer. To find all of the Smiths in the telephone book, we'd navigate to the page that contains the first Smith and keep moving forward until we found something other than Smith.

Finding a first name

Now, let's see what happens if we need to find all people who have a first name of Jake. Let's execute the following query.

SELECT
        *
FROM
        Customers
WHERE
        First_Name = 'Jake'

This yields the following query execution plan.

Notice that this time, SQL Server used a Clustered Index Scan to resolve the query. This is tantamount to a complete table scan. It did not use our ix_Customer_Name index.

Once again, returning to the telephone book example, we can see why. Think about find all of the Jakes in the telephone book. You'd have to start on the first page of the book and look through every entry. Why? Because it's not organized by first name; it's organized by last name, first name.

Does this mean that composite indexes are worthless? No. They have great value to SQL Server. In our first example we were able to use the ix_Customer_Name index to navigate directly to Smith, Jake. We just need to give considerable forethought to the kinds of queries our applications will be submitting to our server and create the appropriate indexes to handle those queries.

Cheers!

Joe

Using CROSS JOIN to generate test data

Joe Webb — Wed, 06 Feb 2008 16:14:15 GMT

To prepare for an upcoming technical presentation, I need to create some test data to use in a demo. I'm planning to show how different T-SQL programming techniques directly affect SQL Server's efficiency in resolving the query. So, 10 - 20 million rows of data will likely suffice for this demo.

The question is: how to create all of that data? Obviously, a simple INSERT...VALUES statement is good for creating up to a few dozen rows of data, but 10 - 20 million rows of data is out of the question for such a simple technique.

Fortunately, SQL Server has a oft forgotten JOIN type that helps for occasions such as this. We're all pretty familiar with INNER JOIN, LEFT JOIN, and RIGHT JOIN. But are you aware of the CROSS JOIN? A CROSS JOIN takes each row from the first table and combines it with every row from the second table, resulting in a Cartesian product of the two tables. For example, if my first table has 3 rows of data - Mary, Mark, Luke - and my second table has 2 rows of data - Jones, Smith - the Cartesian product will result in 6 rows of data.

First_Name	Last_Name
Mary	Jones
Mary	Smith
Mark	Jones
Mark	Smith
Luke	Jones
Luke	Smith

So I have the "how". Now I need the "what".

A quick search on Google led me to the United States Census site where the most popular male, female, and family names are readily available. I downloaded each of those files.There were a total of 5,494 given names and 88,799 family names. I pruned the list of family names down to 2,500 since the original list would have produced a whopping 487,861,706 customers (88,799 * 5,494); far more than I required.

After importing the two lists into two tables, appropriately called Last_Names and First_Names, I used the following script to create my test data.

--clean up the imported names 
UPDATE         
	First_Names 
SET     
        Given_Name = RTRIM(Given_Name)

UPDATE
	Last_Names 
SET     
        Family_Name = RTRIM(Family_Name)

--create a very simple customers table 
CREATE TABLE Customers
        (
         Customer_ID INT NOT NULL IDENTITY(1,1)
        ,Last_Name VARCHAR(20) NOT NULL
	,First_Name VARCHAR(20) NOT NULL
	,Email_Address VARCHAR(50) NULL
	)

--create the test data 
INSERT INTO
	 Customers 
		(
	 	 Last_Name
		,First_Name
		,Email_Address
		 )
SELECT
	 f.Given_Name
	 ,l.Family_Name
	 ,f.Given_Name + '.' + l.Family_Name + '@hotmail.com'
FROM
	 First_Names AS f CROSS JOIN
	 Last_Names AS l

My new Customers table now has 13,735,000 rows in it. (A real business should be so fortunate!) I think that'll do nicely for my presentation. If not, I start over and create a 50 millions rows.

Cheers!

Joe