Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- Microsoft SQL Server Programming
- Performance Tuning SQL Server: Tools and Processes
- Performance Tuning SQL Server: Tools Overview
- Creating a Performance Tuning Audit - Defining Components
- Creating a Performance Tuning Audit - Evaluation Part One
- Creating a Performance Tuning Audit - Evaluation Part Two
- Creating a Performance Tuning Audit - Interpretation
- Creating a Performance Tuning Audit - Developing an Action Plan
- Understanding SQL Server Query Plans
- Performance Tuning: Implementing Indexes
- Performance Monitoring Tools: Windows 2008 (and Higher) Server Utilities, Part 1
- Performance Monitoring Tools: Windows 2008 (and Higher) Server Utilities, Part 2
- Performance Monitoring Tools: Windows System Monitor
- Performance Monitoring Tools: Logging with System Monitor
- Performance Monitoring Tools: User Defined Counters
- General Transact-SQL (T-SQL) Performance Tuning, Part 1
- General Transact-SQL (T-SQL) Performance Tuning, Part 2
- General Transact-SQL (T-SQL) Performance Tuning, Part 3
- Performance Monitoring Tools: An Introduction to SQL Profiler
- Performance Tuning: Introduction to Indexes
- Performance Monitoring Tools: SQL Server 2000 Index Tuning Wizard
- Performance Monitoring Tools: SQL Server 2005 Database Tuning Advisor
- Performance Monitoring Tools: SQL Server Management Studio Reports
- Performance Monitoring Tools: SQL Server 2008 Activity Monitor
- The SQL Server 2008 Management Data Warehouse and Data Collector
- Performance Monitoring Tools: Evaluating Wait States with PowerShell and Excel
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
Last updated Mar 28, 2003.
SQL Server Performance Tuning is one of the most difficult tasks you'll be asked to do. It is difficult because you need to have a lot of experience and knowledge in three areas: programming, administration, and the application you're tuning. In this section of the guide I'll show you how you can find and fix performance issues.
Performance Tuning Basics
The basics of performance tuning are deceptively simple: "Find the slowest part of the system and take steps to make that part faster." But within that simple statement lays a great deal of complexity.
The first thing to notice is that you need to find the slowest part of the system. Every application is made up of several components from the design of the application flow on the screen to the hardware the client uses, out through the network that system is on, off to the general network, down to the server connection, and then on through the various hardware within the server. Past that are the operating system software configuration, the SQL Server instance configuration, the database design and configuration and all the way down to how the stored procedures and Transact-SQL statements are written. So you can see that if you focus your efforts only on the database itself, you may not find the problem at all. In this section, I'll show you how to treat the entire system as part of the performance tuning exercise. You'll also learn to find the dependencies between the components in the system. It's actually fairly rare to find a single problem as the cause of a performance slowdown.
This also means that you'll need to understand where the bottleneck is and it's tough to do that if you don't know how fast the components were working to begin with. I'll explain how you can take a baseline to get just this sort of information.
Notice also that the statement says that you need to take steps to make the part go faster. As a final set of steps, I'll show you the tools and techniques you can use to optimize your SQL Server processes and Transact-SQL statements.
Work from the Outside In
Although there are many components and parts to evaluate, there is a simple way to start the process. You can compartmentalize the work by starting at the “outside” of the system, working inwards. In the series of articles that follow, I’ll show you how to work from the workstation out, but when you get to the SQL Server, you can think about working from the levels of components it contains. There are quite a few but there are three major areas to consider and I mostly take them in this order:
In the sections that follow, I’ll show you how to deal with each.
As the data professional, you’re not often enabled to change or add to the server hardware. It’s important that you understand the impacts that hardware components have on SQL Server installations.
Hardware is made up of hundreds of other components, and many of these have “firmware” installed on them which is really just more software. So the hardware components are not only an important consideration but their “drivers” software are as well. In fact, if you add up all of the firmware and drivers for the hardware, there are potentially more lines of code (and hence things that might need updating or tuning) than in SQL Server itself!
There are four main components within the hardware environment for SQL Server:
- I/O (Storage sub-component)
In subsequent articles, I’ll show you how to set a baseline level of monitoring on these components, and what you can do to tune them.
Because SQL Server runs on hardware, you might think that hardware will have the biggest impact on performance. However, other than in extreme cases where the system is starved of memory or the I/O subsystem is woefully slow, there is a far bigger impact on performance based on the work the server is doing and in the case of SQL Server, that means the queries that are running.
This only makes logical sense if you don’t do any work at all, or retrieve any rows from SQL Server, the performance of the system is effectively 100% albeit not very useful! On the other hand, if you retrieve the maximum amount of data in the least efficient way, taxing all four components of the hardware at the highest levels, the performance could reach 0%. By that logic, you should do one of two things:
- The least amount of work possible
- The most efficient way to perform the work required
And that’s where writing good queries comes in. You should strive to write efficient T-SQL, and you should learn to tune the queries you write, and re-write them where necessary, called “re-factoring”. I’ll show you how to do those things in the articles in this section, along with other performance tuning references here at InformIT.
Just after setting up the hardware correctly and then tuning your queries, you need to understand and apply proper Indexes. And just what is that?
An Index in SQL Server works similar to an index in a book. If you want to locate certain topics or words in a long book, you turn to the index to look up the word, and that tells you which page numbers to look at to find those words or topics.
An Index in SQL Server is quite similar. You create an Index on the columns you will ask about frequently (like last names, states, etc.) and SQL Server creates pointers in the Index as to where those entries are located. Of course, the analogy breaks down a little in that in the book, the pages don’t change. In SQL Server, the data changes constantly, so the Indexes need to be updated and along with that, they need to be defragmented from time to time. Later in this section I’ll show you how to choose the right columns to Index, how to check the Indexes to see when they need to be maintained, and how to maintain them.
Your Code or Someone Else's?
With "canned" or off-the-shelf applications, your tuning efforts will be limited to the platform (SQL Server) and the hardware it runs on. You won't often be allowed to tune any of the code or indexes these applications provide. You can still run the tuning process I'll describe in this section and report it to the vendor having been one multiple times in my career, I can tell you it is often very much appreciated. At the very least, you'll be able to help the vendor quickly pinpoint the issues. If not, hey, maybe it's time to find another vendor!
In some cases your group or company owns the application code, and you'll be required to tune not only the database platform and hardware, but the code, stored procedures, indexes and more. This is where you'll have the most impact, and the place where you'll be held to the highest standards. After all, this is a creation of your own design, so it's best to do it right the first time and build in the metrics and other components that will allow you to quickly troubleshoot performance problems later.
But before you even write your first piece of code, you need to think about the design. At times, even the join order can matter (but not always), so every part of the application's design needs to be thoroughly thought out and considered.
Tools of the Trade
Of course, there is a lot of knowledge that you need to properly tune a system. But along with this knowledge, it's crucial to have good tools to work with. Happily, Microsoft includes just about everything you need right in the box to create and tune your system. I'll cover these tools and give you practical examples on working with them.
Microsoft isn't the only pony in this stable. Lots of other vendors have great products that will find, and in some cases even prevent performance problems. I'll also cover a few of those so that you can make your own decision.
As you can see, the reason that performance tuning on your SQL Server system is valuable not only because of its effect, but also because of its difficulty. In this section of the guide, and using the references at the end of each tutorial and overview, you'll get the knowledge you need to keep your systems running, and running fast.
Click Next below to continue reading about Microsoft SQL Server Performance Tuning.