When a stored procedure, prepared queries and queries submitted via sp_executesql is compiled for the first time, the values of the parameters supplied with the execution call are used for cardinality estimation, to optimize the statements within that stored procedure and create the query plan. This is known as parameter sniffing because the optimizer sniffs the current parameter value during compilation.
If these values are typical and the data distribution is even in the underlying tables, all the calls to the stored procedure will benefit from this query plan since the plan is reused. However, parameter sniffing can cause problems if the "sniffed" parameter value is not typical of the values which are actually used during a typical execution or the data in underlying tables are very skewed, because plan generated for “sniffed” parameter value may not be optimal for current parameter passed and since the plan is reused there can be performance degradation.
Consider the following scenario we have a table with two columns (country and some column ). This table has 10001 rows. 10000 rows has USA in country column and 1 row has brazil in country column.
This table has NONCLUSTERED INDEX called NC on country column.
create table data(country char(10),somecolumn char(10))
go
insert into data values (‘BRAZIL’,‘somedata’)
go
insert into data values (‘USA’,‘somedata’)
go 10000
CREATE NONCLUSTERED INDEX [NC] ON [dbo].[data]
(
[country] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
create proc sniffing @p1 char(10)
as
begin
select country,somecolumn from data where country=@p1
end
Go
–Let us execute stored procedure sniffing with the with parameter brazil.
exec sniffing ‘BRAZIL’
go
Optimizer picked up Index-seek in Non-clustered index and Row-ID lookup on table.
What happens when we execute the same procedure with parameter ‘USA’. Since the plan is already created and cached for ‘BRAZIL’ it is reused and plan which is generated for BRAZIL is Not an optimal plan for parameter USA.
exec sniffing ‘USA’
go
How to identify if the optimizer is using plan which compiled for sniffed parameter values and not the current parameters value.
Let us enable statistics xml on
set statistics xml on
exec sniffing ‘USA’
go
Look at the XML plan for the ParameterCompiledValue and ParameterRuntimeValue.
Below is extract from XML plan and this output proves that the plan is compiled for parameter BRAZIL (ParameterCompiledValue) and it is used for parameter USA (ParameterRuntimeValue)
{
<ColumnReferenceColumn="@p1"ParameterCompiledValue="‘BRAZIL ‘"ParameterRuntimeValue="‘USA ‘" />
}
We will also see a huge difference in estimated and actual rows count if the parameter sniffing is impacting the plan
(Remember out dated stats can also cause optimizer to estimate incorrect rows so difference in estimate and actual rows doesn’t mean it is because of parameter sniffing ).
What would have been the optimal plan if the parameter ‘USA’?
Let us execute the same procedure with recompile option
exec sniffing ‘USA’ with recompile
go
How to fix Parameter sniffing?
1. USE RECOMPILE: when you create the stored procedure. so the parameter is compiled every time it is called. This method can be used if the compile time is very less compared to execution time of bad plan
Ex: create proc sniffing @p1 char(10) with recompile
2. OPTION (RECOMPILE): for the statement which impacted by the parameter sniffing. If the procedure has multiple statements recompile will impact only the particular statement.
3. OPTIMIZE FOR HINT: Instructs the query optimizer to use a particular value for a local variable when the query is compiled and optimized (or) OPTIMIZE FOR UNKNOWN WHICH Instructs the query optimizer to use statistical data
instead of the initial values for all local variables when the query is compiled and optimized. This value is used only during query optimization and actual values are used during execution.
{
alter proc sniffing @p1 char(10) as
begin
select country,somecolumn from data where country=@p1
option (optimize for (@p1 = ‘USA’))
–option (optimize for (@p1 unknown))
end
}
4. Assign the incoming parameter values to local variables and use the local variables in the query. If you are in SQL Server2000 in which we don’t have OPTIMIZE FOR hint.
Ken Henderson has blogged about it in http://blogs.msdn.com/b/khen1234/archive/2005/06/02/424228.aspx
5. Trace Flag 4136 which is introduced in SQL Server 2008 R2 Cumulative Update 2, SQL Server 2008 SP1 Cumulative Update 7 and SQL Server 2005 SP3 Cumulative Update 9 introduce trace flag 4136 that can be used to disable the "parameter sniffing" process more details on http://support.microsoft.com/kb/980653
If you liked this post, do like us on Facebook at https://www.facebook.com/mssqlwiki and join our Facebook group https://www.facebook.com/mssqlwiki#!/groups/454762937884205/
Thank you,
Karthick P.K |My Facebook Page |My Site| Blog space| Twitter
MSSQLWIKI 