Free SQL Server Tools that might make your life easier

Be sure to me know which resources you use and how you get on with them.

This little beauty is fully customisable and is freely available courtesy of Michelle Ufford (aka SQL Fool) on her blog SQLFool.com

As you know, it is just not practical to use a SQL Server Maintenance Plan to manage the index optimisation of an enterprise scale database. This then leads all good DBA’s to create their own custom built script which is all well and good but why re-invent the wheel, right!

Every SQL Server DBA should have a custom Index Defrag Script in their toolbox and this one has earned a well deserved place in the performance tuning area of this site.

Get your hands on the script here at SQLFool.com

Do you have  any scripts or tools that have made your life as a DBA easier? Let me know and I will add them to the site.

"SQL Server Performance Tuning Experts"

I recently came across a post on Stackoverflow regarding the performance of using a SELECT TOP 1 query in comparison to using the MAX() function.

My initial thoughts on this were that the MAX() function would provide the best performance however, in order to be absolutely certain and prove my initial hypothesis I decided to put the theory to the test.

Create the Test Environment

To effectively test the various T-SQL statements we need some data to play with. The script below will create a table containing one million records and was adapted from the article Creating Random SQL Server Test Data by Mitchel Sellers.

Activate SQL Statistical Logging

To evaluate the performance of each of the T-SQL queries, we are going to want to review information regarding both the number of I/O requests issued by SQL Server and the time that is takes to perform the queries, so enable both STATISTICS IO and STATISTICS TIME.

Ensuring a Fair Test

In order to ensure a clean slate to work from for our testing, it is a good idea to free the SQL Server plan cache prior to the execution of each of our T-SQL statements to be tested. The following statements will achieve this requirement.

Performance Comparison with no index on the test table

So the first query:

This produces the query plan shown in Figure 1 and contains three operators. A Table Scan, which is to be expected as there is no index on the table and a Sort operator that is responsible for 95% of the cost of the overall plan.

Figure 1: SELECT TOP 1 , with no index.

Executing the query produces the following results:

SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 4 ms.
Table ‘tmpTable’. Scan count 1, logical reads 6050, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times: CPU time = 344 ms, elapsed time = 338 ms.

Executing the second query using the MAX() operator:

This produces the query plan shown in Figure 2 and contains three operators. Again, a Table Scan is performed however this time a Stream Aggregate operator is used and the Table Scan accounts for 88% of the query cost.

Figure 2: SELECT MAX(), with no index

Executing the query produces the following results:

SQL Server Execution Times: CPU time = 0 ms, elapsed time = 4 ms.

Table ‘tmpTable’. Scan count 1, logical reads 4546, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times: CPU time = 281 ms, elapsed time = 280 ms.

Performance Comparison with no index on the test table

Create a clustered index on the test table:

Now execute the first query once again. Looking at how the estimated execution plan differs, Figure 3, notice that the Sort operator changes to a pure Top operator (that incidentally has an estimated number of rows of 1) and that all the cost of the query is placed on the Clustered Index Scan operator. This effectively removes the need for the Sort and hence it’s replacement in this plan.

Figure 3: SELECT TOP 1 , with clustered index.

The results of executing this query are:

SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 1 ms.

Table ‘tmpTable’. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times: CPU time = 0 ms, elapsed time = 1 ms.

Now execute the second query once again. Again, this produces a different plan in comparison to when the query was executed without a clustered index on the table however, the key point is that the Clustered Index Scan operator that bears 100% of the estimated cost of the plan.  This demonstrates that the execution cost of both queries is almost identical, when executed on a table & column covered by a clustered index.

Figure 4: SELECT MAX(), with clustered index.

The results of executing this query are:

SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 2 ms.

Table ‘tmpTable’. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times: CPU time = 0 ms, elapsed time = 1 ms.

Conclusion

When a clustered index is present on the table & column that is to be selected, both the MAX() operator and the query (SELECT TOP 1 ColumnName order by ColumnName) have almost identical performance.

When there is no clustered index on the table & column to be queried, the MAX() operator offers the better performance.

I hope you enjoyed the article and please feel free to post any comments, questions and feedback below.

What with so much going on at any given time, it can be tricky to stay on top of tasks and manage priorities. If like myself you enjoy getting things done and getting them done efficiently, then you too may find my latest discovery to be of value.

It is a web based task/project management application. It is intuitive to use, provides scheduled reminders and best of all is completely free.

Take a look at www.onlinetasklist.com