Can I prove my database does not have memory issues?

Question

(This is a continuation of Do indexes consume memory?)

A fellow database developer believes we are having memory issues. He has seen increased run times in some standard queries - going from under 10 seconds to about two and a half minutes. He looked at Task Manager on the server and found high memory usage and now wants to take some of the memory currently allocated to the OS and free it up for SQL Server.

We are on SQL Server 2008, a 64-bit machine, AWE is not enabled, minimum 4096 MB, max 10240 MB.

I found Brent Ozar's A Sysadmin’s Guide to Microsoft SQL Server Memory which indicates Task Manager is not reliable. I have also found that our Page Life Expectancy is not indicating memory pressure. (Checked via Pinal Dave's query.)

Where else should I look? What else should I check? I'd like to report back to the database developer to either confirm his suspicions or prove them incorrect.

EDIT: modified my actual question. I appreciate, and agree, that these queries are overwhelming more likely slower for reasons other than memory problems. I am in a situation, however, that I need to prove memory is not the culprit across the board. That is, proving that a handful of queries are slower for other reasons won't accomplish my task. I'd like to understand where I can get such information and what metrics I should check.

Answer 1

The only way to prove is not a memory issue is by prooving is something else. And this requires you to identify the root cause of your performance problems. I recommend you follow a methodology like Waits and Queues. The SQLCAT team has also published a Troubleshooting Flowchart poster that you can follow.

As a general side comment: if someone is offering you to buy more memory on the server, just say YES, and then go ahead and do the root cause analysis. It doesn't matter that if the root cause of the problems are table scans, SQL Server can always use more memory.

Answer 2

To address your developers concern only (i.e. demonstrate memory isn't the problem), you could start by proving that the query isn't waiting on memory grants and that page life expectancy is at a comfortable figure.

Memory grants (from Glen Berry):

-- Shows the memory required by both running (non-null grant_time) 
-- and waiting queries (null grant_time)
-- SQL Server 2008 version
SELECT DB_NAME(st.dbid) AS [DatabaseName], mg.requested_memory_kb, mg.ideal_memory_kb,
mg.request_time, mg.grant_time, mg.query_cost, mg.dop, st.[text]
FROM sys.dm_exec_query_memory_grants AS mg
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
ORDER BY mg.requested_memory_kb DESC;

Page Life Expectancy:

SELECT [object_name],
[counter_name],
[cntr_value]
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE '%Manager%'
AND [counter_name] = 'Page life expectancy'

From there, I'd follow the advice in the comments and identify what the actual problem is, rather than focusing on what the problem is not.

• Waits & Queues
• sp_whoisactive
• Post the execution plans on your question.