Query Hash Values, Plan Guides, and the Query Store
What happens to query hash values when it comes to plan guides and query stores? Is it is a special case? Read on for some surprising information.
Join the DZone community and get the full member experience.Join For Free
i was eating dinner with hugo kornelis and we started talking about query hash values. you know, like everyone does at dinner. as we talked about it, i suddenly thought about both plan guides and the query store. i wondered what happened to the query hash values in that case? thus, our blog post is born.
query hash and plan guides
the behavior of the query hash itself is fairly straight forward. the text of the query is run through a hashing algorithm within sql server and a value comes out, so these two queries:
select * from sales.salesorderdetail as sod join sales.salesorderheader as soh on sod.salesorderid = soh.salesorderid; select * from sales.salesorderdetail as sod join sales.salesorderheader as soh on sod.salesorderid = soh.salesorderid option (force order);
result in two different query hash values:
unhinted query hash 0x7264738ed060f3c1 hinted query hash 0xd763cbb6b860aff3
things get interesting if we create a plan guide for the first query to make it behave like the second query:
exec sys.sp_create_plan_guide @name = 'hashtest', -- sysname @stmt = n'select * from sales.salesorderdetail as sod join sales.salesorderheader as soh on sod.salesorderid = soh.salesorderid;', -- nvarchar(max) @type = n'sql', -- nvarchar(60) @module_or_batch = null, -- nvarchar(max) @params = null, -- nvarchar(max) @hints = n'option(force order)'; -- nvarchar(max)
if we rerun the query and then take a look at the first operator in the execution plan, we can see that the plan guide is in use… and that the query hash has changed. it no longer matches the original query. now, it matches the query that included the query hint. this actually makes perfect sense. the plan guide is basically changing the query from the first example above, into the second.
now, what happens when we toss in the query store?
query hash and query store
traditionally, in the query store, forcing a plan isn’t changing anything except the plan, so what you’ll see is the original query hash value. however, things get a little off when we start forcing plans on queries that have plan guides. i’ve blogged about this before, you’ll get the plan from query store, but you’ll get the properties showing that both the plan guide and plan forcing are both in use. let’s force the plan and see what happens.
exec sys.sp_query_store_force_plan 135,114;
are you sitting down?
what i expected would happen is that we would see the query hash value go back to the original value. however, look at this screen capture from the
operator of my execution plan:
i’ve highlighted three pieces of information. you can see that a plan guide was applied because there is a
property and value at the top. you can see that a plan was forced because we see the
property and value at the bottom. however, in the middle, you can see, that the query hash, for some strange reason, now matches the plan hash.
what’s going on?
i don’t know.
clearly, the behavior, at least in all the testing i’ve done and read about, is that plan forcing overrides plan guides. fine, but clearly there’s some housekeeping around the plan guides that is incomplete. part of that is right there in the query hash value. sql server can’t use the value from the plan guide text because it’s wrong, but it must not generate a new value. rather than leaving it blank (although, why not leave it blank), it copies the query plan hash value.
what’s this mean for production servers and your day-to-day existence? not much… unless you’re querying for the query hash value out of the dmvs while using plan guides and query store with plan forcing. in that case, you may have some issues tracking down everything you expect to see under normal circumstances.
Published at DZone with permission of Grant Fritchey, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.