SQLPerf: Measuring anything has an effect on it

I’ve been back doing SQL performance tuning work this week. This morning I had a good reminder that whenever you measure something you have an effect on it. The procedure I was working on was at the head of 46% of all blocking chains on the site yesterday. When I looked into it, the #1 reason it was blocking was the call:

 — DEV ENV ONLY : Log this query call

EXEC p_XXX_DAF_LogQueryRequest ‘p_XXX_DAF_L2M_CTSGetGroup’


(name modified to keep details private). This call is at the beginning of every procedure on the site. It counts the number of times the proc has been called at that nesting level and updates a datetime value that remembers when the proc was last called.


But the irony is that 75% of the work in the proc I was working on and the #1 reason for it blocking, was that call and nothing to do with the real work the proc was doing. And by the comment, it’s only meant to be used in the dev environment anyway.


TechEd US – Orlando – Done and dusted

TechEd US is now done and dusted. It was a great event. I really enjoyed the chance to catch up with so many people from the SQL MVP community, the RD community and others.

I ended up doing a series of interviews at Virtual TechEd (www.virtualteched.com). Not sure when they’ll get posted up but there’s some great material on that site for those that couldn’t make it to the event in person.

Thanks to the INETA and Culminis folk for organising the Birds of a Feather session on user groups. I was one of a panel of five organising that session and it seemed to go very well, apart from a lack of time.

Thanks to all that attended my two sessions in the data track. I appreciated the number of people that attended sessions first thing in the morning, particularly the DMV session which was the morning after the attendee party. For those that have asked, I have put a copy of the DMV session materials here.