DiagManager Wiki Rss Feed

Updated Wiki: FAQ

amitban — Mon, 05 Dec 2011 14:54:45 GMT

Fequently asked questions (FAQ)

I received an error, what should I do?

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.

New Comment on "FAQ"

amitban — Mon, 05 Dec 2011 14:49:54 GMT

Answered your question here: http://sqlnexus.codeplex.com/discussions/281521

New Comment on "FAQ"

udayhere — Wed, 30 Nov 2011 19:05:45 GMT

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

New Comment on "FAQ"

udayhere — Wed, 30 Nov 2011 19:04:53 GMT

New Comment on "FAQ"

udayhere — Wed, 30 Nov 2011 18:45:43 GMT

New Comment on "COMMON_ISSUES"

crossman — Thu, 09 Jun 2011 19:36:39 GMT

The pssdiag.cmd references 'diagutil.exe' which is not valid. I assume it is supopsed to be SQLDiag.exe but when I changed it and ran it it hung and did not collect anything. I added a pause command after the 'if "%toolsbin%"=="" set toolsbin=' command and never got the prompt so I know it's hanging before this. If I remove the lines containing the "for /F "tokens=1,2 delims==~" %%i IN ('SQLdiag.exe')" commands, it works but not until I manually copied the pssdiag.xml from the cab file to the same location as pssdiag.cmd.

New Comment on "COMMON_ISSUES"

crossman — Thu, 09 Jun 2011 19:04:12 GMT

Updated Wiki: COMMON_ISSUES

jackli — Wed, 25 May 2011 20:04:53 GMT

Common Issues

Updated Wiki: COMMON_ISSUES

jackli — Wed, 25 May 2011 20:04:31 GMT

Common Issues

Updated Wiki: FAQ

jackli — Wed, 25 May 2011 20:00:08 GMT

Fequently asked questions (FAQ)

I received an error, what should I do?

See Common Issues section.

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

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

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

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

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:

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.

Updated Wiki: FAQ

jackli — Wed, 25 May 2011 19:59:06 GMT

Fequently asked questions (FAQ)

I received an error, what should I do?

See Common Issues.

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

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

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

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

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:

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.

Updated Wiki: FAQ

jackli — Wed, 25 May 2011 19:58:38 GMT

Fequently asked questions (FAQ)

I received an error, what should I do?

See Common Issues.

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

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

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

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

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:

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.

Updated Wiki: The version of this file is not compatible with the version of Windows you're running. Check your commputer

jackli — Wed, 25 May 2011 19:55:27 GMT

You may receive the following error:
"The version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need an x86(32-bit) or x64(64-bit) version of the program, and then contact the software publisher."

We have had users how mistakenly name the final package as pssd.exe. Current version only supports cab file. When you create the package, you need to name it pssd.cab. Windows XP and beyond can extract cab files without requiring a zip utility.

Updated Wiki: COMMON_ISSUES

jackli — Wed, 25 May 2011 19:52:31 GMT

Common Issues

Updated Wiki: FAQ

amitban — Tue, 24 May 2011 23:19:33 GMT

Fequently asked questions (FAQ)

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

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

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

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

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:

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.

Updated Wiki: Data Collection Output Files

jackli — Tue, 24 May 2011 15:29:03 GMT

Data Collection Output Files

Where are output files

There will be an output folder from where you run you pssdiag package.
If you plan to use the data for SQL Nexus, all you need to do is to point SQL Nexus to the output folder. SQL Nexus will figure out what to do with each file.

File types

.trc: profiler trace file
.blg: perfmon capture
.out: these are output file from TSQL Script run.
.mdmp: userdump from SQL Server process
.reg: registry export

File naming conventions

A file can contain serveral things including machine name, SQL Server instance name, startup or shutdown key words.
Generally it's in format <machine name>_<instance name>_<data collector name>_startup(or shutdown)
Example:

Server1_KJ64BIT_SQL_2008_Perf_Stats_Startup.OUT means that the data was collected from Server1, SQL Server instance KJ64bit. The data came from collector SQL_2008_Perf_stats. The collector was started from the beginning.
Server1_KJ64BIT_SQL_2008_Perf_Stats_Snapshot_Shutdown.OUT means that the data was collected from server1, SQL Server instance KJ64bit. The data came from collector SQL_2008_Perf_Stats_Snapshot. It was started at end of the data collection.

Internal Files

For 2005, in the output folder, there are files beginning ##. These are internal files.
For 2008 and 2008 R2, there will be an internal subfolder within the output folder. All the files are internal files.

Updated Wiki: FAQ

jackli — Tue, 24 May 2011 15:27:25 GMT

Fequently asked questions (FAQ)

I saw many differnt files in the output folder, what are these files?

This page has information on what theyse files are and naming conventions

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

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

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

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:

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.

Updated Wiki: Collecting Data for SQL Nexus

jackli — Tue, 24 May 2011 15:24:27 GMT

Collecting Data For SQL Nexus

Step by Step tasks has detailed info on how to collect data.
For SQL Nexus, just choose version, platform and leave everything else as default. SQL Nexus will be able to analyze the data collected. SQL Nexus just need you to point to the output folder. For the curious this page has more information about output files.
Alternatively, you can choose a detailed trace template. The screenshot below let you choose either GeneralPerformance10.xml or DetailedPerformance10.xml. If you choose _DetailedPerformance10.xml for tracing, more trace events will be captured but it can add load to your system in terms of IO requirement.