SQL Server weird behavior; DBCC FLUSHPROCINDB temporarily resolves issues

Posted on 2009-04-07
Medium Priority
Last Modified: 2012-05-06
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?

Question by:thecoon
LVL 32

Accepted Solution

Brendt Hess earned 1000 total points
ID: 24093137
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

Author Comment

ID: 24101701
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?

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Introduction This article will provide a solution for an error that might occur installing a new SQL 2005 64-bit cluster. This article will assume that you are fully prepared to complete the installation and describes the error as it occurred durin…
This article explains how to reset the password of the sa account on a Microsoft SQL Server.  The steps in this article work in SQL 2005, 2008, 2008 R2, 2012, 2014 and 2016.
SQL Database Recovery Software repairs the MDF & NDF Files, corrupted due to hardware related issues or software related errors. Provides preview of recovered database objects and allows saving in either MSSQL, CSV, HTML or XLS format. Ensures recov…
Stellar Phoenix SQL Database Repair software easily fixes the suspect mode issue of SQL Server database. It is a simple process to bring the database from suspect mode to normal mode. Check out the video and fix the SQL database suspect mode problem.

619 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question