Forcing sql not to cache plans for procs

  • Team is experencing issues related to the performance as CPU usga e was quite high so in between they just flushed the cache and after that the performance issue got solved. In few procs there, dynamic sql is used. I have read one article called "Hit and Miss". I have asked for the trace to know if calls are missing the use of cache. There could be many issues which can contribuet to loss of performance. I read recently if co-related subquery are used where its calculating avg of some sales or something else, it can degrade the performance drastically. Once I get the trace I will try to check.

    Could you please suggest what steps at the moment, we can adopt to analyse where are the bottle necks related to performance? Is that possible from a trace to get a idea on the same or are there any settings which we should use while generating a trace so that we can analyse to know what is casuing the issue?

  • Yes, you want to analyze the trace. A standard trace, using the defaults, will capture the execution time, I/O and CPU costs. That's what you need to look at. It's just the beginning, but you need to start there.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

Viewing 2 posts - 16 through 16 (of 16 total)

You must be logged in to reply to this topic. Login to reply