以下是我們正在嘗試做的事情。當服務器上沒有足夠的內存時，200GB或更大的SQL Server數據庫能否加載到頁面文件中？
我們將有一個需要加載到內存中的200GB + SQL Server數據庫。 Microsoft的最佳做法是在服務器上有足夠的物理內存，然後將整個數據庫加載到該內存中。這意味着我們在每臺SQL Server上都需要256GB的內存。這會導致快速訪問加載到內存的數據庫，但會導致內存的高成本。順便說一句，我們正在Windows Server 2008上運行SQL Server 2008.
目前，我們的服務器僅安裝有12GB內存。只有3GB以下分配給操作系統，剩餘的9GB用於SQL Server。是否可以將頁面文件增加到256GB並將其設置在SSD驅動器上？然後我們要做的是將數據庫加載到位於SSD上的頁面文件中。我們希望性能將類似於將整個數據庫加載到內存中，因爲它將位於SSD上。
這項工作？我們可以忽略另一種選擇嗎？我們希望儘可能降低成本，同時不犧牲環境的性能。任何意見，將不勝感激。
謝謝。
如果要將數據庫存儲在內存中，則需要購買更多內存。儘管the other answer暗示，內存是絕對最好和最便宜的方式來使數據庫性能更好 - SQL Server 是旨在使用內存很好。
雖然SQL Server將在必要時利用頁面文件，並且SSD上的頁面文件比舊式機械磁盤上的頁面文件略快，但它仍然是I/O並進行交換，不管下面的磁盤類型如何，都會有很多開銷。一般來說，這可能比在旋轉磁盤上具有相同的頁面文件（或者根本沒有頁面文件）要好一些，但我認爲它不會受到影響的任何地方真正的記憶，或者它將會接近您對「快速訪問」的期望。
如果你不能買到更多的內存，那麼你可以用SSD上這個頁面文件開始，但我相信你將需要額外關注其他調整的機會 - 在很大程度上確保您有支持的類型索引您運行的查詢，儘可能避免全表掃描。對於全表聚合，您可以考慮索引視圖（請參閱here和here）;對於子集，您可以考慮filtered indexes。
而且可以肯定的是：您將實際數據存儲在SSD驅動器上，對不對？如果沒有，那麼我會爭辯說，你應該使用SSD的數據和/或日誌，而不是頁面文件。如果頁面文件不斷地通過交換磁盤來交換數據，頁面文件不會給你帶來太多好處。
需要更多的關於這個問題的澄清。
您是否在控制數據庫或者這是一個COTS解決方案，它限制了您的優化能力？
您是否正在羣集？這就是爲什麼添加200 + Gb的RAM是一個問題（現在超過400GB，每個節點200個）？
您是裸機還是虛擬化？這是爲什麼RAM可能是一個問題？
到目前爲止，似乎「專家」做出了一些假設，可能對您的情況不公平。
請更新您的問題...... :)
你爲什麼把這個作爲答案？把它們放在評論框 – DevelopmentIsMyPassion
是的，這是一個限制我們能力的COTS解決方案。服務器都是虛擬的，這就是爲什麼RAM是一個問題。我被告知，支持微軟最佳實踐的成本將爲60,000美元，因此我們正在尋找一種更便宜的選擇。 顯然這是FIM的工作方式，或者我被告知。它將整個數據庫放入內存以優化性能。我們需要更便宜的替代方案，因爲我們預計數據庫將增長到200GB以上。 – WeirdG
這裏「物理記憶」是什麼意思？你的意思是說微軟建議在內存條上有足夠的內存來保存整個數據庫？ – vgoff
@vgoff理想的情況是，爲什麼不呢？顯然，你希望數據保存到磁盤上，但是當它可以放在內存中時，這意味着你的所有查詢都可以從內存中訪問數據，這比任何你可以拋出的磁盤都快幾倍。 –
感謝您澄清OP的聲明。我不能確切地確定他們是否在談論物理內存，如在盤片上（因爲他們詢問pagefile）或易失性內存。您甚至可以在易失性RAM中寫入頁面文件。理想和最佳實踐往往是兩回事。 – vgoff