Fequently asked questions (FAQ)
I received an error, what should I do?
I saw many differnt files in the output folder, what are these files?
This page has information on what these files are and naming conventions
What happened to SQL Server 2000 and 7.0 collector?
Pssdiag for SQL Server 2000 and 70 is available athttp://support.microsoft.com/kb/830232. This codeplex release intends to support SQL Server 2005 and beyond.
How do I tell PSSDIAG to shut down automatically after a certain amount of time?
You can use the /E command line parameter. For example:
PSSDIAG.CMD /E21:00:00 - Shut down at 9pm (current day, or following day if current time is >9pm)
PSSDIAG.CMD /E+10:00:00 - Start, collect data for 10 hours, then shut down automatically
I need to collect data from an IA64/x64/x86 SQL instance. Is there anything I need to do differently?
Be sure to select the CPU platform (see the 32-bit Pentium, Itanium, or x64 buttons on the left pane of Diag Manager UI) before making other selections -- selecting a new platform loads new defaults
for the rest of the form. Note that you should select the platform that matches the version of sqlservr.exe that you are targeting. For example, for a 32-bit SQL instance running in the WOW64 layer on x64 Windows, you should select 32-bit Pentium/x86.
Select the AMD64 option only for native x64 SQL 2005 instances.
PSSDIAG was killed abruptly with kill.exe/taskman, orphaning the profiler trace. What do I do?
Run the following to stop any active profiler trace (usesp_trace09 on a SQL 2005 instance):
EXEC tempdb.dbo.sp_trace10 'OFF' -- For SQL Server 2008 and above
OR
EXEC tempdb.dbo.sp_trace09 'OFF' -- For SQL Server 2005
Run "logman query -ets" from a command prompt to identify any orphaned ETW perfmon logs. Run "logman stop <tracename> -ets" to stop them (replace "<tracename>" with the appropriate trace name). Reference: Logman. Note that PSSDIAG automatically performs these steps when it starts to clear up any orphaned traces and perfmon logs. Check the "##srv__SQL_Base_ClearOrphanedBLGs_Startup.OUT" output file for any orphaned perfmon .BLG files. This file is created every time you spawn a PSSDIAG capture.If you have SQL Server 2005/2008 Perf Stats script, running. Kill sqlcmd.exe. If it restarts, you need to useprocess explorer to identify parent cmd.exe and kill that cmd.exe. If you don't want to use process explorer to find out process parent/child tree, you can kill all cmd.exe processes if this doesn't affect other operators/operations.
Can I run PSSDIAG on a remote machine to minimize the load on the server being monitored?
If you are not capturing a profiler trace, yes, you can run the collector on a remote machine. If you need to capture a profiler trace, it is srongly recommended to run the collector on the server being monitored. SQL Server itself always captures the profiler
trace, so there is no way to offload profiler trace-related work to a remote machine. Because the primary performance impact of data collection is typically caused by the profiler trace, and because the trace is always captured
by sqlservr.exe regardless of where PSSDIAG is running, there are generally no performance advantages to be gained by running the collector remotely.
How do I import the perf stats script output and profiler traces that PSSDIAG collects?
The data collected by PSSDIAG (.trc and .out files) can be imported by
SQL Nexus into a SQL Server database.
I need to collect data for a long time but there isn't enough disk space. What can I do?
Limited disk space is usually the biggest obstacle to long-term data collection. Before configuring a PSSDIAG package, find out from how much free disk space is available on the server to be monitored. The free disk space must be on a locally attached disk
(or SAN) if you are collecting a Profiler trace. If you are not collecting a Profiler trace you have other options, including capturing the data on a remote machine. If you are collecting Profiler, the server will typically need an appropriate local disk with
at least several GB free. The rate at which Profiler trace data is generated is entirely dependent on the application workload. It may vary from a few MB per minute up to several GB per minute for a heavily loaded server that services thousands of queries
each second. You could do the following for a long term data collection using PSSDIAG:
PSSDIAG.CMD /E 03:00:00 /L /Q /N2
PSSDiag.CMD /E +03:00:00
PSSDiag.CMD /B +03:00:00
PSSDIAG is too "heavy". My server slows down when we are capturing data.
The set of data that PSSDIAG/SQLDIAG captures is completely configurable. The impact of data collection is equal to the combined impacts of the various log types that you configure for collection using
the Diag Manager to capture (the collector itself has a negligible impact on the machine), which means that if a PSSDIAG/SQLDIAG data capture hurts performance on a server it is almost certainly due to the log types and trace events that were selected. Generally
speaking, the only log type that commonly causes performance problems is the profiler trace. Note that there is no more efficient way to capture a profiler trace than the method that PSSDIAG/SQLDIAG uses. You can capture certain information using XEvents starting
from SQL Server 2008 but a profiler trace is required for most common performance issues that we are dealing with up to SQL Server 2008 R2 release. Nevertheless, a profiler trace can be an intrusive log type to capture. You should not capture a profiler trace
unless you need one, be careful not to select high volume events unless they are essential, and always keep in mind the following points:
- Always capture a server side trace and not using the profiler.exe GUI interface. PSSDIAG uses server side tracing. SeeKB929728 for details.
- Always trace to a locally attached (or SAN) disk, never to a network share. See KB307786.
- Never trace to a UNC path, even if the UNC points to a local disk.
- Don't capture extremely high frequency events like Object:Opened, Lock:Acquired/Released, etc on a production server. Some servers have a workload that is sufficiently low-volume to capture these events, but there is no easy way to know in advance whether this is the case. More information on high frequency events can be foundhere.
- Direct the trace to the fastest available volume that isn't already being used by the data or log files. Tracing is write-intensive, so of course avoid RAID-5 whenever possible.
- Be aware that with certain workloads, even a fairly basic trace of just RPC/Batch Starting & Completed events can hurt performance if you haven't allocated fast enough disks to the trace.
- Trace filtering can dramatically reduce .TRC file size and the I/O cost of tracing, but you should be aware that it can actuallyincrease the CPU burden of tracing. To minimize the extra CPU use, filtering should be performed on an integer column (dbid, duration, etc) instead of a text column (database name, textdata, etc) whenever possible. If a filter doesn’t remove
a significant portion of the trace events (say, >10%), it probably isn’t worth it, and might actually introduce more overhead than it prevents. While configuring PSSDIAG/SQLDIAG for SQL Server, you cannot add Profiler Trace Filters. Even if you do
so from the GUI, it would not be included in the PSSDIAG.INI file. To set filters for profiler traces collected with PSSDIAG/SQLDIAG, you need to:
- Initialize PSSDIAG on the server Find out the Trace ID of the profiler trace running usingfn_trace_getinfo function or sys.traces view.
- Use the Trace ID obtained from the above step, and use thesp_trace_setfilter stored procedure to set the filter. Refer "SQL Profiler Data Columns" under SQL Server Books Online for theData Column numbers and "sp_trace_setfilter" topic for finding out the values of the logical and comparison operators.
- To verfiy that the filter is active, use thefn_trace_filterinfo function.