Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

OPTIMIZE FOR UNKNOWN (parameter sniffing problem) Expand / Collapse
Author
Message
Posted Friday, September 21, 2012 8:57 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, September 8, 2014 3:14 AM
Points: 513, Visits: 1,130
Hi,

I recently read this post http://sqlinthewild.co.za/index.php/2007/11/27/parameter-sniffing/ and not sure I got the "juice"...
If I have a SP with 4 parameters to be applied on a SELECT statement do I have to "tell" SQL Server to "ignore" the values with the "OPTION (OPTIMIZE FOR (@p1 UNKNOWN, @p2 UNKNOWN, ...))".
Is this the best way to optimize the query plan?

Thanks,
Pedro




If you need to work better, try working less...
Post #1362744
Posted Friday, September 21, 2012 9:02 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:25 PM
Points: 43,008, Visits: 36,164
PiMané (9/21/2012)
Is this the best way to optimize the query plan?


No. It's a specific solution to a specific problem.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1362755
Posted Friday, September 21, 2012 9:04 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, July 25, 2014 12:09 PM
Points: 437, Visits: 334
You can also use local variables for intermediaries. Assign your incoming parameters to local variables, then use the local variables in the predicates.

Roland Alexander
The Developing World


There are two means of refuge from the miseries of life: music and cats. ~ Albert Schweitzer
Post #1362758
Posted Friday, September 21, 2012 9:10 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, September 8, 2014 3:14 AM
Points: 513, Visits: 1,130
Roland Alexander STL (9/21/2012)
You can also use local variables for intermediaries. Assign your incoming parameters to local variables, then use the local variables in the predicates.


Yep, that one solution on the blog's post...
My main question is if it's necessary for ALL SPs...
Say you have an SP to list customers with 4 filters: @city, @sex, @maritalstatus and @anualincome
There's a select on the SP that takes all 4 parameters...
Do I have to tell SQL Server to OPTIMIZE FOR UNKOWN?
@city can have multiple values so can @anualincome, but @sex and @maritalstatus have few values.

Thanks,
Pedro




If you need to work better, try working less...
Post #1362767
Posted Friday, September 21, 2012 9:16 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:25 PM
Points: 43,008, Visits: 36,164
As I said, no. It is a specific solution to a specific problem.


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1362774
Posted Friday, September 21, 2012 9:19 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, July 25, 2014 12:09 PM
Points: 437, Visits: 334
That depends on any number of factors. Parameter sniffing only presents a problem if there are multiple possible execution plans, some of which may be suboptimal for the parameter value passed. Consider a customer table with a state field, clustered on customer account number, with a nonclustered index on state. Assume ten thousand rows in the table. Eight thousand (80%) are from Texas. So if we have a stored procedure that selects based on state, the optimal plan involves scanning the clustered index, since this will be much more efficient than trying to do a key lookup. BUT there are only two rows from Vermont, and the select would benefit greatly from a key lookup for this parameter value. If the first plan compiled for the SP involved TX as a parameter, we will wind up using the same plan (CI scan) for Vermont as well as Texas, and this is suboptimal (obviously) for Vermont. Forcing the issue by using local variables will result in the optimizer generating a new plan that makes use of index statistics to generate the optimal plan for the value.

Roland Alexander
The Developing World


There are two means of refuge from the miseries of life: music and cats. ~ Albert Schweitzer
Post #1362776
Posted Friday, September 21, 2012 9:31 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, September 8, 2014 3:14 AM
Points: 513, Visits: 1,130
So it depends mostly on the data in the tables.
Being a "generic" software spread across the country we can have databases with customers mainly from one state (where a cluster index scan would be better) and also databases witch customer from many different states (where a index seek would be better)..
But since the query plan will be recompiled the 1st time on each database it will probably be optimized for its case.
We can have a database where the plan says to use a index scan and another database with the same structure but different data with an index seek...
There's not much that can be done in these situations since our SW is all over the country (20.000 customers) and each case is specific...

Thanks,
Pedro




If you need to work better, try working less...
Post #1362787
Posted Friday, September 21, 2012 9:34 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Friday, July 25, 2014 12:09 PM
Points: 437, Visits: 334
PiMané (9/21/2012)
So it depends mostly on the data in the tables.
Being a "generic" software spread across the country we can have databases with customers mainly from one state (where a cluster index scan would be better) and also databases witch customer from many different states (where a index seek would be better)..
But since the query plan will be recompiled the 1st time on each database it will probably be optimized for its case.
We can have a database where the plan says to use a index scan and another database with the same structure but different data with an index seek...
There's not much that can be done in these situations since our SW is all over the country (20.000 customers) and each case is specific...

Thanks,
Pedro


Which is the point of using local variables, since it will force a new plan each time the query is run. Of course, this is also the downside of using local variables.


Roland Alexander
The Developing World


There are two means of refuge from the miseries of life: music and cats. ~ Albert Schweitzer
Post #1362792
Posted Friday, September 21, 2012 9:39 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Monday, September 8, 2014 3:14 AM
Points: 513, Visits: 1,130
Roland Alexander STL (9/21/2012)
Which is the point of using local variables, since it will force a new plan each time the query is run. Of course, this is also the downside of using local variables.


Excuse my ignorance... but why are local variables a bad thing inside SP? They force the calculation of a new query plan (which is like recompiling?!)?

Thanks,
Pedro




If you need to work better, try working less...
Post #1362796
Posted Friday, September 21, 2012 9:41 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:25 PM
Points: 43,008, Visits: 36,164
Roland Alexander STL (9/21/2012)
Which is the point of using local variables, since it will force a new plan each time the query is run.


Errr... really?



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1362797
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse