Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Stairway to Server-side Tracing - Step 3: Creating a SQL Trace Using SQL Server Profiler Expand / Collapse
Author
Message
Posted Monday, February 14, 2011 10:37 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, August 25, 2014 3:38 PM
Points: 55, Visits: 294
Comments posted to this topic are about the item Stairway to Server-side Tracing - Step 3: Creating a SQL Trace Using SQL Server Profiler
Post #1063689
Posted Thursday, February 17, 2011 9:46 AM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Thursday, March 6, 2014 7:07 AM
Points: 660, Visits: 639
Nice Article, but just a simple question. Why the date is in the future: Stairway to Server-side Tracing - Step 3: Creating a SQL Trace Using SQL Server Profiler
By Dan Guzman, 2011/04/20
Post #1065799
Posted Thursday, February 17, 2011 8:43 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, August 25, 2014 3:38 PM
Points: 55, Visits: 294
I honestly don't know why the date is in the future. Maybe it's because SQLServerCentral.com figured I'd have a better chance meeting a deadline 3 monthos out
Post #1066129
Posted Thursday, February 24, 2011 9:44 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 27, 2014 9:08 AM
Points: 1, Visits: 24
Nice article. I'm really enjoying this series.

Just one little issue with listing 4 the last line of which should read ',@status = 2 ;-- delete trace'
Post #1069065
Posted Thursday, April 21, 2011 3:09 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Wednesday, September 10, 2014 3:19 AM
Points: 5,371, Visits: 1,391
Nice one...


Post #1096835
Posted Wednesday, July 24, 2013 5:59 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Yesterday @ 12:14 PM
Points: 596, Visits: 1,688
I'd like to hear some feedback on how to handle it when you trace your production box, say main database is called Production, then try to replay those trace files on a development box where a copy of the database is called Test and has a different databaseID.
Some brief research makes it look like you can load the trace files into a table, from Profiler, then update either the database id and/or database name in the trace table, before trying replay.



Post #1477016
Posted Wednesday, July 24, 2013 8:45 AM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 14, 2014 12:45 PM
Points: 21, Visits: 225
I use this method for a time and i continue thinking that is the most friendly for newby database developers to debug.

Exelent explanation.
Post #1477107
Posted Thursday, July 25, 2013 5:48 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, August 25, 2014 3:38 PM
Points: 55, Visits: 294
Indianrock (7/24/2013)
I'd like to hear some feedback on how to handle it when you trace your production box, say main database is called Production, then try to replay those trace files on a development box where a copy of the database is called Test and has a different databaseID.
Some brief research makes it look like you can load the trace files into a table, from Profiler, then update either the database id and/or database name in the trace table, before trying replay.


That is correct - open the server-side trace file(s) in Profiler and save to a table so that you can modify trace data prior to replay. Alternatively, create and load a table with the same schema Profiler expects for the replay. Example code below. Note that you may have database names embedded in the TextData so make sure you change those too.

SELECT
IDENTITY(int, 0, 1) AS RowNumber
,EventClass
,BinaryData
,DatabaseID
,NTUserName
,NTDomainName
,HostName
,ClientProcessID
,ApplicationName
,LoginName
,SPID
,StartTime
,EndTime
,Error
,DatabaseName
,RowCounts
,RequestID
,EventSequence
,IsSystem
,ServerName
,TextData
,EventSubClass
,Handle
INTO dbo.replay_trace
FROM fn_trace_gettable(N'C:\Traces\ReplayTrace.trc', default);


Post #1477445
Posted Thursday, July 25, 2013 6:05 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Yesterday @ 12:14 PM
Points: 596, Visits: 1,688
Thanks !! I did dump a trace file into a trace table, updated just the database name ( since the database IDs were the same on prod and dev ) and replayed from the table.

What I've been asked to do is test sql 2012 compression on some of our busiest tables to see if it improves IO. I'm still thinking it might be easier to find some of our most intensive select statements, drop data buffers and plan cache, record the runtime of the "select" before compression and after --- instead of trying to accomplish the same via profiler trace replays.

My manager thinks, due to previous experience using the profiler GUI on a production stock market-related database, that profiler doesn't "always hose production."

I'm sticking with server-side because we have seen in the past that unless dialed down to a very few events with filters, and run just for the duration of one problematic query, it does hose production. So far server-side, using the tsql replay template, has no noticeable affect on production. I'm dumping 100mb trace files to a spot on our Netapp filer in production, and it creates a new 100mb file about every 5 seconds.

Given that, I don't think we're going to be able to trace an entire business days traffic and replay it on a much less powerful QA box.




Post #1477450
Posted Thursday, July 25, 2013 6:55 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Monday, August 25, 2014 3:38 PM
Points: 55, Visits: 294

My manager thinks, due to previous experience using the profiler GUI on a production stock market-related database, that profiler doesn't "always hose production."


A properly filtered Profiler trace won't impact production much. Although your manager's experience may vary, I have personally seen a DBA unwittingly crash a production stock market-related database with an unfiltered Profiler trace of several thousand events per second. Even if the server doesn't become entirely unresponsive, a Profiler trace of high-volume events will slow response time and throughput considerably.

Level 10 of this Stairway details the performance difference of a T-SQL Replay trace using Profiler versus a server-side trace. I think you are wise to stick with a server-side trace for this task
Post #1477464
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse