At SQLServerCentral, we recently published a list of all the trace flags from Konstantin Taranov. It's a great list, and thanks to Konstantin for compiling it. While I haven't often used trace flags, there are some that have really helped me at various times when I needed to change SQL Server behavior. If you aren't sure what trace flags are, Erin Stellato of SQLskills wrote a great post recently. I see trace flags as feature flags. The development team can allow us to experiment, test, and use functionality at our discretion, or ignore it.

This week, I wanted to ask how many of you are using Trace Flags right now. Do you have any running in code or set for startup on your instances? If you don't know how to do this, we've got a short piece to help you.

In Erin's post, she notes that SQLskills only recommends three trace flags (depending on version) for their customers. In general, I think that's good advice. There is a risk with using flags, and certainly I would be wary of using without substantial testing. I do think Erin's list is good, and you might consider using those. I also become wary about trace flags that aren't embedded directly in code. I think these trace flags end up being hidden from anyone troubleshooting issues. After all, how many of you actually go to the Configuration Manager or the Services Applet and look for parameters?

I expect that most of you don't run trace flags on your instances. There may be some of you that have never heard or, or used, a trace flag in your career. That's fine, though I hope you use today to a) let us know, and b) educate yourself to ensure you know how to enable a flag you need one. If nothing else, add one to a test instance, and ensure you have the skills to actually make the change.