五餅二魚工作室

整個八月份異常忙碌，這當中剛好遇到兩次類似的狀況，提出來跟大家分享一下。

 

很多人在找關於 SQL Server 的記憶體設定時，我想很多人都有看過 Cary 所寫的 "SQL Server 記憶體使用量說明" 和 "SQL Server - x86與x64的架構下 - 最佳記憶體設定"，相信有看過這兩篇資料的朋友，藉由 Cary 的描述之後都會很清楚知道關於記憶體的相關設定。

 

而我最近所遇到的狀況，都是採用 Windows 2008 64 位元 OS , 搭配 SQL Server 2005 32 位元版本，他們原本的實體環境各是 8GB 和 16GB 的記憶體，但都是沒有開啟 AWE 的模式，因此只能使用到 3.7GB 的記憶體。而在跟這兩個公司的相關人員分別討論之後，都建議他們開啟 AWE，讓 SQL Server 可以使用到更多的記憶體，也藉著 SQL Server 能使用到更多的記憶體時，可以讓查詢的效能有了一些提升。

 

而在最近原本配置實體記憶體有 8GB 給 SQL Server 的公司，因為公司資料庫的成長非常快速，因此開始規劃把這些主機給做一些升級，其中最大的改變就是從原本的 16 GB 升級到 30 GB，升級後起初用起來還蠻順的，但過了一陣子之後，SQL Server 會不定時當初 "Failed Allocate pages: FAIL_PAGE_ALLOCATION 1" 的錯誤訊息，伴隨而來的就是會有將近 5~20 分鐘會無法連接 SQL Server，但過了這個時間之後有時又可以正常執行了。

 

原本在追查有這樣的問題的時候，我比較把方向朝向是否有指定使用過多的記憶體，或者是有許多大 Table 在做 Table Scan，而導致 Buffer Cache 的不足，因此有一段時間利用 Performance Dashboard 和 SQL Trace 的幫助，調整了部分的 SQL 指令，並且規劃一些 Index 來做改善，甚至也調整了 tempdb 的 File 數目，讓 SQL Server 可以執行的更順暢。雖然這些調整對於廠商在使用相關系統的時候，都有明顯感受到效能的提升，但 SQL Server 不定時會有錯誤的狀況還是沒有解決，只能限制 SQL Server 的最大記憶體使用量不能超過 12GB，來降低問題發生的頻率，因為一旦超過這個設定值，設定的越高出問題的頻率也就越加頻繁。

 

而在追查這個問題的同時，原本使用 8GB 的廠商，也規劃將資料庫主機升級到 32GB，也真的那麼湊巧也是遇到同樣的問題，因此我覺得問題可能是出在記憶體設定上面所導致的。在這期間我查了不少相關的資料，也參考網路上的建議做了一些調整，但都沒有甚麼效果。這樣的問題困擾我許久，後來在 FB 上面的 Super SQL Server 的討論中，幾位前輩們也都建議將 SQL Server 升級為 64 位元來試試看，因此這兩個廠商再分別跟他們討論和確認所擁有的 SQL Server License 授權之後，一個升級成為 SQL Server 2005 64 位元版本，一個升級成為 64 位元版本的 SQL Server 2008 R2。而在升級之後，因為程式本身就是採用 64 位元定址，因此就不必在使用 AWE 的方式使用超過 4GB 的記憶體，而最重要的，原本會出現的記憶體異常的錯誤，也都不在發生了。

 

因此如果有遇到類似狀況的朋友們，可以試試看如果關閉 AWE 的話就沒有問題，但開啟之後就會有類似的狀況的話，那麼很有可能您遇到的會是跟我同樣的案例，那麼我想您應該也是需要升級到 64 位元的 SQL Server 了。