Let me summarize (and round!) the important data points in your spreadsheet:

      Total                                     Use Count 1      ---------------------------------------   -----------------------      Total Plans   Total MBs   Avg Use Count   Total Plans   Total MBs         -----------   ---------   -------------   -----------   ---------Adhoc      55,987       3,054               3        38,314       2,036Proc          709       1,502           1,549           135         527

So the first row shows the bad stuff, taking up about 2/3 of your plan cache (things which are mostly only ever used once, with a few very minor exceptions). You need to try and get rid of as much of these as you can. The second row shows the good stuff. These are the things you want in your plan cache (plans with a high amount of reuse). The rest of the data is largely irrelevant IMHO. One other point though: you say that access is exclusively through stored procedures, but if those procedures use dynamic SQL, those statements are cached asAdHoc plans, notProc plans.

On 2008 or greater, I would say turn onoptimize for ad hoc workloads and move on to the next problem - this would take the amount of MBs your single-use plans currently occupy down to next to nothing. Unfortunately, on 2005, your options are quite limited, aside from refactoring those stored procedures to use statement-levelOPTION (RECOMPILE) and/or less / no dynamic SQL, or turning onforced parameterization at the database level - which tries to get better plan reuse out of similar queries by treating literals as parameters for plan matching purposes. I hesitate to even mention plan guides because they're not for the timid and - as I discuss later on in this answer - I'm not sure it's worth going down that path unless you know your plan cache is definitely the source of your performance issue.

I asked about@@VERSION because, before SP2, the algorithm for the amount of memory that could be allocated to the plan cache was relatively loosey-goosey. As of SP2 they tightened that up quite a bit (the change is documented and explained inthis post andthis post). In your case, the plan cache is relatively full, so it is not surprising you're getting cache misses. 26 GB = an upper limit of 5.8 GB; I see ~4.5 GB in the spreadsheet but there may be some calculation or configuration difference here that I don't know about.

This MSDN article talks about theoptimize for ad hoc workloads server setting added in 2008, and mentions trace flag 8032, which will allow you to allocate more memory to your caches (presumably in the absence of setting this setting at the server level, which I now recommend to all of our customers, or at least the 99% that are no longer on 2005). I have never tested this trace flag on 2005 SP3 or SP4, and honestly not even sure when it was introduced. I also don't know if it will solve your problem or just shift it, since I think even if you had some % more RAM allocated to caches, you'd still be filling it and having lots of cache misses because of the nature of your stored procedures.

Or, of course, if there is even a problem to solve that relates directly to the plan cache at all. Just because your cache hit ratio isn't as high as you might expect does not mean that it is causing your problem, and of course the converse is that even at 100% cache hit ratio - which doesn't seem realistic given that so many of your plans are single-use and ad hoc - your users may still be suffering from performance problems caused by something else entirely.

My suggestion is to look for better smoking guns than plan cache hit ratio. Get more specifics about your users' performance complaints. Are all queries always slow? Certain queries? Certain times of day / week / business cycle? Are only reporting queries slow? Take a serious read throughthis admittedly dry and long document on SQL Server best practices - in particular, the section on waits and queues, which can help you formulate a logical approach to identifying, diagnosing and solving performance issues. Making some number on a dashboard look better - a number that you don't even know directly contributes to the problem - might be very satisfying, but if it doesn't solve your users' performance issues, then it hasn't really gotten you anywhere.

These may also be useful in reading up on compilation / recompilation and plan cache reuse. Some of these are focused on 2008 (particularly those about the ad hoc workloads setting), but much of the information is still useful for 2005 and/or to better understand the benefits of upgrading (hint, hint).

• http://technet.microsoft.com/en-us/library/ms181055(v=sql.90).aspx
• http://www.sqlperformance.com/2013/08/t-sql-queries/parameter-sniffing-embedding-and-the-recompile-options
• http://technet.microsoft.com/en-us/library/ee343986(v=sql.100).aspx
• http://www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/
• http://www.sqlskills.com/blogs/kimberly/plan-cache-adhoc-workloads-and-clearing-the-single-use-plan-cache-bloat/
• http://www.sqlskills.com/blogs/kimberly/clearing-the-cache-are-there-other-options/
• http://www.sqlskills.com/blogs/kimberly/exec-and-sp_executesql-how-are-they-different/
• http://www.sqlskills.com/blogs/kimberly/prepared-statements-and-caching/
• http://www.sommarskog.se/query-plan-mysteries.html
• http://www.sommarskog.se/dynamic_sql.html

• sql-server
• performance
• sql-server-2005