Introduction

A common cause of mysterious performance issues are traces that have been left running. Naïve use of traces can leave many traces running—traces that are slowing down the application by consuming critical resources. This happens because the SQL Server Performance Analyzer process is killed or trace sessions forgotten. In analyzing an issue, many traces may be created and left running.

Scripts

I see this issue enough that I have created some scripts for the issue. The following query will tell you which non-default traces exist:

use [master]

select T.id as [Id],
       case T.statuswhen 0 thenN'stopped'elseN'running'endas [Status],
       T.pathas [Path],
       case T.is_rowset when 0 thenN'false'elseN'true'endas [Rowset],
       case T.is_shutdown when 0 thenN'disabled'elseN'enabled'endas [Shutdown option],
       T.start_time as [Start],
       T.stop_time as [Stop]
fromsys.tracesas T
where T.is_default <> 1;

The following query can be used to close all non-default traces it also lists their locations.

use [master];

setnocounton;

declare @result table ([Path] nvarchar(260)notnull);

declare trace cursorlocalfast_forwardforselect T.id, T.path
                                            fromsys.tracesas T
                                            where T.is_default != 1;
                                            
open trace;

declare @id int;
declare @path nvarchar(260);

fetchnextfrom trace
  into @id, @path;
 
while@@fetch_status= 0
begin
   executesp_trace_setstatus
     @traceid = @id,
     @status = 0;
    
   executesp_trace_setstatus
     @traceid = @id,
     @status = 2;
    
   if (@path isnotnull)
   begin
     insertinto @result([Path])
       values (@path);
   end;

       fetchnextfrom trace
         into @id, @path;
end;

close trace;
deallocate trace;

select R.[Path] as [Path]
from @result as R;

In general, the queries require view server state permission:

grantalter traceto [login name];