Troubleshooting SQL Profiler

Here are some problems you may encounter when using SQL Profiler:

• When setting filters, a blank include filter includes all items in the SQL Profiler output. A filter on a data column is not applied to event classes that do not populate that data column.
  
  
• Because the SQL Profiler stored procedures save trace queue definitions on the server rather than on the client, SQL Profiler is unable to edit or start a trace created originally with the stored procedures.
  
  
• For security reasons, batches containing stored procedures with password arguments are not traced. Instead, an event is produced, which replaces the batch text with a comment.
  
  
• In Microsoft® Windows® 95 and Windows 98, SQL Profiler does not accept client configuration changes until the SQL Profiler is closed and restarted.
  
  
• SQL Profiler can incur problems accessing files on a remote computer if those files become unavailable.

Here are some common problems you may encounter when replaying a SQL Profiler trace:

• Replay errors may occur when logins and users captured in the trace do not exist in the target database. If the logins and users exist in the database, they must have the same permissions as they did in the source (traced) database.
  
  
• Replay errors may occur when the database ID (DBID) of the target database is different from the DBID captured in the trace. To correct this problem, restore a backup of the master database of the source (traced) server onto the target server. Then, restore the user database or databases. As an alternative, the DBID data column can be removed from the trace and the default database set to the target database for each user captured in the trace.
  
  
• Replay errors may occur when attempting to replay a trace against a database if it is in a different state than from the source (traced) database. Updates may fail if data is missing or changed.
  
  
• System performance may degrade if replaying a trace that contains more concurrent connections than the replay computer can manage. In this case, the trace may be filtered by Application Name, SQL User Name, or another filter if one or more of these data columns were captured in the trace.
  
  
• Replaying captured events containing the KILL statement may cause unexpected replay results; the SPID that is terminated may not exist or, if it does exist, the SPID may be assigned to a different user or connection than the one traced originally.
  
  
• When replaying a trace file as fast as possible, SPIDs may become blocked, halting the progress of the replay. To free the blocked SPID and allow the trace to continue, kill the blocking SPID.