本文爲本系列最後一章，監控內存使用。監控服務器的內存是非常重要的事情，有很多情況會引起內存消耗。所以要經常性地做檢查。
本文將使用可靠性和性能監視器來獲取內存相關的統計。
準備工作：
在開始之前，先來了解一下將要用到的計數器：
Ø Memory: Available Mbytes:提供系統上可用內存的數量。
Ø Memory: Pages/sec:顯示有多少頁被用於讀或寫入硬盤，這些基於硬頁面錯誤。
Ø Paging File:%Usage:顯示掛起的總數的百分比。
Ø SQL Server: Buffer Manager: Buffer cache hit ratio:返回SQLServer從緩存但不是從硬盤返回的數據的百分比。
Ø SQL Server: Buffer Manager: Page life expectancy:顯示數據駐留在內存的平均秒數
Ø SQL Server: Buffer Manager: Memory Grants Pending:等待內存工作區授予的進程數。
步驟：
1、 打開可靠性和性能監視器，在【運行】中輸入perfmon.exe
2、 選擇性能監視器。
3、 去除所有已存在的計數器。
4、 添加新計數器。
5、 選擇所要監視的服務器。
6、 選擇下面的計數器：
Memory: Available Mbytes
Memory: Pages/sec
Paging File:%Usage
SQL Server: Buffer Manager: Buffer cache hit
SQL Server: Buffer Manager: Page life expectancy
SQL Server: Memory Manager: Memory Grants Pending
7、 然後點擊確定。
上面這些步驟已經在前一章說明了。這裏就不累贅了。
分析：
在本文中，再次使用了可靠性和性能監視器這個工具。爲了獲取內存相關的性能計數器，需要在圖形化界面中觀察這些計數器。
首先先檢查Memory: Available Mbytes，這個值意味着系統的可用內存。如果發現這個值經常很低，可能表示服務器內存不足，在生產數據庫中，這個值可以使用GB爲單位。
然後檢查Memory: Pages/sec ，以爲這因爲硬頁面錯誤導致的從磁盤讀或寫頁面。這個值如果長期高於20，意味着內存不足使得應用程序使用虛擬內存，從而導致掛起。
接着是Memory: pages/sec ，同時也要檢查Paging File:%Usage去預估內存掛起。如果這個值經常超過20%，可能意味着內存不足。
SQL Server: Buffer Manager: Buffer cache hit ratio:意味着數據從緩存中讀取的次數，比較合理的值爲大於90%。如果該值很低，可能內存不足或者需要檢查索引和查詢。如果你需要獲得大量數據，這一步可能就會佔用大量內存然後引起SQLServer從磁盤讀數據而不是從內存。檢查索引，確保在大表中能儘可能筆描掃描。並儘可能限制查詢返回的結果行。
檢查SQL Server: Buffer Manager: Page life expectancy，表示數據頁駐留在內存的秒數。微軟建議最少300秒。如果在一個實例中經常低於300秒，意味着數據保留的時間少於5分鐘就被移出內存。
如果SQL Server: Memory Manager: Memory Grants Pending經常建議等待進程，你可能需要增加服務器的內存了。
不管什麼原因，如果你發現內存不足和掛起發生得比較頻繁，你首先應該檢查是否有非SQL Server的其他應用或者服務耗費了比SQL Server更加多的內存。如果你發現這些應用或者服務，嘗試移到別的服務器。如果做不到，那麼需要增加更多的內存，以供SQLServer使用。
如果服務器僅僅工SQL Server使用且沒有上面說的情況，那麼要分析你的查詢和索引，以確保他們是最優化的。如果已經優化好，還是存在這些問題，那麼才需要考慮增加內存。
除了可靠性和性能監視器，還可以使用SQL Server Profiler來監控性能，創建一個用戶自定義收集器並存爲文件，當你從性能監視器中獲取性能數據時，SQL Server Profiler會同步運行。一旦你完成收集，可以把性能數據導入到SQLServer Profiler中供任何時候分析。
