You say you enabled AWE on SQL Server but did you activate /PAE in the boot.ini file?
PAE enables Large Memory support.
Activate PAE in Windows 32Bit Enterprise
c:\boot.ini
[boot loader]
timeout=30
default=multi(0)disk(2)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /PAE
http://support.microsoft.com/kb/283037
Lock Pages in Memory
As part of enabling AWE, you would also need to give the SQL Server Service user the right to Lock Pages in Memory. Enabling this option in the Group Policy dialog (gpedit.msc), prevents Windows from paging memory out of the SQL Server working set for its own needs, especially if memory starts to run low on Windows.
http://msdn.microsoft.com/en-us/library/ms190730.aspx
Monitoring AWE Memory Usage
To test AWE usage, I setup a Windows 2003 Enterprise SP2 with PAE enabled in boot.ini. I used SQL Server 2005 32bit Standard SP4.
The total physical memory is 8192Mb. The max memory setting for SQL Server is configured at 8192 and the minimum is at 2048.
Does SQL Server see AWE on startup.
2012-02-09 07:27:51.35 Server Address Windowing Extensions is
enabled. This is an informational message only; no user action is
required.
Is SQL Server using Locked Pages for the Buffer Pool
According to some blogs, I should be seeing this message, but I'm not.
Using locked pages for buffer pool.
This is an informational message only; no user action is required.
Memory being allocated through AWE
SELECT SUM(awe_allocated_kb) / 1024 AS awe_allocated_mb
FROM sys.dm_os_memory_clerks ;
[3648]
Memory allocated to Multi-Page memory.
select sum(multi_pages_kb)/1024 as [MultiPage Memory, MB] from sys.dm_os_memory_clerks
[14]
Multi-page memory can not use AWE allocated memory
Memory being used outside the buffer pool
SELECT sum(multi_pages_kb
+ virtual_memory_committed_kb + shared_memory_committed_kb) AS
[Memory used outside BPool, mb]
FROM sys.dm_os_memory_clerks
WHERE type <> 'MEMORYCLERK_SQLBUFFERPOOL'
[24]
Overall memory allocation by component
SELECT type, (single_pages_kb)/1024 as Single_Pages_MB, (multi_pages_kb)/1024
AS Multi_Pages_MB, (awe_allocated_kb)/1024 as AWE_allocated_MB
FROM sys.dm_os_memory_clerks
GROUP BY type
ORDER BY 2 DESC
This will show you how single-page and multi-page memory is being used by each component. It will also tell you which one is able to benefit from AWE.
Mutli-page : when request exceeds 8Kb
Single-page : when request is less than or equal to 8Kb
As a side note, I have found sp_whoisactive very helpful in finding slow queries, memory hogs and just about everything that's going on in SQL Server. Here is a link that Brent Ozar provides on how to set it up and use it.
http://www.brentozar.com/archive/tag/sp_whoisactive/
If you look closely at SpBlitz memory recommendations it says it has two possible meanings
Memory Dangerously Low or Max Memory Too High
In your case looking at perfmon counters output you have shared their does not seems to be a memory pressure. So we are left with the fact that max server memory is configured incorrectly
. And this seems true, on a system having 32 G memory you have given 30 G to SQL Server this would definitely leave OS fighting for more memory.
In this case OS will start paging out SQL Server processes to disk making it very slow. Or if Locked pages in memory is there for SQL Server service account OS process would be paged to disk. Both these conditions are very bad for SQL Server and OS.
I suggest you take help from This SE thread to calculate appropriate value for max server memory. I have given answer on this thread which asks user to take help of perfmon counters
to reach to a sensible value.
You can start by giving 27 G to SQL Server
and leaving 5G for OS
. Then use perfmon counters mentioned in SE thread to reach to sensible value.
EDIT: I forgot to ask you to apply SQL Server 2008 R2 SP3, currently SQL Server is on SP2. This is must if you need extended support. In any case, to be on safer side you should always make sure SQL Server is patched to latest service pack.
Best Answer
Memory allocated to SQL Server is 120 G and backup running is for 1.2TB + database and in such scenario of course a high page write would be done. IF this message is only coming when backup is running you might ignore it. In your exact previous thread, I asked you to ignore it as well.
I also asked you to collect perfmon counter values using performance data collector set and this is much needed because to answer your question whether the alert actually should be considered or can be ignored depends on that. You have to have performance/system benchmark to which you can compare other results.
NOTE: Seeing the database size I can say with confidence that adding more RAM would always help. Ideally if you take my advise RAM allocated to SQL Server should be 1/3rd of total database size. RAM's are cheaper those days instead of wasting too much effort in solving an alert I suggest you to go ahead and add more RAM, that would really be worth.
If you want me to analyze the data collector result personally my website has my mail id send me the details I can help you with the analysis.