為什麼SQL Server使用很少的內存

　　SQL Server的內存一直上不去。從Task Schedule中看到SQL Server只使用了88MB內存，實際這台機器有12GB的內存，可用內存有超過8GB。

　　當時我以為是開啟了AWE導致的，所以連接到他的服務器看了一下。但是數據庫為2005企業版64位，所以不用開啟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 64bit 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 64bit 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