The data in the Query Data Store is what makes all the magic happen. From collecting the aggregate performance metrics of a query to the various plans in use by that query to being able to force a plan, it’s all controlled by the data within the Query Data Store system tables.
When I was presenting on this topic at the PASS Summit a few weeks ago, one great question came up (great question = answer is “I don’t know”), well, I defaulted to an “I don’t know” answer, but my guess was, “No.” The question was: can you take a plan from one server, let’s say a test server, export it in some way, and then import it to production? In this manner, you ensure that a plan you like gets into production without having to clear the plan from cache & generate a plan by running the query.
However, I knew that the Query Data Store information is all stored in system tables. You can’t directly modify system tables in SQL Server (well, not any more. In old versions prior to 2005, you could. Ah the joy of REALLY screwing up a database). However, I tested it. You won’t be shocked to find out, nope. you can’t.
So What Can You Do?
You have a number of data manipulation options. Since you can query the data store, obviously, you can export that data and store it elsewhere. When you backup a database, the Query Data Store data gets backed up. You can also directly manipulate the data using the procedures listed here to flush the store, remove a particular query or plan, or reset the performance statistics.
That’s about it. In it’s current incarnation, there’s not much in the way of direct manipulation of the data in the query store. It’s just like any other system table in that way.
I’d love to see them add the ability to upload, or import, an execution plan. Imagine the scenario where you have sharded your database across multiple servers, or, if you’re in Azure SQL Database, multiple databases. You identify a particular execution plan that’s going to work well for all these instances. Wouldn’t it be great to be able to import that plan and force all the various servers to use it, all programmatically? Heck yes.
However, we’re not there today.
I love talking performance tuning. In fact, I’ll be doing an all day seminar on execution plans and query tuning before SQLSaturday Providence in Rhode Island, December 2016, therefore, if you’re interested, sign up here.