SQL Server的内存一直上不去。从Task Schedule中看到SQL Server只使用了88MB内存，实际这台机器有12GB的内存，可用内存有超过8GB。 当时我以为是开启了AWE导致的，所以连接到他的服务器看了一下。但是数据库为2005企业版位，所以不用开启AWE。而且即使开启

　　SQL Server的内存一直上不去。从Task Schedule中看到SQL Server只使用了88MB内存，实际这台机器有12GB的内存，可用内存有超过8GB。

　　当时我以为是开启了AWE导致的，所以连接到他的服务器看了一下。但是数据库为2005企业版位，所以不用开启AWE。而且即使开启了，也会被忽略。

　　使用下面的脚本查询了一下SQL Server内存使用：

　　select physical_memory_in_use_kb,locked_page_allocations_kb,*fromsys.dm_os_process_memory

　　看到实际使用的内存有2GB，远远超出任务管理器看到的。(也可以通过Perfmon的Total server memory(MB)查看)。

　　当时觉得很奇怪，查看了SQL Server错误日志发现了类似下面的信息：

　　2009-06-0412:21:08.16 Server Large Page Extensions enabled.

　　2009-06-04 12:21:08.16 Server Large Page Granularity: 2097152

　　2009-06-04 12:21:08.21 Server Large Page Allocated: 32MB

　　猜测这台期间开启了Lock Pages In memory功能，之后得到确认。因为开启Lock Pages In memory之后，SQL Server会使用AWE APIs锁定内存页，所以这部分的内存使用不会显示在Working Set中。

　　So in summary the AWE APIs for 32bit and bit SQL Server systems are used for different purposes. In 32bit it is really to extend memory access beyond 4Gb or to enable the AWE feature. For bit systems, it is to possibly gain performance and to “lock pages” for the buffer pool.

　　到现在这个问题就比较明朗了，其实SQL Server还是正常工作的。一般查询SQL Server的使用还是建议使用DMV或者Perfmon，直接查看Working Set信息可能不准。

　　另外说一下，当时看到上面Large Page的信息，，以为是数据库开启了LargePage，但是使用DBCC TRACSTATUS查看没有开启834 Trace Flag,所以大数据功能是没有启用的。只有开启834 Trace Flag数据库才会真正启用Large Page。

　　启用Large page在数据库错误日志会看到类似信息：

　　2009-06-0414:20:40.03 Server Using large pages for buffer pool.

　　关于Lock Pages In memory/working set机制我找到了两篇文章，大家有兴趣可以参考：

　　Funwith Locked Pages, AWE, Task Manager, and the Working Set

　　WhySQL Server is using so LESS memory