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
Performance Monitoring Tools: SQL Server Management Studio Reports
Last updated Mar 28, 2003.
One of the top items on a DBA's task list is to learn how to quickly find the operational status of a server. You need to be able to find out if a server is running, and if it is running well. If not, you want to be able to determine what the problem is as quickly as possible. It's also useful to be able to communicate that information to others, especially those with a different technical skill set or no technical skill at all. If you can explain to these audiences thoughtfully and intelligently that the server is starved for memory, you can more readily convince them to buy the hardware you need to fix the problem. If the problem is in the code running on the server, then you'll need data to show the long running queries or incorrect design to prove your case.
There are a few processes you can use to satisfy all of these goals. You can dig into the documentation and become an expert in Transact-SQL (T-SQL) statements, and research the various system functions and views. You can then learn to interpret the output of these statements and function calls and compare them to known good and bad values. With this data and knowledge in hand, you can create spreadsheets of the data, and then create graphs and charts showing the known performance to the expected performance. You can deliver these reports to the technical and non-technical professionals that need the information. This is a good course of action, but it does take time and dedicated testing resources, two luxuries you may not have.
Another method is to use someone else's knowledge and skill to gather and display the data about the server. Several vendors provide tools that you can buy to monitor the server, and some of those provide output you can share with others. These tools are commonly known as dashboards. A dashboard is a software equivalent to the dashboard on a car. It shows a graphical or textual representation of activity in the engine. These tools have the advantage of providing you instant data collection, and you don't have to spend time learning the various system calls to display the data.
In SQL Server 2005, Microsoft provides a similar tool for free, inside the SQL Server Management Studio (SSMS). In fact, it provides several reports with this kind of information. In this tutorial, I'll cover a few of the reports you can use to monitor your server's health and performance, and how you can interpret the results and provide them to others.
One word of caution is needed before we begin. Even with a dashboard, you are still responsible for your server. You can't substitute any tool for learning how your server works, and why it is showing the results you're seeing. The tools just make it easier to automate some of the more mundane collection tasks. For that reason, I like the reports Microsoft provides a little better than other tools because it doesn't try to explain the results, it just displays the results. Some are obvious, such as showing long-running queries. Clearly a query that takes an hour is probably an issue. Some output, however, isn't as intuitive. You'll need to understand what you're looking at, but having the output available makes that much easier.
To see the dashboard, open SSMS and connect to a SQL Server 2005 system. Once you've connected, unless you have a very large display, use the push-pins to move all of the panels on the screen out of the way except the Summary tab. The default view for this tab is the list view of the objects on the server, but you can change that to the first report we are interested in using the Report button. Just to the right of that button is a small triangle that will drop down a list of available reports.
You'll see quite a list of reports, but we'll only examine a few of the more important ones. These reports will help you drill down to the interesting activity on the server, which you can troubleshoot.
I'll explain how you can use the reports by going over a typical session on my server. The report I normally start with is the Dashboard.
This view shows an overview of the activity on the server, represented as a "pie" graph. On my system, ad-hoc queries take up most of the activity on the CPU, followed by the reporting server instance. For the input/output components, activity within the msdb database takes most of the time. You can also expand the text items in this report to show more detail about configuration or activity, as I've done here. There are several items on this report that you can use to view the configuration and other information about your server.
If you right-click inside the report, you're able to print the report, or export it to Excel or a PDF file. If you export the report, all of the details are expanded automatically, even if you don't have them expanded on the screen. You'll also get all of the graphical elements on the screen.
The dashboard is a great place to start when you're monitoring your server. If the server shows a blocked process, or a high value in one of the activity sections, you can use other reports to drill down a bit further. On my system, I noticed that the memory was showing more use than I thought was healthy for the level I have installed. The next report I opened was Memory Consumption.
These graphs showed that the memory is being used primarily by the cache — normally a good thing. I wanted to know more about what specific items were using memory so I scrolled to the bottom of the report and expanded the Memory Usage by Component item. This shows all of the objects that are using memory, along with the memory distribution.
Along the way, I received a report that an application experienced an issue. One user had a machine freeze up on him, and they asked me to investigate. I changed the view back to the dashboard, and when I expanded the activity details I noticed a blocked process. I then pulled down the Activity — All Blocking Transactions report and opened the details. The report shows the connections that were blocked, even the times the connections blocked. I resolved the deadlock and helped the developer evaluate the code to find out how the block occurred.
The way I found out the particular machine that had the block was to use the Activity — All Sessions report to see the connection ID numbers involved, and then I drilled down until I found the Client Network ID column that displays the machine name. That helped the developer and I find the problem.
With that crisis resolved, I wanted to take some proactive measures for performance, so I pulled down the Activity — Top Sessions report.
This report shows a lot of information about the longest running queries, the sessions that take the most memory, the sessions that take the most CPU time and so forth. By monitoring this screen I can find the queries that are running poorly or the ones that could benefit from an index. I can also evaluate the reaction of my server to the maintenance tasks such as backups or index reorganizations.
One I locate the longer queries I use the Performance — Object Execution Statistics to find out more granular information for performance.
There is a lot of information on this report, especially in the bottom section. The details here break down the activity by the number of reads and writes, memory use and other information that shows you what is happening with a particular session. This report allows you to decide which of the other reports you need to use to locate and fix issues.
As you can see, the reports from SSMS don't fix problems for you. They point out the areas where you are having issues. You will then need to use the knowledge you've gained to resolve the issues.
Informit Articles and Sample Chapters
If you'd like to learn more about SQL Server Management Studio, check out this article by Eric Brown.
The team that created the Management Studio Reports regularly blogs. You can find that here.