Sample Header Ad - 728x90

Parameter Sniffing - Hints and fixes

5 votes
1 answer
3557 views
I recently dealt with a problematic stored proc. At times, runs beautifully fast, other times, runs very very long. I determined that *bad* parameter sniffing was the cause. Just for info - The parameters in the proc are datetime and the query uses these parameters to search through date ranges. Anyway, this is what I attempted: 1. Recreated the proc and used WITH RECOMPILE - Didn't help 2. Recreated the proc and added OPTION (RECOMPILE) - Didn't help 3. Recreated the proc and added OPTION (OPTIMIZE FOR UNKNOWN) - Runs fast 4. Recreated the proc and used local variables - Runs fast To help my understanding.... Is using local variables & OPTIMIZE FOR UNKNOWN the exact same thing in the way that is uses average density statistical data to produce a plan? I tried a couple of combinations of things as well: 5. Recreated the proc and added OPTIMIZE FOR UNKNOWN **&** OPTION (RECOMPILE) - Runs fast 6. Recreated the proc with local variables **&** OPTION (RECOMPILE) - Runs slow I have read about the potential dangers of using OPTIMIZE FOR UNKNOWN and in a lot of cases, using local variables are brought up as if it's the same thing. This is what leads me to think that it is the same thing. BUT - How do I explain that attempt 6 runs slow. I want to say that yes, stats are updated but it's with a less than zero % sampling rate - Tables are HUGE +- 1.6 billion rows. Might also be worth noting - I used the awesome sp_blitzcache and filtered on the specific proc - There is a compilation timeout warning for it - My intuition is telling me that is something to note here.
Asked by Sicilian-Najdorf (381 rep)
Dec 13, 2022, 09:03 AM
Last activity: Dec 14, 2022, 01:27 PM