One of the ways that you can take more direct control over your SQL Server instances is through the use of trace flags. There are a number that many people recommend you enable by default. Prior to Extended Events, for example, I’d say you should turn on trace flag 1222 in order to capture deadlock information on your server (now I just recommend you use the system_health session). I absolutely think you should turn on trace flag 2371 to get better behavior out of your automated statistics updates. I’ll leave the systems experts to advise you on the others.
What about Azure SQL Database?
I doubt you’ll be shocked, but if I try this:
| 1 | DBCC TRACEON (2371,-1); |
I get the following error:
This error makes sense right? We’re talking about a Platform as a Service (PaaS). You’re only managing the database, not the server, so you don’t have access to control underlying server behavior.
How about if we just want to modify the behavior of a query? You can use the query hint QUERYTRACEON to adjust behavior. For example, the new statistics cardinality estimation engine in 2014 and better is absolutely marvelous. It’s in use in Azure SQL Database. However, there are edge cases where the old way can work better for certain queries. If you want to go to the old cardinality estimation engine in SQL Server 2014/2016, you use traceflag 9481 in a query hint like this:
| 1 2 3 4 5 6 7 | SELECT *FROM Sales.SalesOrderHeader ASsohJOIN Sales.SalesOrderDetail ASsod ONsod.SalesOrderID = soh.SalesOrderIDWHERE sod.OrderQty > 30ANDsod.ProductID = 867OPTION(QUERYTRACEON 9481); |
Bad news. The error message is the same.
Working within Azure SQL Database, trace flags are not a part of your tool set.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}