August 9, 2015 at 3:57 am
Hold it people I just had a thought (can't believe I'm so pathetic to think of such things on a Sunday morning LOL!)...
As the purpose of the replay will be stress-testing just as much as analysis (I need to make the replay server collapse and THEN do a post-mortem) am I right to suspect the trace definition will have to capture everything, ie ALL Events/Columns? Normally for pure analysis I'd strip it down to just RPC Completed/SQL Batch Completed, and columns Text/CPU/Reads/Writes/Duration/SPid/StartTime?
August 9, 2015 at 5:42 am
RPC Completed and SQL Batch Completed should be enough. The columns you listed sound good too.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
August 9, 2015 at 6:15 am
No, you don't need everything, however replay requires a very specific set of events and columns. Use the T-SQL Replay template and don't change anything after
eg you need the established connections event.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 10, 2015 at 3:49 pm
GilaMonster (8/9/2015)
No, you don't need everything, however replay requires a very specific set of events and columns. Use the T-SQL Replay template and don't change anything aftereg you need the established connections event.
I took a look - that is a big template, but yes, will do.
Another possible 'gotcha that's been raised is that much of the server workload uses GUIDs that are dynamically generated during a session - in your experience, if I synch the test database to it's prod equivalent immediately before running the trace, would that suffice, or is there any other measures I need to take?
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply