Stairway to Server-side Tracing - Step 1 - Overview of Tracing (Stairway Series)

  • Comments posted to this topic are about the item Stairway to Server-side Tracing - Step 1 - Overview of Tracing (Stairway Series)

  • Great article, looking forward for next step.

    I had a little problem when running the query - but it was easy to spot where the problem was.

    SELECT

    t.id AS TraceId ,

    path AS TraceFilePath ,

    tcat.name AS EventCategory ,

    tevent.name AS EventClassName ,

    tcolumn.name AS ColumnName

    FROM sys.traces AS t

    CROSS APPLY fn_trace_geteventinfo(t.id) AS tdef

    JOIN sys.trace_events AS tevent ON tdef.eventid = tevent.trace_event_id

    JOIN sys.trace_categories AS tcat ON tcat.category_id = tevent.category_id

    JOIN sys.trace_columns AS tcolumn ON tcolumn.trace_column_id = tdef.columnid

    WHERE t.is_default = 1 --default trace

    AND t.status= 1 --running

    ORDER BY TraceFilePath ,

    EventCategory ,

    EventClassName ,

    ColumnName ;

    thanks

  • A good start to an overview to SQL trace.

    It'd be useful if the next one detailed the difference between profiler and server side tracing where one uses rowset and the other file provider (guaranteed to be loss less).

  • Good article. Interested to read the next step. I expect you will include those sp_trace* procedures as well.

    A quick question on this, if the server side operation is to just dump the events collected into the client side application like profiler, then how would the server be affected in performance ? Won't that be an issue only at the client side (comparing the client side & server side traces)?

    Thanks,

    Rony

  • Looking forward to the rest of this series, thanks!

  • Rony, I'll cover the sp_trace* procs in detail in the next Stairway level, How to Create a SQL Trace Using T-SQL.

    With client-side traces, a SQL Trace rowset provider runs on the server to handle returning trace results to the client application. If the client doesn't consume trace data as fast as it is generated, the trace buffers fill on the server and server threads sending event data will wait for free buffers. Consequently, a slow trace consumer can slow down queries and overall server performance. The rowset provider waits up to 20 seconds before dropping trace events.

  • Good article... Looking forward to read the next part of the series...

  • sammesel (2/23/2011)


    Great article, looking forward for next step.

    I had a little problem when running the query - but it was easy to spot where the problem was.

    SELECT

    t.id AS TraceId ,

    path AS TraceFilePath ,

    tcat.name AS EventCategory ,

    tevent.name AS EventClassName ,

    tcolumn.name AS ColumnName

    FROM sys.traces AS t

    CROSS APPLY fn_trace_geteventinfo(t.id) AS tdef

    JOIN sys.trace_events AS tevent ON tdef.eventid = tevent.trace_event_id

    JOIN sys.trace_categories AS tcat ON tcat.category_id = tevent.category_id

    JOIN sys.trace_columns AS tcolumn ON tcolumn.trace_column_id = tdef.columnid

    WHERE t.is_default = 1 --default trace

    AND t.status= 1 --running

    ORDER BY TraceFilePath ,

    EventCategory ,

    EventClassName ,

    ColumnName ;

    thanks

    Even using this modified code my server will still not parse?

    Msg 102, Level 15, State 1, Line 8

    Incorrect syntax near '.'.

    Seems to be failing at the parameter (t.id) ?

    Microsoft SQL Server 2005 - 9.00.3080.00 (X64) Sep 6 2009 09:15:46 Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 2)

  • The Server-side Tracing stairway is targeted at SQL 2005 and later versions. Since the error message refers to the CROSS APPLY line, I suspect you are either running this on a SQL 2000 server or from a user database in SQL Server 2000 compatibility mode (80).

  • Hah! You're absolutely correct! The DB is indeed running in (80) compatibility mode :pinch:

    Thanks for the quick response...

  • sammesel is right, but this code should be corrected in the article. Please and thank you. 😛

  • I corrected the script in the article shortly after Sammesel brought this to my attention. As I mentioned in my other response, the other issue is that the script is intended for databases in 90 and later compatibility mode.

    Thanks,

    Dan

  • Hi Dan,

    First, thanks for the article, it's been very helpful.

    I saw your earlier reply regarding the versioning, and I should have been clearer. I was referring to the missing spaces in the FROM section, which should be corrected to:

    FROM sys.traces AS t

    CROSS APPLY FN_TRACE_GETEVENTINFO(t.id) AS tdef

    JOIN sys.trace_events AS tevent ON tdef.eventid = tevent.trace_event_id

    JOIN sys.trace_categories AS tcat ON tcat.category_id = tevent.category_id

    JOIN sys.trace_columns AS tcolumn ON tcolumn.trace_column_id = tdef.columnid

    It's simple to correct, but the original doesn't parse in SSMS as is.

    Thanks for the quick response,

    Mike

  • Thanks for pointing out the missing spaces in the script. The edit tool didn't preserve the original spaces so I added them back. The revision is awaiting appoval.

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply