大型 Microsoft SQL Server 數據庫的文件、文件組和 RAID 類型的最佳設置
首先——雖然我完全不接受建議；如果有任何好的方法可以提前測量/收集數據，我也很感興趣，我可以使用這些方法來確定要遵循哪些“經驗法則”以及跳過哪些。
我不能為應用程序顯著更改架構，雖然我懷疑開發人員對索引很滿意；我還不想取出它們的索引並替換它們。
我有一個相當大的電話應用程序數據庫，大約 60GiB 左右。數據主要分為：
- TRAFFIC 表（持續的順序寫入，偶爾沿著任意數量的索引進行長時間掃描以進行報告，快速增長。關聯索引也很大。）
- BILLING 表（持續的順序寫入，經常沿著 account_info 掃描使用者資訊）
- 其他所有內容（持續隨機訪問讀取和寫入，比其他兩個表更頻繁。）
我現在在一台單核機器上，3Gb 專用於 SQL Server 和 SQL Server 2005 中的磁碟記憶體。msdb 數據庫和作業系統位於 15k 硬碟驅動器 RAID 1 上。日誌文件和備份驅動器位於 15k 上硬碟驅動器，RAID 1。電話數據庫都在 2 x 15k 硬碟驅動器，RAID 10 上。（總共有八個驅動器。）
我正在大力升級硬體。將在 Server 2008 R2 x64 上安裝 SQL Server 2008 R2、12 核、32Gb RAM。它將有四個內部硬碟，可能用於作業系統和備份，但最大的變化是附加儲存 - 外部 SAS 介面上的 12 x 15k 驅動器。
我們在目前伺服器上有點 CPU/I/O 限制，但還不足以打擾 - 這個新伺服器將治愈很多罪過 - 但這次我仍然寧願做“正確”。
我可以做一個 6 個磁碟的大型 RAID 10 並將整個數據庫放到它上面，但我一直在考慮將 TRAFFIC 和它的索引文件分解到單獨的分區 - 以及可能的 BILLING。此外，Everything Else 在它自己的文件中可能會做得很好。
然後，當然，總是要考慮 RAID 10 與 RAID 5/6 與 RAID 50/60。
我想要一些關於如何處理這個決定以及如何確定是否值得分解驅動器以將 TRAFFIC/BILLING 分開的指導 - 以及我是否可以使用兩個文件組（PRIMARY 和 USERDEFINED）或者我是否願意需要更多。
順便說一句，sizeof(TRAFFIC) = sizeof(BILLING) * 2 >> sizeof(EVERYTHING ELSE)
謝謝，
讓我們從頂部開始。
我有一個用於電話應用程序的大型數據庫，大約 60GiB 左右
換種說法：我有一個非常小的數據庫。說真的，大約 10 年前，60 giga 大的時間。比較一下：我有一個 800gb 且還在增長的金融數據數據庫，一張表中有 95% 的數據；）
它將有四個內部硬碟，可能用於作業系統和備份，但最大的變化是附加儲存 - 外部 SAS 介面上的 12 x 15k 驅動器。
這是我要做的：
- 鏡像兩張光碟進行引導。放下一個 64GB 的分區，剩下的用於 TEMP。你不想在那裡看到很多 IO。
- 為日誌文件鏡像接下來的 2 張光碟。如果那些在 IO 上執行 hifh - 用 SSD 替換它們。鑑於您所做的少量更改……小型 80gb SSD 應該足夠了。
- 其餘的（12 個磁碟），放置一個巨大的 RAID 10。
更重要的是您重新配置我們的伺服器以使用：
- tempdb 的至少 12 個數據和日誌文件。不要自動生長那些。修復它們。
- 最少 12 個日誌文件。可不是鬧著玩的。也不要在這裡自動生長。
- 最少 12 個數據庫文件。我說 - 沒有自動增長？
然後，當然，總是要考慮 RAID 10 與 RAID 5/6 與 RAID 50/60。
考慮到 Raid 10 與其他之間的巨大性能差異，請在那裡考慮 - 對於任何需要高 IO 的情況，所有這些都將 Raid 5/6/50/60 中的水排除在外。RAID 5 / 6 僅在您放入 SSD 驅動器時才有意義 - 那麼顯著的 IO 損失將被完全吃掉。實際上，考慮到您微不足道的數據庫大小，即使使用 2x15 SAS 磁碟也可能在經濟上是愚蠢的。獲得 2 個 x200gb REALSSSD 驅動器，如果 RAID 10 超過 30 個驅動器，您將獲得大約 100 倍的 IO 性能。鑑於基礎設施的巨大成本，您可能會在此過程中節省大量資金。
實際上，最明智的做法是不要破壞整個 SAS 東西——你有 4 個驅動器插槽，將作業系統放在兩個驅動器上，在另一個驅動器的鏡像中使用 200gb SSD。完成的。而且比你的 SAS 東西快很多；）擁有一個微不足道的數據庫大小的樂趣。查看http://www.fastestssd.com了解目前狀態。現代 SSD 將在該設置中達到 200mb 的持續隨機速率，即使不是頂級的。這將使用您從 SAS 設置中獲得的平庸 IO 嚴重消除流量。
或者：30 個 SAS 磁碟可能是 4800 IOPS。RealSSD 在一張磁碟上最高可達 50.000，“弱時間”約為 36.000 IOPS。這意味著 ONE SDD 的速度大約是您的 12 盤設置的 7.5 倍 - 在緩慢的時刻。在好的時候大約快 10 倍。哎喲。
注意正確對齊分區並正確格式化文件系統（提示：不要使用標準的 4kb 節點大小 - 對於 SQL Server 來說很愚蠢）。
我可以做一個 6 個磁碟的大型 RAID 10 並將整個數據庫放到它上面，但我一直在考慮將 TRAFFIC 和它的索引文件分解到單獨的分區 - 以及可能的 BILLING。此外，Everything Else 在它自己的文件中可能會做得很好。
那將是對 SQL Server 的愚蠢濫用。鑑於它在文件之間進行負載平衡並且想要/要求每組多個文件（每個邏輯處理器一個）它不會獲得任何東西 - 正好相反。如果文件和索引最終出現在同一張光碟上，那麼分離文件和索引將一事無成。在您的情況下，您最好使用一個文件組，12 個文件。如果您想要以後的可擴展性，您可能希望從 48 個數據文件開始 - 為您提供多達 48 個處理器核心的空間。
您可能希望使用兩個文件組從波動較小的文件組中分離出計費數據-/請求一個，但不是為了直接速度，而是為了獲得可能在以後完全移動它們而不進行重組的特權-這就是我對我的財務所做的數據庫。
最後一句話：購買伺服器的人在硬體方面做出了錯誤的決定。沒有理由為這麼小的東西配備外部 SAS 托盤。我的數據庫伺服器來自 SuperMicro，在 2 個機架單元高度上有 24 個磁碟插槽。那就是沒有外部籠子。我真的不想在這裡比較這些數字——但我敢打賭這是浪費了很多錢。