1. Parameter Sniffing, Sp_Recompile
Teshale Misganaw
And
Tim Weigel

2. Teshale Misganaw One of the DBA at PGI SQL Server = few years
A limited experience on DB2 and Oracle

3. The Problem Production Sites 27 servers
Customers make calls to Connect
Summo Logioc alert (One Server)
Proc is timing out
Proc is taking longer than millisecond

4. The Research Start looking for Expensive Procs (CPU Intensive)
sys.dm_exec_procedure_stats
Outer apply with
sys.dm_exec_query_plan
sys.dm_exec_sql_text
Found one PROC which was executed so many times
Major KeyLookup (execution plan)
Index Seek but query needs additional columns
Add cover index to satisfy the lookup
35 columns (not practical)

5. The Research The BAD PLAN usually comes right after Index Maintenance
We dropped the whole index maintenance job and recreated
Not working
Tim went further and studied the data distribution
Found two combination of data that triggers the BAD PLAN
Column1 = 123…
Coulmn2 = 567….
HAAAA

6. The Research We suspect Parameter Sniffing
Flush the Cache for a single PROC
DBCC FREEPROCCACHE(planhandle)
The next time the PROC runs it picks up good plan
Good Sign
After the next day maintenance plan,
BAD PLAN
At least we are getting somewhere

7. The Solution Problem Starts right after maintenance plan
We want to make sure it is covered all the time
Create a job that runs every 5 minuets that reads
sys.dm_exec_procedure_stats
max_elapsed_time
If max_elapsed_time > , start the job

8. The JOB declare @flush_bad_plan_out varchar(100)
if (select MAX(max_elapsed_time) from sys.dm_exec_procedure_stats where object_id = object_id('PROC_NAME')) >
= 'sp_recompile ''PROC_NAME'''