Is there any specific reason that you shouldn't turn on the default trace on production server. Is enabling the query store is option to default trace?
April 26, 2022 at 12:42 pm
Since you're posting in a SQL Server 2017 forum, I'm going to give an answer that applies to 2012 or greater. Less than 2012, it's a different answer.
Don't enable the default trace on your servers. There are two reasons for this. First, and most important, traces, trace events, and the profiler, all put a much greater load on your systems than the alternative. The alternative is Extended Events, and you already have the default trace equivalent there, system_health, enabled by default. Use that instead. It's enabled on every system you have (except Azure SQL Database) right now unless you have specifically disabled it. Add the default trace will just add overhead without adding very much at all in the way of functionality.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Like I said at one of your previous posts ( https://www.sqlservercentral.com/forums/topic/transaction-log-growth-index-manintenance-jobs-database-functional-jobs#post-4021517 ), there's not much use of it on a busy system because the life=time expectancy of data in that rather small table can be measured in low minutes.
That also means that I agree that it's frequently just not worth having turned on.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply