sql server 2008 r2 的一般記憶體要求
我對 DBA 工作沒有經驗，但我正在嘗試為我們的 sql 伺服器請求額外的資源，並希望我可以讓一些聰明的人對我們應該執行的內容提供一個粗略的估計。我懷疑 IT 為我們的生產 sql 伺服器分配的資源很低。
硬體軟體：
數據庫：sql server 2008 r2 企業數據庫
Windows：Windows 2008 r2 Enterprise 64 位，可以肯定在 VMware 上執行。
處理器：Intel(R) Xeon(R) CPU E7-4860 @ 2.27GHz 2.26 GHz（2 個處理器）
安裝記憶體：4GB
數據庫文件硬碟：300GB
用於備份的硬碟：150GB
日誌硬碟：100GB
應用：
我們有 3 個主要數據庫，總計約 170GB 的數據，一個位於同一伺服器上的 Reporting Services 數據庫 (SSRS)，其中可能包含每天生成的 10 個不同的報告（每個報告平均包含 700k 條記錄）。我們的使用者群大約有 20 個同時使用者，其中可能有 5 個被認為是“資源密集型”的，可以生成處理數據的大型報告。大多數使用者通過asp.net 網站和Report server 網站與數據庫進行互動。此外，我們的開發人員通過直接遠端連接到伺服器（最多 2 個遠端連接）在 BIDS 中廣泛使用 SSIS。最後，我們有一個相當複雜的數據倉庫操作，每天可能通過同樣在伺服器上執行的 SSIS 包引入 300 萬條記錄。
目前問題：
我們有長期的伺服器超時，對網站的響應時間非常糟糕。我懷疑我們擁有的記憶體量（4GB）可能是一個很大的瓶頸。我們之前對額外記憶體的請求已被拒絕，常見的響應是我們需要執行更多查詢優化。雖然我們不是 sql 專業人士或（我相信你可以從我們的設置中看出）db admin 專業人士，但我想確保如果硬體是瓶頸。
感謝大家的 tl;dr 避免！
……希望我能得到……對我們應該執行的粗略估計。
如果沒有關於您的查詢和數據大小的更多資訊，真的很難給您任何類型的估計，更不用說準確的估計了。
數據庫：sql server 2008 r2 企業數據庫
Windows：Windows 2008 r2 Enterprise 64 位，可以肯定在 VMware 上執行。
處理器：Intel(R) Xeon(R) CPU E7-4860 @ 2.27GHz 2.26 GHz（2 個處理器）
安裝記憶體：4GB
兩個處理器（我假設這在 VM 中作為 2 個核心公開）可能或可能不會配置不足。分配給 VM 的核心不一定直接映射到物理核心（甚至在需要時允許使用 100% 的單個核心！），因此您可能會發現這是一種比記憶體更靈活的資源。如果沒有關於您的工作負載或硬體/虛擬化配置的更多資訊，我會說將其增加到 4 會很不錯。
記憶體分配。好傢伙。這對於工作負載來說是嚴重不足的。Windows 本身至少需要 2-3 GB 才能保持快樂，並且在盒子上執行 BIDS 的 2 個使用者中的每一個都需要至少 500 MB。有了這個，盒子已經用完了，我什至沒有開始弄清楚數據庫需要多少。
大多數使用者通過asp.net 網站和Report server 網站與數據庫進行互動。
您沒有說，但如果它們在同一個機器上執行，則還需要考慮它們的記憶體要求。
最後，我們有一個相當複雜的數據倉庫操作，每天可能通過同樣在伺服器上執行的 SSIS 包引入 300 萬條記錄。
假設它在晚上系統上沒有實時使用者時執行，我不認為這是一個問題，除非執行時間太長。這部分事情是你最不擔心的；現場使用者更重要。
我們之前對額外記憶體的請求已被拒絕，常見的響應是我們需要執行更多查詢優化。
正如我在上面所展示的，目前配置的記憶體量完全不足。然而，與此同時，在頻譜的另一端，您極不可能獲得足夠的記憶體配置，以便能夠一次將整個數據庫保存在記憶體中。
即使你得到了這樣的一攬子回應（順便說一句，這可能更多地與你對額外資源的理由的說服力有關，而不是實際的資源使用本身），數據庫的效率很可能是改善。然而，沒有任何調整可以解決您現在遇到的問題。對我來說，這個建議完全不是首發。
我會採取總體方法，即目前配置的記憶體量低於最低要求（應盡快糾正），並且可能需要額外的資源來將使用者體驗提高到可用水平，同時進行*改進以提高效率系統。*
以下是一些想法（按攻擊順序）：
- 如果您能證明每次配置更多資源時性能會提高多少，那麼您將獲勝。使用性能監視器日誌記錄跟踪性能指標（注意：日誌記錄部分非常重要），如果可以的話，包括網站響應時間。現在開始做這件事，然後再做其他事情。當您最終達到最小記憶體量時（您不會立即獲得 32 GB），突然間您現在有證據表明添加的記憶體改善了一些事情……這意味著添加更多可能也會有所幫助！如果您沒有在目前配置上收集基線，那麼當事情被提升到最低推薦水平時，您將錯過這條船。
- 分析伺服器的等待統計資訊。這將告訴您系統中最大的瓶頸是什麼。您可能會遇到
PAGEIOLATCH_XX最常見/最長的等待時間，這表明正在執行過多的 I/O 以從磁碟獲取頁面。這可以通過添加記憶體來緩解，因此物理 I/O 變得不那麼頻繁，因為所需的數據已經在記憶體中。雖然這種分析幾乎已成定局，但在證明對資源的需求時，您已經收集了這些統計數據這一事實為您提供了更多彈藥。- 正如我上面提到的，記憶體的最低要求沒有得到滿足。為您正在執行的所有軟體收集一組推薦的硬體要求，也許還可以抓取任務管理器的螢幕截圖。僅此一項就足以證明當場至少增加 4-8 GB 是合理的。如果他們仍然拒絕，請嘗試說服他們允許您試用一周，然後在此之後將其歸還（您正在收集性能統計數據，因此您不需要歸還它，因為在周中您將能夠證明它改善了多少情況）。如果他們仍然拒絕，你就注定要失敗；網址_
- 如果您可以解除安裝一些工作負載（特別是，盡可能避免遠端處理），這將增加可用於數據庫的記憶體量，這一點更為關鍵。
- 您將無法一次將整個數據庫放入記憶體中，這意味著您需要非常小心地設置 SQL Server 的最大記憶體設置，以防止記憶體過度送出，這會像其他任何事情一樣扼殺性能。過度送出實際上比無法將所有數據都放入記憶體*更糟糕。*您現在很可能處於這種情況，因為根本沒有可用的記憶體，並且最大記憶體設置很可能設置為預設值（無限制）。
- 由於您執行的是 SQL Server Enterprise Edition，並且記憶體非常寶貴，因此我強烈考慮實施數據壓縮。這將犧牲 CPU 使用率的增加來節省記憶體空間（從而減少磁碟訪問，這相對非常慢）。
- 調整數據庫。就索引和訪問模式而言，結構和查詢可能會使用改進。此外，如果經常掃描和匯總大量數據，則創建索引視圖、匯總表或預計算報告可能會很有幫助。
- 這可能是一個遠景，因為它可能意味著更多的硬體配置，但實施一個記憶體解決方案。最快的查詢是您從未做過的查詢。
這些只是一些想法。最重要的是，單獨調整併不能解決這裡的問題，單獨的硬體也不能解決問題，儘管後者可能會緩解大多數直接問題。事情就是這樣：在短期內將硬體投入到問題上以撲滅大火，並在長期內對問題進行調整以盡可能地解決根本原因。