Adding Trace Filters to a SQLdiag Configuration
Normally, Profiler trace filters are
added to a SQL Server data collection to reduce the amount of
diagnostic data that is collected by SQLdiag. For example, you could
add a filter on SPID to collect only trace events which pertain to a
particular Session ID. Note that the text filters add CPU overhead to
the data collection as there is a significant CPU overhead for
evaluating text-based filters as opposed to integer filters. However,
if you collect a Profiler trace using a SQLdiag configuration XML file,
then you need to follow these steps:
1. Start
SQLdiag on the server.
2. Find out the Trace ID of the Profiler trace running using fn_trace_getinfo function or sys.traces view.
3. Stop the trace using sp_trace_setstatus without deleting the definition.
4. Use the Trace ID obtained from step 2, and use the sp_trace_setfilter stored procedure to set the filter.
5. To verify that the filter is active, use the fn_trace_filterinfo function.
6. When you are satisfied that the filter is active, start the trace data collection using sp_trace_setstatus.
The following T-SQL Commands can be used toSet a Filter for SPID = 52 for TraceID = 2 once the SQLdiag has been initialized:
select * from sys.traces — To get the trace id
EXEC sp_trace_setstatus 2,0 — Stops the trace but doesn’t delete the trace definition
from the server
EXEC sp_trace_setfilter 2, 12, 0, 0, 52 — Add a filter for SPID = 52
EXEC sp_trace_setstatus 2,1 — Start the trace again
select * from fn_trace_getfilterinfo(2) — Get information about the filters set for the
trace
Understanding the Custom Diagnostics in SQLdiag
This section looks at the different
categories of custom diagnostics available out-of-the-box in the Diag
Manager. The extensibility of SQLdiag using Diag Manager is a very
compelling reason for all SQL Server professionals to add this tool to
their repertoire. The T-SQL, VBScript and DOS commands used by the
custom diagnostics configurations are available in the C:\Program Files\Microsoft\Pssdiag\CustomDiagnostics folder.
NOTE If you have installed Diag Manager on a 64-bit machine, then instead of Programs Files you will be looking for the Program Files (x86) folder.
General Custom Diagnostics
The SQL Base
custom collector is used to add tasks that should be executed for every
type of SQL Server data collection. This custom collector runs before
any other custom collector task. One of the group’s primary purposes is
to define global parameters that may be of general use in other task
groups. This collector also collects basic configuration information
from the registry, system configuration information, the status of the
PAE switch, and the trace flags active on the target SQL Server
instance.
All the output files have the prefix “SERVER_SQL_Base_*.”
The MSINFO custom collector collects the msinfo32 output from the target machine.
The SQL Best Practices custom collector collects outputs of various scripts to check the following:
- NTFS compression on SQL Server database files
- Hypothetical indexes on the databases (if any)
- Use of the /3GB and /PAE switch in the BOOT.INI file
- Information about all the SQL Server Profiler traces active on the target SQL Server instance
All the output files have the prefix “SERVER_SQL_Best_Practices_*.”
SQL 2008 Perf Stats
The most common customization that SQL
Server professionals and Microsoft engineers add to SQLdiag is to
collect SQL Server blocking diagnostics. You might already be familiar
with the configuration option to capture blocking information. This
information can be collected using the SQL 2008 Perf Stats
custom diagnostic option. This section describes why this custom
diagnostic is not just about collecting blocking information on your
SQL Server instance as seen below. Note that the scripts available in
the download section work for SQL Server 2012 instances as well.
However, if you intend to capture the SQL Perf
Stats script manually, then you need to get the latest Perf Stats
script, available from CodePlex at http://sqlnexus.codeplex.com/wikipage?title=Sql2005PerfStatsScript&ProjectName=sqlnexus. After downloading it, follow these steps:
1. Click Page Info from the navigation bar.
2. Scroll down to locate the File Attachments section.
3. Locate PerfStatsScript2008R2.zip and download the file.
4. After extracting the zip file, you will find the files shown in Figure 3.
The SQL_2008_Perf_Stats_Snapshot.sql
script collects information about your SQL Server instance’s top
resource-consuming queries, missing indexes information with the CREATE INDEX
scripts along with resource consuming query hashes. Query hash was a
new feature added in SQL Server 2008 and later versions to create a
hash value for the queries which use different literal parameter
values. The output of this script is collected twice: once when SQLdiag
starts and once when it is stopped.
The SQL_2008_Perf_Stats.sql script captures various DMV outputs and blocking information periodically using a delay of ten seconds with the WAITFOR DELAY command.
The output of both aforementioned scripts can be
imported into a SQL Server database using the SQL Nexus tool for data
analysis. The bonus here is the fact that this custom diagnostic also
collects the output of the System Health Session Extended Event
session, which is an Extended Event session that runs by default on SQL
Server 2008 instances and later.
NOTE This
custom diagnostic is the equivalent of the SQL 2005 Perf Stats custom
collector used for SQL Server 2005 instances to collect similar
diagnostic information.
Backing Up Diagnostic Data Already Available
The SQL 2008 Backup MDW
custom collector performs a backup of any Management Data Warehouse
database that you might have configured on the SQL Server instance.
When you Save the SQLdiag configuration, a pop-up window will prompt
you for the Management Data Warehouse database name, as show in Figure 4.
The SQL Dumps custom collector collects all the mini-dump (SQLDumpXXXX.mdmp) files, symptom dump text files (SQLDump*.txt)
and the exception log file. The collector skips any dump file larger
than 10MB and limits the dumps collected to 70MB. The dump files
skipped will be the older dump files.
WARNING Both
the custom collectors can bloat your SQLdiag output folder, so these
collectors should be enabled only when required. A Management Data
Warehouse database backup can be significantly large if it stores data
for a large number of instances or contains a large amount of
historical data.
Analysis Services Custom Collectors
The Diag Manager provides four
different types of collectors for Analysis Services. Three collectors
are specific to a given Analysis Services version, and the fourth is a
shared collector that collects general diagnostics from an Analysis
Services instance:
- Analysis Services 2000
- Analysis Services 2005
- Analysis Services 2008
- Analysis Services Shared
The Analysis Services 2008 and Analysis
Services Shared works for SQL Server 2012 Analysis Services installed
in the multi-dimensional model. If you are interested in viewing what
these collectors collect, you can find details by right-clicking on the
collector and selecting the Details option as shown in Figure 5.
