SSRS Report is taking forever – OPTION (OPTIMIZE FOR UNKNOWN) hint – Parameter sniffing

Today one of the SSRS reports kept on loading.
On analyzing the stored procedure associated with it, we decided to use OPTION (OPTIMIZE FOR UNKNOWN) hint.
This stored procedure was creating 5 temp tables. We checked and found out that all these 5 temp table creation was instantaneous.
It was using the 5 temp tables and 8 other tables and performing the query, which was taking forever.
So we added the OPTION (OPTIMIZE FOR UNKNOWN) hint in this query and Viola! the query took less than 1 second.

So what is this parameter sniffing?

The Brent OzarTurgay Sahtiyan and Gregory Larsen have explained nicely what is parameter sniffing.

SQL Server compiles the stored procedures using (sniffing) the parameters send the first time the procedure is compiled and put it in plan cache ( or procedure cache). After that every time the procedure executed again, SQL Server retrieves the execution plan from the cache and uses it, regardless different parameters are passed.

The potential problem with this approach is the parameters that were used when the plan was cached might not produce an optimal plan for all execution of the SP, especially those that have significantly different set of records returned depending on the parameters passed. For instance, if you passed parameters that required a large number of records to be read, the plan might decide a table or index scan would be the most efficient method to process the SP. Then if the same SP was called with a different set of parameters that would only return a specific record, it would used the cached execution plan and perform an table or index scan operation to resolve it’s query, even if a index seek operation would be more efficient in returning the results for the second execution of the SP.

Read here to know more about scans vs seeks.


Reference 1

Reference 2

MSDN Execution Plan Caching and Reuse –  SQL Server has a pool of memory that is used to store both execution plans and data buffers. The percentage of the pool allocated to either execution plans or data buffers fluctuates dynamically, depending on the state of the system. The part of the memory pool that is used to store execution plans is referred to as the procedure cache.

SQL Server execution plans have the following main components:

  • Query PlanThe bulk of the execution plan is a re-entrant, read-only data structure used by any number of users. This is referred to as the query plan. No user context is stored in the query plan. There are never more than one or two copies of the query plan in memory: one copy for all serial executions and another for all parallel executions. The parallel copy covers all parallel executions, regardless of their degree of parallelism.


  • Execution ContextEach user that is currently executing the query has a data structure that holds the data specific to their execution, such as parameter values. This data structure is referred to as the execution context. The execution context data structures are reused. If a user executes a query and one of the structures is not being used, it is reinitialized with the context for the new user.



One thought on “SSRS Report is taking forever – OPTION (OPTIMIZE FOR UNKNOWN) hint – Parameter sniffing

  1. Pingback: SQL Server Query optimizer – Scan Vs Seek | Vikas D More

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s