SQL Performance Related Tools Collection

As a part of my profession, I come across a lot of situations that we have to look into performance of a SQL Server. For this, everybody has a slightly different methodology and style. Often than seldom, I need to point my correspondence to a series of tools, that I usually revert to, if I need to do the performance analysis real quick. At some point, I decided that I should put these first set of tools in a common location and give some guidance about their usage, so that I will not have to repeat myself. Even when I repeat myself, I know that the knowledge I share might not be as complete as these resources that I am going to share with this blog post.

First of all, here is my nifty little collection:

http://sdrv.ms/18wkAiV

The folder looks like this at the moment:

Part 0 - performance Dashboard Reports and Management Data Warehouse

Before we start talking about performance analysis on SQL server, we need to make sure that some stuff is already in the know, to all of us.

You need to have read about the MDW

http://msdn.microsoft.com/en-us/library/dd939169.aspx

Better yet, you should have already noticed two files in my collection above, namely

SQL Performance Dashboard Reports for SQL Server 2005 and 2012.

 For SQL Versions of 2008 and 2008R2, remember that you may use the package named 2012 without any modifications.

These are readily available and magnificent tools to get you started. So please do have a look to all the good looking stuff that we may have.

http://www.mssqltips.com/sqlservertip/2670/install-sql-server-2012-performance-dashboard-reports/

http://dotnetstories.wordpress.com/2012/07/16/using-sql-server-2012-performance-dashboard-reports/

While you are at it, please review this one, from one of my colleagues. He has excellent work going on dashboards:

http://blogs.msdn.com/b/sql_pfe_blog/archive/2013/04/15/sql-2012-system-health-reporting-dashboard-visualizing-sp-server-diagnostics-results.aspx

By the way, I am certainly at a miss, why we do not have these inside our SQL Server product, in-the-box and by default enabled. If you agree, please be loud about it, complain about this in the connect site and provide comments all over the place.

Part I -- PAL

In there, we have the PAL tool that comes from http://pal.codeplex.com/

This is an automated tool for analyzing perfmon BLG files, that might have been collected from any server. It does have templates for SQL Server as well as, any funky technology out there. There are a lot of documentation out there to help you use this tool, but the main purpose is to get a html report from a performance data collection.

Some good blogs that I have come across:

http://tracyboggiano.com/archive/2012/03/automation-of-pal-performance-analysis-of-logs-tool-for-sql-server-using-powershell-part-1/

Part II -- RML and SQLNEXUS

There is a another group of files in my collection, that are meant to be used together for conducting a variety of SQL specific analysis. Some of these tools, have dependencies to each other, so I included them all. I know you are eager to read the straight dope here, but sorry, I will define the tools and give you a link to another blog from a colleague.  

Reportviewer is a component that you need to have installed to be able to use the SQLNEXUS tool and potentially the RML Utilities.

RMLSetup_XX are two files for x86 or x64 platform, these stand for the Replay Markup Language Utilities.

A very nifty article of why RML exists is here http://support.microsoft.com/kb/944837

Once you install the report viewer and the RML utilities for your specific platform (these better be done in a test or analysis environment rather than the SQL Server you are trying to review and trouble shoot the performance of, needless to say), you have got access to real fine tools, please read on as these need to be used in conjunction to each other and an excellent blog link is coming up.

You should have noticed that there are

PerfStatsScriptXXXX file for each version of SQL server starting from 2005. These are the data collector components to be run on the target server that we are trying to review or troubleshoot the performance of.

I have modified some parts of these perfstatscripts to make them less prone to failure, you just need to make sure that the correct version is being run.

And the last one in this series is the SQLNEXUS tool. It comes from http://sqlnexus.codeplex.com/

Please make sure that you have installed the report viewer and the rml utils before you run SQLNEXUS, also, you will need a decent SQL instance so that the tool can load up it's data regarding the analysis that it will do.

A typical analysis run, consists of the following.

•  You copy relevant perfstats script to the server, you run a data collection using one of the *.bat scripts in them. SQLDIAG (that is already installed on the SQL server as an in the box utility) will collect lots of data, according to the perfstat scripts definitions.  (notice you might need lots of space where this runs, also consider I/O path requirements and overhead to the server)
• You will stop this collection, after a certain period of time. Time frame could be according to bad performance period, something undesirable happening on the server etc.
• In the output folder, you will find results of type SQL traces, perfmon BLG, and SQL script outputs.
• You will move these output to another server that you have set-up for analysis, using PAL, RML Utils, Report Viewer and SQLNEXUS.
• You will load the data up using PAL, and  SQLNEXUS and run relevant analysis.

Here is the blog that actually tells it all, very thorough and very beneficial. Big, big thanks to Pankaj Mittal for this one.

http://blogs.msdn.com/b/pamitt/archive/2011/02/25/how-to-use-the-sqldiag-the-sqlnexus-and-the-pal-tools-to-analyze-performance-issues-in-sql-server.aspx

 Part III - Let's Learn About XEvents

 The last file in the collection is a XEvent display setting file, although I have not been able to make it really work yet.

Performance trouble shooting or reviews, need to shift to using XEvent methodology. It is much more versatile, robust, powerful than all the older methods of collecting SQL traces and other intermediate data for analysis. The only problem with this, was and still is, the fact that older versions of SQL Server  and the related client tools, were not very complete in terms of using XEvents in an effective way.

 Here is a great introduction from my colleague Bob Dorr, to make you like XEvents. With his guidance in this blog article, we might find similar analysis results that all the above tools could give us, from right within the XEvent interface inside the SSMS.

http://blogs.msdn.com/b/psssql/archive/2012/04/06/sql-server-2012-rml-xevent-viewer-and-distributed-replay.aspx

Interesting to say, this thing is near live or near real-time, meaning that we do not collect-offload-loadup-analyze data. The XEvent can collect data and immediately show us analysis without any intermediate steps.

Also notice that the overhead of using XEvents (and the associated hardships of "where to put the data", "will the SQL slow down while collecting") is by a magnitude less than using SQL Server tracing. No wonder tracing might become depreciated soon .

Thanks for reading and please do post comments.
Appreciate more if anyone posts about such performance related work they might have performed and tools that they might have used and  any challenges they might have faced. I would also be thrilled if anyone has a recommendation to include in these set of tools. Until next time, keep well.