December 2, 2009 at 9:24 am
G33kKahuna (12/2/2009)
Jacek, Giving you a hard time was not my intention. When you post an article with a title "Using Server Side Traces for Dynamic Performance Evaluation" but offer up very little in the world of performance evaluation; you got to expect challenges. Sorry you feel chastised ...
I did not feel chastised at all. I might be a bit disappointed you did not find anything useful in this article. 😉
As I mentioned before - everyone is entitled to their own opinions and each opinion is as valuable as any other.
I can put it this way - your job is to express your opinion - my job is to accept it or ignore it. No hard feelings...
As far as the dynamic part is concerned I think you might have taken the wrong definition of the word 'dynamic'. The dynamic refers to the dynamics of the various SPs have on each other rather then about the on the spot performance measurements of the system. If you need the 'right now' (dynamic) view into the system then the DMV you mentioned are probably just fine.
For example one lesson I learned using the method described in the article is how the autogrowth of the log and data files can negatively impact the performance of SPs in extreme cases.
---------------------------------------------
[font="Verdana"]Nothing is impossible.
It is just a matter of time and money.[/font]
December 2, 2009 at 11:51 am
Jacek,
I see that you SELECT the TraceID at the end of your Procedure - how do you turn the trace off with that technique? Does it run until C: is full?
Just Wondering,
Doug
December 2, 2009 at 11:59 am
To stop the trace use sp_trace_setstatus @traceID, 0
To delete the trace definition use sp_trace_setstatus @traceID, 2
The @traceID is the ID you got when you run the code provided in the acticle.
---------------------------------------------
[font="Verdana"]Nothing is impossible.
It is just a matter of time and money.[/font]
December 2, 2009 at 10:22 pm
G33kKahuna - Is it your position that server side trace information offers no value in troubleshooting performance issues? What “fantasy world” are you living in?
Tommy,
Which part of my response said server side trace is bad? infact the wait types I mentioned can be captured only on the server side ...
Sounds like you are suggesting that avg read, write and cpu are the only server side performance indicators .... looks like you got a lot to catchup on SQL Server performance tuning bud ... :hehe:
Look up Andew Kelly, Paul Randel, Jimmy May and Linchi Shea articles
JacekO, I would have calibrated SQL Wait & Waiting stats for autogrows but you seem to prefer your approach ... fair enough and peace.
December 3, 2009 at 4:34 am
nice article jacek!
"Keep Trying"
December 3, 2009 at 8:32 am
G33kKahuna (12/2/2009)
G33kKahuna - Is it your position that server side trace information offers no value in troubleshooting performance issues? What “fantasy world” are you living in?
Tommy,
Which part of my response said server side trace is bad? infact the wait types I mentioned can be captured only on the server side ...
Sounds like you are suggesting that avg read, write and cpu are the only server side performance indicators .... looks like you got a lot to catchup on SQL Server performance tuning bud ... :hehe:
Look up Andew Kelly, Paul Randel, Jimmy May and Linchi Shea articles
JacekO, I would have calibrated SQL Wait & Waiting stats for autogrows but you seem to prefer your approach ... fair enough and peace.
G33kKahuna - We are talking in circles...I merely supported the analysis of server side trace data as a tool to troubleshoot performance issues; not the end all be all. Your arrogance is unbecoming. Perhaps we should take this offline.
Tommy
Follow @sqlscribeDecember 3, 2009 at 4:45 pm
Your arrogance is unbecoming. Perhaps we should take this offline
Jacek's article was debate worthy. I believe he and I don't see eye to eye on the evaluation approach .... he did clarify his position as well.
You jumped in the middle from nowhere with a pitbull attitude. You lacked skills to support your own argument or counter mine, not to mention lack of comprehension. Like I said before you offered, I would be more than happy to debate you offline but after your response from yesterday; it would be a waste of time .... cheers
December 3, 2009 at 5:49 pm
G33kKahuna (12/3/2009)
Your arrogance is unbecoming. Perhaps we should take this offline
Jacek's article was debate worthy. I believe he and I don't see eye to eye on the evaluation approach .... he did clarify his position as well.
You jumped in the middle from nowhere with a pitbull attitude. You lacked skills to support your own argument or counter mine, not to mention lack of comprehension. Like I said before you offered, I would be more than happy to debate you offline but after your response from yesterday; it would be a waste of time .... cheers
That was not my intention and if I insulted you in anyway, please accept my apologies. I found the article insightful and was merely trying to support the author for his contribution. Feel free to PM me offline.
Updated this post to include an example; using the information below we were able to hone in on Procedure_C; closer inspection of the execution plan in the server side trace revealed a missing index; i.e.
Object Name # of Executions Avg_Reads Avg_Writes Avg_CPU Avg_Duration Max_Duration
Procedure_A30026830023413
Procedure_B292588202603
Procedure_C1835102010246251
Object Name< 11 - 2 Seconds3 - 5 Seconds5 + Seconds
Procedure_B2234512 134 0
Procedure_A2285510 118 0
Procedure_C1032418 235 150
Tommy
Follow @sqlscribeViewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply