Performance Tuning with Traces
This past Saturday, I presented "Performance Tuning with Traces" at SQL Saturday #47 in Phoenix, Arizona. You can download my slide deck and supporting files here.
This is the same presentation that I did in September at SQL Saturday #55 in San Diego, however I focused less on my custom server-side trace tool and more on the steps that I take to troubleshoot a production performance problem which often includes server-side tracing.
If any of my blog readers attended the presentation, I'd love to hear your feedback. I'm specifically interested in hearing constructive criticism. Speaking in front of people is not something that comes naturally to me. I plan on presenting in the future, so feedback on how I can do a better job would be very helpful. My number one problem is I talk too fast!
Legacy Comments
|
Dan
2011-02-24 |
re: Performance Tuning with Traces Hey Tara, I attended your session at SQL Sat 47 (I was the one from San Diego as well). Overall I thought your presentation was great, and in talking to some of the others that were there, I know they felt similar. I've been fortunate in that I've caught both of your sessions (both SD and PHX). The only problem I would have from your Phoenix presentation was that, if I hadn't seen your presentation before in San Diego, I'm not sure I would have followed your section in regards to your custom SQL Trace. If I recall correctly, it was one brief slide and didn't go into a lot of details. This is definitely a valuable resource that brings everything you talk about together. I've personally used it in production and can vouch for how valuable that information is (especially having it stored in tables). Other then that, I would say the presentation was a success. I really enjoyed the real world examples you gave, which really drives home the importance of this information you presented. Thanks Tara! Dan |
|
tarad
2011-02-24 |
re: Performance Tuning with Traces Thanks Dan, appreciate the feedback! It was nice to meet you. It was a tough decision to spend less time on the custom SQL Trace tool. I went that route this time around because my SD presentation went over 60 minutes and I didn't get to some of the information that I had wanted to. That plus my PHX session was the last slot of the day, so I wasn't sure if I could keep people's attention that late in the day. After I ended around the 45-minute mark, I should have gone back to the tool since we had extra time to do it. I definitely see your point and will adjust my focus a bit for the next time I present this topic. |
|
Anita
2011-03-02 |
re: Performance Tuning with Traces I attended your session in Phoenix and I thought it was very interesting. I didn't have trouble following your presentation although you do talk fast. :) I was fascinated to learn that it IS OK to run a server side trace at all times even on a high transaction environment. Currently I work in a very informal environment as an all-around DBA working with all aspects of SQL Server administration/development/business intelligence. At some point I'd like to specialize but have trouble deciding the route to go towards. As a production DBA, when you are on call, how often do you actually get called to resolve a problem? Thanks! |
|
tarad
2011-03-02 |
re: Performance Tuning with Traces On a typical week, the on-call DBA gets paged on average about 2 times at night (not two times a night). We've had some very rough on-call weeks the past year though, but we are addressing that by being more proactive. Being a production DBA can suck due to on-call duties, so make sure the compensation is right. |