This article is half-done without your Comment! *** Please share your thoughts via Comment ***
In this post, I am sharing about the Parameter Sniffing of SQL Server. I will discuss, why the query optimizer sometimes fails to choose a proper query plan.
One day I experienced that one of my production stored procedure was not returning expected performance, and before two days, same stored procedure was running fine.
At that time, I didn’t know about the Parameter Sniffing and started to look into this problem.
I found that before two days there were total 25000 records and later there were total 10,00,00 records.
I concluded that records increased quickly, but not increased ten times, and it increased just three times, and even I had already tested this stored procedure for 10,00,00,00 records.
Now time to know about the Parameter Sniffing:
Many times query optimizer chooses old query plan for execution because it stores this plan into the cache for frequently running queries.
Now, what happened when old query generated table scan for the first set of records and later the same parameter is required to change for index scanning because records increased.
I check the query execution plan and found that in my situation query optimizer use old query plan instead of to create a new query plan.
The query optimizer was using an old query plan from the query cache.
Now, this is known as a Parameter Sniffing issue.
For you guys, this is very important to know why this is happening.
The Query optimizer does not always choose the old query plan, but many times due to traffic or load, query optimizer chooses a plan from the query cache.
As a DBA, you should monitor all indexes and its usages to identify this kind of problem.
SQL Server Solution for Parameter Sniffing :
Three options for this solution:
- OPTION 1: RECOMPILING
- OPTION 2: OPTIMIZE FOR VALUE
- OPTION 3: OPTIMIZE FOR UNKNOWN
OPTION 1 : RECOMPILING
RECOMPILING, means forcing SQL Server to recompile stored procedure or statement at every execution. You can set recompile hint on stored procedure or statement.
Sample code for Stored procedure and statements.
|
1 2 3 4 5 6 7 8 |
/*Stored Procedure with Recomplie option*/ CREATE PROCEDURE dbo.usp_gettestdata @testid INT WITH RECOMPILE AS /*Select statement with Recomplie option*/ SELECT * FROM dbo.tbl_testdata OPTION (RECOMPILE); |
OPTION 2 : OPTIMIZE FOR VALUE
As a DBA, you can find a particular set of values which require executing under the best execution plan so you can set OPTIMIZE for a hint for this value. But values and data rapidly change in the database system so this only for those values or data which are not changing frequently.
Sample statement with OPTIMIZE for Hint:
|
1 2 3 4 5 6 7 |
CREATE PROCEDURE dbo.usp_EmployeeData @EmpID INT AS SELECT EmployeName, EmployeeDOB, EmployeeClass FROM dbo.tbl_EmployeeDetails WHERE EmpID= @EmpID OPTION (OPTIMIZE FOR (@EmpID=26)); |
OPTION 3 : OPTIMIZE FOR VALUE
Basically, you can set UNKNOWN hint for the query optimizer to create a generic execution plan base on statistical data. This may be again generated parameter sniffing issue, but still, you can use this for infrequently running queries.
|
1 2 3 4 5 6 7 |
CREATE PROCEDURE dbo.usp_EmployeeData @EmpID INT AS SELECT EmployeName, EmployeeDOB, EmployeeClass FROM dbo.tbl_EmployeeDetails WHERE EmpID= @EmpID OPTION (OPTIMIZE FOR UNKNOWN); |
