Index Hints : query using dropped index should fail gracefully - by AaronBertrand

Status : 


Sign in
to vote
ID 345058 Comments
Status Active Workarounds
Type Suggestion Repros 1
Opened 5/20/2008 5:47:42 AM
Access Restriction Public


If I create an index, and then use a hint in a query to use that index, the query fails with:

Msg 308, Level 16, State 1, Line 1
Index 'abc' on table '' (specified in the FROM clause) does not exist.

With tools like DTA, the dropping of indexes is going to become much more common, but common sense of inspecting code for index hints is not necessarily going to get any better, until people get bitten... and even then they will probably react by only fixing the one query.

[Filed on behalf of Greg Linwood.]
Sign in to post a comment.
Posted by Dragba on 5/20/2008 at 4:54 PM
This is a major issue for ISVs that have third-parties customizing their software. Even if the core application doesn't use index hints, some customized code may. Dropping indexes becomes unmanageable risk. Unfortunately we cannot use aliases to solve this problem (at least in 2005). That would be another solution if we could create the alias for existing index that will have the same name as the index that has been dropped. Or SQL Server can simply ignore the hint which is even better.
Posted by Microsoft on 5/20/2008 at 4:32 PM
I agree with the sentiment of this DCR. Failing queries when an INDEX hint can't be creates excessive dependence between the physical structure of the data and the application code. But we must find a way to provide a warning to users, e.g. through the SQL error log or a DMV or showplan, if the index hint is not honored. We'll consider this for the next release.

Note that you get the kind of behavior I described if you use USE PLAN in a plan guide. That is a possible workaround for now.

Thanks! -Eric
Posted by Michael J. Swart on 5/20/2008 at 10:09 AM
Having SQL Server behave in predictable ways is important. Improvements like this one sort of bring the db engine into a fuzzier area of behaviour. Maybe good in this case, but a slippery slope.

Consider this situation. A dba sees a query with terrible performance that is holding locks on resources everywhere. The dba fixes the query with a query hint and the index suddenly gets dropped. What's worse? An error on the query? Or a poorly performing query (with a warning) that is once again locking resources everywhere.