After finishing the salary survey I was kicking around ideas for the next one and thought about one of the sessions I presented at SQL Connections in Spring this year and Fall last year about undocumented tips and tricks (just the tip of the iceberg!). In that presentation I covered a bunch of trace flags that I thought would be useful to people (and I'll be blogging about some of them – just blogged about checkpoint information trace flags over on our SQL Mag blog) and I was wondering when people would use them.
So this survey is about your comfort level with using trace flags in production.
I've left the "Other" option open if you want to go into more detail.
I'll report on the results in a few weeks.
6 thoughts on “Survey: what’s your comfort level with trace flags in production?”
It depends on what the traceflag is and how critical the databases on the server are.
Trading system at a bank? I’ll be looking for multiple reputable sources and I’ll have it enabled on test for as long as possible.
Non-critical reporting database? I’ll be OK enabling something that just been mentioned by a reputable source.
Either way, if I don’t understand what it’s supposed to do, it is not getting enabled, not on production.
I’m with Gail.
I’ll want to totally understand what it’s going to do, so if it’s documented great. If it’s undocumented but I’m familiar with it then good. If it’s new to me then it’s going into test \ UAT for as long as possible.
I like the option that says put DBCC TRACEON in a loop :)
I’m not sure about the validity of a survey with "if" responses. Many people probably have never used trace flags in production, but leave a remote option that they may use it. What does that say about us? I’m not sure. I’m curious what you’ll information you’ll glean from this. ;)
I don’t know either :-) None of my surveys are really statistically valid, but at least give a sense of the prevailing views out in the field.
The Only Trace Flag we use in Production right now is TF 1118. History says that our previous DBA’s enabled it in SQL Server 2000 because Kimberly Tripp advised it :-)