Home > Articles > Data > SQL Server

SQL Server Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

Performance Monitoring Tools: SQL Server 2005 Database Tuning Advisor

Last updated Mar 28, 2003.

There are two primary methods for your tuning work. The first is the "manual" method. What you do here is examine as many system views, dynamic management views, performance counters and any other meta data you can find about what is happening on the system. You compile all that data, and then learn about what those numbers and responses mean when they line up in a certain way.

This method works great — in fact, for a performance tuning expert, this is the preferred way to work.

But some of us don't have time to be an expert in every arcane Performance Counter and Dynamic Management View (DMV), along with all the ways they can interact with the Query Processing engine with its Algebrizers, Parsers and so on, and the hardware and software configurations on the systems. Sure, we like to learn things in this area, but we have other work to do.

That brings up the second method — automatic tools. And automatic tools are good things — most of the time. Tools allow you to leverage far more work than you can without them, they automate processes that we might make errors in, and they do it far faster than we can. So it makes sense, even for an expert, to take some time and learn the automated tools we have in SQL Server to help us with performance.

But there are limits. If the tools could be blindly trusted, Microsoft would have built them into the engine's intelligence and just make the queries better to begin with. The very fact that they exist as a separate tool means that there is a time to use them and a time not to. In this tutorial we'll take a look at the SQL Server 2005 Database Tuning Advisor, and give some indication as to when to use it, and when to trust your own judgement.

SQL Server 2000 included a tool called the "Index Tuning Wizard". It would examine a query and suggest changes or additions to the indexes on a table or set of tables. That's great — as far as it goes. But there is far more involved in a tuning effort than just the indexes, as I've explained in my previous articles.

The other issue with the Index Tuning Wizard is that it needed fairly high permissions to run. If you wanted a DBA to tune only the databases they owned, they were out of luck unless they were the sysadmin on the whole box. In addition, the Index Tuning Wizard didn't always take everything into account. You could even trick it by running a query from one database in another!

A new tool was called for in SQL Server 2005. This tool is called the "Database Tuning Advisor", or DTA, and it goes much further in what it examines for the tuning suggestions. In addition, you can include any portions of the system you want the DTA to examine, and it will make suggestions just for those items.

So what will the DTA do for you? Well, Books Online tells us that the Database Engine Tuning Advisor can:

  • Recommend the best mix of indexes for databases by using the query optimizer to analyze queries in a workload.
  • Recommend aligned or non-aligned partitions for databases referenced in a workload.
  • Recommend indexed views for databases referenced in a workload.
  • Analyze the effects of the proposed changes, including index usage, query distribution among tables, and query performance in the workload.
  • Recommend ways to tune the database for a small set of problem queries.
  • Allow you to customize the recommendation by specifying advanced options such as disk space constraints.
  • Provide reports that summarize the effects of implementing the recommendations for a given workload.
  • Consider alternatives in which you supply possible design choices in the form of hypothetical configurations for Database Engine Tuning Advisor to evaluate.

So what does all that mean? Well, it means that the DTA goes a lot further in examining the whole system for your tuning efforts. But all this analysis depends a great deal on one thing: how well you represent the system to the DTA.

What this means is that the DTA has to "watch" activity on the system to see what to do to make it better. It's kind of like a golfing coach. If you tell the coach, "Whenever I hit the golf ball, it always arcs to the right." The coach can make a couple of guesses right from the start about what you're doing to cause that, but what he or she will probably tell you is "I need to watch your swing, and even better, watch you play an entire game." The reason they want to see that is that it provides lots of clues that they can use.

Suppose you swing the golf club one time for the coach. They might notice that your stance, or your grip, or your swing is causing you to "slice" the ball, meaning it will go to the right. But perhaps you do everything properly — at first. Perhaps after you've been playing for an hour or two on a hot golf course your grip relaxes, or you get too tired to swing properly.

What does all this have to do with the DTA? A lot. You can tell the DTA to watch three things: a query, a set of Profiler Trace Tables, or a Profiler Trace. I almost never use the query method. There's just too little data there, and it's like allowing the golf coach to only watch one swing. It's just not enough data to make any recommendations from.

So I normally use a SQL Server Trace file. In case you're not familiar with what that is, it is the output from the SQL Server Profiler, yet another tool (which I've described here) that can record the activity of SQL Server for you. You can include several items, like counters in the Windows Performance Monitor, which indicate system activity, both from the users and the system. Of course, you don't want to watch everything, because the system would take so much time recording every single event that it would affect the performance itself – which kind of defeats the purpose!

So which objects to collect? Ah — Microsoft thought about that. There's a "Trace Template" that you can choose called "Tuning" , which has everything the DTA needs to do its job.

But we're not finished yet. Not only do you need to collect the right items, you need to collect the right "profile" of activity. For instance, if you run the Profiler Trace on a weekend or when not many people are on, you won't stress the system to the point of failure, and the DTA needs to see the "real" problem to fix it. Think of the golf coach watching your entire game. The coach can then fix not only your swing but suggest some exercises to make your game that much better. The key, then, is collecting the right data, at the right times. That's what I focus on.

As far as running through the screens for the DTA — I don't think you need me to do that here. You have the information you need to get started, and the DTA is very simple to use. But you do need to know how to start it.

To start the DTA, you have a lot of options. It all depends on where you are when you want to run it. You'll find the tool listed on the Windows Start menu, and you can start it from there by clicking All Programs, then Microsoft SQL Server 2005, then Performance Tools, and then Database Engine Tuning Advisor.

You can also start the DTA in SQL Server Management Studio by selecting the Tools menu, and then selecting Database Engine Tuning Advisor.

But that's not all. You can also start the DTA from the SQL Server Management Studio Query Editor, inside a Transact-SQL script file. Just select a query in the Transact-SQL script, or select the entire script, and then right-click the selection. Now choose Analyze Query in Database Engine Tuning Advisor. The DTA will open and import the script as a workload. You can specify a session name and tuning options to tune the selected Transact-SQL queries as your workload.

One more — if you want to start the DTA in SQL Server Profiler, on the Tools menu, click Database Engine Tuning Advisor.

Here's how I use this amazing tool. I create my application, and then set up a test run, both automated and manual. I capture that activity on a very underpowered system and select all the options. I then parse out what I need to change, and see what change I get in performance when I run those test suites again. Notice I said "change" I get — not "increase". I've run the DTA and gotten a decrease in performance. There are a lot of reasons for that, but what I do is to un-check options and run the DTA again. It's pretty fast — the hard part is getting the Trace set up, and you already have that. I then follow the instructions and run my tests again. Usually there is one or two suggestions that "fight" over the right solution, and when I remove one them, the gain is worth the work.

Get out there and experiment — once you know how to use this powerful tool, you're a leg up on the performance problems you face.

InformIT Articles and Sample Chapters

There is more about monitoring the SQL Server Enterprise in this free sample chapter from the book SQL Server 2005 Distilled.

Books and eBooks

You can read more about this powerful tool in the book Inside SQL Server 2005 Tools, by Michael Raheem, Dima Sonkin, Thierry D'Hers, Kami LeMonds.

Online Resources

Microsoft has all the docs for this tool right here: http://msdn2.microsoft.com/en-us/library/ms173494.aspx.