Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 876
  • Last Modified:

SQL Server weird behavior; DBCC FLUSHPROCINDB temporarily resolves issues

Experts, I have an interesting problem that has no easy solution.  Furthermore I do not know the exact problem, just the symptoms and what has temporarily resolved it:

Approximately every 2-3 hours our database will run excessively slow.
-every call to the database is through stored procedures.
-web service calls (hitting the DB) that usually take 1-2 seconds now time out (180 seconds)
-windows services that poll the DB now time out

When we run the command 'DBCC FLUSHPROCINDB...' to clear the execution plans the database immediately speeds up and we experience no more time outs.  However, 2-3 hours later the database slows again and the time outs occur.

My question to you experts, is what steps do I take to find the specific problem? Running 'DBCC FLUSHPROCINDB(...)' every 2-3 hours is not acceptable as it is not resolving the problem.  How can I further diagnose and pinpoint the culprit?  Could one bad stored procedure execution plan slow down an entire database?  Anyone experience something similar with regards to 'DBCC FLUSHPROCINDB(...)' temporarily "fixing" the database?


0
thecoon
Asked:
thecoon
1 Solution
 
Brendt HessSenior DBACommented:
The problem is almost certainly in the way the applications work with queries, or stored procedures with RECOMPILE flags for each call.  What is happening is a side effect of the fact that SQL Server just continues to grow the procedure cache .... and grow, and grow, and grow, until you run out of available memory, at which point... it continues to grow, leading to disk swapping of memory that just slows your system to a crawl.

Your quick workaround is to run the DBCC command on a schedule, every 90 minutes say, to keep things running.  Your long term goal is to revise code to make more reuse of the same plans
0
 
thecoonAuthor Commented:
bhess1, all of the queries through applications are done via stored procedures without RECOMPILE flags.  The only thing I can think of that might make the procedure cache grow is we use dynamic SQL in several stored procedures that are called infrequently (procedure is called ~3,000 times in a day, but we have stored procedures that are called 180,000 times a day).

Do you have any good articles on procedure cache, for what you are talking about, that could help me?
0

Featured Post

Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now