Fequently asked questions (FAQ)

I received an error, what should I do?

See Common Issues section.

I saw many different 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 at http://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 (use sp_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 use process 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:

  • Enable NTFS compression in PSSDIAG by using /C1 to PSSDIAG.CMD as a command line parameter. When the /C1 parameter is provided, PSSDIAG will turn on NTFS compression for all perfmon log and profiler trace rollover files. This is done on a low priority background thread and has a negligible additional impact on the server.
  • Eliminate Profiler tracing if a trace is not required. The SQL profiler trace makes up the large majority of the data collected by PSSDIAG. To turn off profiler tracing, simply uncheck the "Profiler Trace" checkbox in the Diag Manager GUI when configuring the package. If you are NOT capturing a Profiler trace, you can run PSSDIAG from a remote machine if a secondary machine with more disk space is available.
  • If a Profiler trace is required, minimize the size of the trace - Depending on the issue that you are collecting data for, you can reduce the amount of data collected for a Profiler trace by eliminating high frequency events (refer section below for more details.
  • Enable the "Delete Old Trace Files" custom task group in PSSDIAG. This is a checkbox in the lower right quadrant of the Diag Manager GUI. When enabled, PSSDIAG will run a background job that deletes all but the X most recent profiler .TRC and perfmon .BLG files in the output directory. This may be a reasonable way to keep the trace data under control, assuming that you only care about the data captured during the problem period and a few minutes immediately preceding the problem. When you generate the PSSD.CAB package, the configuration application will ask you how many trace flies/perfmon files you want to keep. You will have to ensure that your customer can stop PSSDIAG soon enough after the problem occurrence to avoid losing trace data you need to troubleshoot the issue.
  • Consider using PSSDIAG’s /E and /L command line parameter to restart collection each night. This can be very useful if you need to trace for many days or weeks, and also helps keep the SQL Server Perf Stats script .OUT file and other .OUT files from growing too large. In the example command line below, the "/E 03:00:00" tells PSSDIAG to automatically stop collection at 3:00am every morning, and the "/L" (run continuously) tells PSSDIAG to automatically restart collection instead of exiting when the shutdown time is reached. The /Q (quiet mode) parameter suppresses the "Do you want to overwrite existing files?" prompt. Also added /N2 to automatically create a new folder as opposed to overwriting existing one.

    PSSDIAG.CMD /E 03:00:00 /L /Q /N2

  • If you have PSSDIAG reuse the same output folder like this, it will overwrite the previous day’s data each morning. This may be desirable, but if you would prefer to archive the previous day’s output and manually delete it if the problem hasn’t occurred, also add the /N2 command line parameter to tell PSSDIAG to rename the existing output folder when restarting collection each morning (previous days’ output folders will be named OUTPUT_00000, OUTPUT_00001, ...).
  • If you want to run PSSDiag for a specific amount of time (say 3 hours) from the start you can use

    PSSDiag.CMD /E +03:00:00

  • If you want to delay the start of the PSSDiag collection for a specific amount of time (say 3 hours) from now you can use

    PSSDiag.CMD /B +03:00:00

  • NOTE

    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. See KB929728 for details.
    • Always trace to a locally attached (or SAN) disk, never to a network share. See KB 307786.
    • 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 found here.
    • 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 actually increase 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 using fn_trace_getinfo function or sys.traces view.
      • Use the Trace ID obtained from the above step, and use the sp_trace_setfilter stored procedure to set the filter. Refer "SQL Profiler Data Columns" under SQL Server Books Online for the Data 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 the fn_trace_filterinfo function. 
  • Last edited Dec 5, 2011 at 1:54 PM by amitban, version 14

    Comments

    amitban Dec 5, 2011 at 1:49 PM 
    Answered your question here: http://sqlnexus.codeplex.com/discussions/281521

    udayhere Nov 30, 2011 at 6:05 PM 
    I have a question about setting filters to PSSDIAG trace. I read the steps above to add filter, but I am not sure if it is possible to accomplish it. I start pssDiag trace and get the traceid to add filter using "sp_trace_setfilter" but I get an error saying that the trace must be stopped before I can add a filter. But if I stop pssdiag trace, then it says no trace found with the provided traceid. Am I missing something? What do you mean by "Initialize PSSDIAG on the server ..." how do I do that.
    Thanks,
    _Uday
    sqltimes.wordpress.com