SQL Trace 1.

Create the Trace you want in SQL Profiler, on a SQL connection, setting a Trace Name (I used DizelTrace), Save To File with a file name (D:\ TRACE.OUT))and a file size large enough to hold the data in a single file (I used 32MB), and the Events / Data fields you want to trace. Run the Trace. 2. Stop the Trace - we don't actually want to collect anything at this point. 3. Export the trace definition - select "File|Export|Script Trace Defintion|For SQL 2005..." Export the definition to a .SQL file of your choice. 4. Close Profiler; we're done with it at this point.In the SQL job with the step you want to trace, you're going to add a couple of steps before the step you want to trace... 5. Add the following code to a T-SQL job step, named Rename SQL Trace File, before the step you want to trace (this step is just to make sure there isn't a file from a previous run, just in case): EXECUTE master.dbo.xp_cmdshell 'D:\ rentrc.cmd rentrc.cmd ren D:\TRACE.OUT.trc Trace_%date:~4,2%%date:~7,2%%date:~10,4%%time:~1,1%%time:~3,2%%time:~6,2%%time:~9,2%.trc umjesto: --DECLARE @OS_Cmd VARCHAR(1024) --SELECT @OS_Cmd1 = ren D:\ TRACE.OUT Trace_%date:~4,2%%date:~7,2%%date:~10,4%%time:~1,1%%time:~3,2%%time:~6,2%%time:~9,2%.OUT"' --EXECUTE master.dbo.xp_cmdshell @OS_Cmd1 --SELECT @OS_Cmd2 = DEL /Q /F C:\Trace Files\DizelTrace.trc"' --EXECUTE master.dbo.xp_cmdshell @OS_Cmd2 6. provjeri da li radi
7. You need to stop the trace. Add this code to a T-SQL step named Stop SQL Trace; note that the file name in the WHERE clause must match the file name you specified above in the Start SQL Trace step, with the '.trc. added to the end: DECLARE @TraceID INT SELECT @TraceID = TraceID FROM :: fn_trace_getinfo(0) WHERE CAST([value] AS VARCHAR(256)) = 'D:\ DizelTrace.trc' IF @TraceID IS NOT NULL BEGIN PRINT 'Closing Trace ID ' + CAST (@TraceID AS VARCHAR(5)) EXEC sp_trace_setstatus @TraceID, 0 EXEC sp_trace_setstatus @TraceID, 2 END

0 Stops the specified trace. 1 Starts the specified trace. 2 Closes the specified trace and deletes its definition from the server.

LISTAM
SELECT *FROM ::fn_trace_gettable( 'D:\Trace.out.TRC', default) --WHERE textdata like '%Drop%'

Kod kreiranja trace-a

declare @rc int declare @TraceID int declare @maxfilesize bigint set @maxfilesize = 50 exec @rc = sp_trace_create @TraceID output, 0, N'D:\MSSQL\traceN', @maxfilesize, NULL if (@rc != 0) goto error The first section of this code is setting up @TraceId and @maxfilesize variables. The @TraceId will be used to get the id of the trace back from the stored procedure that creates the trace. The @maxfilesize variable configures how big the file is allowed to get, once the file reaches this size the trace stops.

The next section of code creates the trace by calling the sp_trace_create stored procedure. This creates the trace but does not start it. The first parameter passed to this stored procedure is the @TraceId, this is an output parameter and this parameter will be populated with the Id of the trace that is created. The second parameter specifies whether to use rollover files, when this parameter is set to 0 then rollover files will not be used, and when the file reaches the max file size the trace stops. Ako je parametar 2 onda se rollover koristi. If this parameter is set to 1 then when the file size reaches the max size, then it rolls over to a new file. The third parameter specifies what file to output the trace to, when SQL Server Profiler generates the script it just puts a generic value in here, you need to replace it with the path and file name that you want the trace data saved to. The forth parameter specifies the max file size. Next the script uses a bunch of sp_trace_setevent statements to configure what events should be traced, this is the part that is really nice to have generated for you.
declare @on bit set @on = 1 exec sp_trace_setevent @TraceID, 109, 7, @on exec sp_trace_setevent @TraceID, 109, 23, @on itd...

Next the script uses the sp_trace_setfilter stored procedure to set the filters for the trace. Finally it uses the sp_trace_setstatus stored procedure to set the status of the trace to 1, which starts the trace.
exec sp_trace_setstatus @TraceID, 1

Once the trace has started collecting data you can used the fn_trace_gettable function to query the data in the file. This function takes two parameters, the first parameter is the file to load, and the second parameter is how many rollover files to load. If you are not using rollover files then you can just pass in a value of 1 for the second parameter. The beauty of this is that you can easily us a SELECT INTO statement to load the file into a table, and then run whatever queries you want against it. For example to load my trace file into a table I used the following query: SELECT * INTO MYTraceTable FROM fn_trace_gettable(N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\testrace.trc', 1); This loads the trace data from the file into the MyTraceTable table. You an not run whatever queries you want against this data. Personally I have found that when I am debugging a application, and want to see what SQL code is being executed against a database it is easier to just use SQL Server Profiler. SQL Server Profiler makes it very easy to start and stop a trace, and it displays the SQL code in a format that is fairly easy to read. When I am run a trace that I want to being running unattended, or if I am looking at performance data, then I find server side traces to be more useful.