on March 28, 2018
The new Enterprise Automatic Tuning feature in SQL Server 2017 may sound intimidating at first – one question I get a lot lately is whether or not there’s a future for DBAs. Will Auto-Tune mean we don’t need any more human tuning?
Well, not anytime super soon.
I’m a big fan of the Automatic Plan Correction feature in SQL Server 2017, but it reminds me a bit of the missing index DMVs we got in SQL Server 2005: the suggestions are a fantastic indication of where you need to look and use your powerful human brain.
Automatic plan correction is temporary – and that’s a good thing
One of the things I love about this feature is that it wisely includes some caution.
If you’ve enabled automatic tuning and it finds what looks like a plan regression, it won’t just force a plan and forget about it.
Let’s say we have a query where the average CPU time with Plan A is 2 seconds, and the average CPU time for Plan B is 10 seconds. If Automatic Plan Correction kicks in, we go into a state where Plan A is being verified.
Trust, but verify
Is Plan A really always faster? It may be that after Plan A is being ever so gently forced (ok, that’s not gentle), the query is run with different parameters, that make Plan A skew horribly wrong, and our average CPU time goes to 12 seconds. SQL Server is looking for that.
Un-force when things change
Automatic Plan Correction is also pretty skittish when it comes to change.
Change indexes on the table? Whoops, we better un-force everything in case there’s something that could be faster! Update statistics on the table? Same thing!
And also…
Automatic Plan Corrections don’t persist over restarts
I did a little demo of this, just to prove it to myself.
I have an Automatic Plan Correction in verification state. Here’s a view of it in sys.dm_db_tuning_recommendations:
But then, I restart my SQL Server instance:
Once the instance comes back up, Automatic Plan correction is no longer in place.
Here’s a different view, after restart. Looking at Query Id 25 in the Queries with High Variation report, there are NO check boxes in those bubbles to the right. Nothing is being forced.
Everything is also gone from view in the sys.dm_db_tuning_recommendations. That data isn’t persisted after restarts.
The good news: we don’t completely start from scratch
My Query Store still has data about past performance of the plan.
After restart, if my query happens to compile with the “slow plan”, the fast plan can be identified from the history capture in Query Store before the restart.
In other words, Automatic Plan Correction doesn’t only consider information since the last restart when making its suggestions. I tested, and just by repeatedly running the “slow plan” for Query Id 25, a recommendation popped up. Since I have automatic tuning enabled for this database, it was automatically applied.
Think of Automatic Tuning as an assistant DBA
And it’s better than just a random assistant! It’s an assistant that can help point you in the direction of problems like bad parameter sniffing, which are really hard to track down.
If your environment is so sensitive that you don’t trust your assistant to just go tuning things, that’s fine! You don’t have to enable Automatic Tuning, and you can still look at the suggestions manually (as long as you’ve got Enterprise Edition).
But at this point, and for the foreseeable future, your assistant still needs you to dig into the code, indexes, and architecture to find a better long term solution than just freezing the plan. Because if just freezing the plan was enough, this feature would be a whole lot simpler.