Enable Trace Flags in SQL Server

  • Is there any negative impact to adding trace flags to a server startup proc?  More of as a failsafe that anything...

    ______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience

  • Not by adding them to a startup proc. The trace flags themselves can alter behavior, so they should be tested in your environment.

     

  • Thanks Steve, was just seeking confirmation. I realize this isn't a "standard" or best practice per say, but always have added it in to facilitate server builds across large distributed teams.  In our shop we all use an agreed upon MSSQL build document and the trace flags get set in the configuration portion during the build itself.  They are also added to the startup proc in case a DBA misses a step or simple "forgets".   In that scenario, after all the databases come online, the start proc will fire and enable any flags that might have been missed.

    ______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience

  • I don't think there are any issues with re-enabling a trace flag that is enabled in the Configuration Manager/Services applet. This certainly gives you a second place where things are enabled, but I'd doc this, as if someone disables a trace flag during startup, and then you re-enable it with the proc, this can cause issues. For example, MS Support says turn this off and the DBA does, but forgets about the startup proc.

    Maybe you want to add a RAISERROR WITH LOG in the startup proc as well to note that you've set a trace flag.

  • Viewing 12 posts - 1 through 11 (of 11 total)

    You must be logged in to reply to this topic. Login to reply