I have the following issue: when a stored proc is called from my application, every now and then (like 1 time out of 1000 calls), it takes 10-30 seconds to finish. Typically, the sproc runs in under a second. It's a fairly simply proc with a single select that ties together a couple of tables. All the table names are set with a (NOLOCK) hint, so it probably isn't locking. The indexes are all in place too, otherwise it would be slow all the time.
The problem is that I can't replicate this issue in SSMS (as it always runs subsecond) no matter how many times it runs the sproc, yet I see the problem when I point the profiler to the user who's running my app. The query plan in SSMS seems correct, yet the problem persists.
Where do I go from here? How do I debug this issue?
Some options:
What does profiler or SET STATISTICS xx ON
say? Is there simply resource starvation, say CPU
The engine decides statistics are out of date. Are the tables changing by 10% row count change (rule of thumb). To test:
SELECT
name AS stats_name,
STATS_DATE(object_id, stats_id) AS statistics_update_date
FROM
sys.stats
WHERE
object_id IN (OBJECT_ID('relevanttable1'), OBJECT_ID('relevanttable2'))
What else is happening on the server? example: Index rebuild: not blocking, just resource intensive.
Usually I'd suggest parameter sniffing but you say the parameters are the same for every call. I'd also expect it to happen more often.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With