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
Creating a Performance Tuning Audit - Evaluation Part Two
Last updated Mar 28, 2003.
In the last section I explained how you can make your selections for the second phase of creating a performance tuning audit. The audit is an essential part of performance tuning exercise since it presents a single location for all the components within a system. We're focusing on a holistic approach because the database is just one part of the system, but as the DBA you're often asked to "tune the system" when it runs slow. In a small application that involves only a couple of components, that might be possible, but in a large, enterprise-level application there are so many interdependencies that you can't tune it by evaluating only one object.
As I mentioned in the Defining Components phase, the format you use to gather and present this information isn't really important. The important part is to be consistent and to use a tool that allows you to disseminate the information to as many technical and business people as possible. I've used Microsoft Word or Microsoft Excel as the primary tool since they are available just about everywhere (and the reader is free), and almost any system can import or open them. Word even has multi-authoring capabilities, and Excel gives you table-like display and manipulation.
We've defined the parts of the landscape, which I covered in a previous tutorial in this series, and in the last tutorial I showed you how to define the components you need to care about.
Now let's return to the outline and discuss the second part of the evaluation phase. In this part of the process you will apply measurement tools and processes against the components you selected using the metrics you decide on. You'll need to make more decisions here on things as varied as timing and interval to the instance of the metric to evaluate.
Once again, let me reiterate that it's important not to get ahead of the process — don't make a broad statement about what you're seeing when you set up the measurement tools. You will want to watch the monitor, but you need to let the tests complete before you interpret data, and it's important that you wait until the interpretation is evaluated before you try to create a corrective action plan. I'll cover all of these steps throughout this series.
So you've identified the components within the system to monitor, and you've decided to use the "outside-in" approach. As I mentioned earlier, the best resource that you have to work with the components is the expert in that area. Let's take a practical example at this point.
This example system uses an N-tier architecture — that is, it has an HTTP-based client, which talks to various COM+ systems that in turn talk to a single database server. The system has clients that are located on the backbone of the corporate network, and also multiple laptop clients that pull information from the system to create reports. Recently, the users have reported a significant slowdown. To simplify the example we'll keep it simple with two switches in between the main clients, and a single switch that handles the inbound traffic from the laptop clients from a VPN.
Using our methodology, we've selected two types of clients from the local network and one laptop as a representative of the outside clients. We've detailed the network path, we have the information from the developers about the general nature of the application, and we know the network routes. We've also identified all of the servers involved in the chain of packets from a client's click of the mouse to the servers and back to the client with a screen representation of the processed data.
With the parts of the system identified, we need to split out static and dynamic data elements to monitor. Static elements are those that don't change very often, or at all. For a workstation this is information like the model number, memory installed, even the service pack level on the operating system and driver names and versions. Happily, you can get most of this information from the WINMSD utility that is included in most versions of Windows. If your clients are UNIX or other operating systems-based, there are similar utilities that will give you the same kind of information.
You'll want the same static information for all of the servers in the line as well. Make sure on the servers that you run the proper commands to get the service pack levels for all of the software components that are pertinent to its operation. For SQL Server, you can run the xp_msver stored procedure along with others that I'll detail in this series to find out much of the static information for the server.
For routers and other hardware devices, you can get the model number, firmware revision, port information and so forth. Make sure you include all devices in the chain.
It's at this point that you'll run into the danger I've mentioned earlier. Your network admin will say something like "That switch has what firmware release? That's totally out of our baseline — I'll fix that right now." Once again, don't do it. Note it down, and leave that correction for the next two phases.
Gather as much of this kind of information as humanly possible. You don't have to include it all inside your main audit documentation, since it will quickly become unreadable. Point to the source documentation and review it with the other technical professionals in the next phase of the process. Just note it down and gather it all into one location. Make sure you enlist others in this process; or you'll have a lot of work to do and it will take so long that the problem will change underneath you.
Next, we need to gather the dynamic information. These are usually based on objects and counters. Objects are things like processors, and an associated counter might be something like percent utilization. We will need to use a tool that is able to read these objects and counters and save out the associated values. On Windows systems like clients, COM+ and SQL Servers, you can use the Windows System Monitor. This tool has everything you need to monitor the entire process end to end. There are also multiple commercial tools that do the same thing, but they often include an interpretive component that can be dangerous.
On routers and other network equipment, you will often need a second set of tools to collect the values you want. There are multiple open-source products that fill this need.
The important thing is that we start the collection at the same time, and that they run for the same length of time. It's also important that we consider the interval for the collection. Most of the time technical professionals take too long of an interval when they monitor. They take a five or ten minute collection interval, and completely miss the things that happen within that time frame. I recommend no longer than five minutes for the interval, and most of the time I monitor with a one minute or less interval, and I do that for twenty-four hour periods. I then take those periods several times a month, during representative activity.
With the information gathered from each source, we need to prepare it for the next phase. To do that, I normally bring all of the counters into an Excel spreadsheet, and then format the cells with the appropriate data type. The most crucial data type is the date format for the collection, so that you can accurately compare the events across the components. What we're trying to get to is the ability to see when the client clicked on something, watching it resonate through the entire system.
In the next tutorial I'll explain the next phase, continuing with this example.
Informit Articles and Sample Chapters
Our own Tom Bunzel will show you how to use both Excel and Microsoft Word, and how those multi-authoring techniques I've mentioned.
As you can probably tell, I use Excel a lot. Other than the articles here on Informit, I also use Mr. Excel to help me use this great product.