用於更快查詢的儲存配置
請就為新的 SQL Server 2019 機器設置儲存分配提供建議。
- 銳龍 7 8 核 64GB 記憶體
- 4 個本地驅動器（2TBNVMe PCIe4 + 1TBNVMe PCIe3 + 2TBSSD + 4TBHDD）
我將按如下方式分配驅動器：
- 2TBNVMe PCIe4 = 中密度纖維板
- 1TBNVMe PCIe3= LDF
- 2TBSSD = 作業系統 + 臨時文件
- 4TB HDD = 每日 SQL 備份
我計劃上述設置以獲得最佳查詢結果（我們將有 10X100GB 的數據庫文件，每天並發昂貴的查詢和每週一次的批量插入）——請告知這是否是最佳的本地儲存配置。
或者我應該將 NVMe PCIe3 分配給臨時文件以實現最佳查詢並將 SSD 切換到 LDF（因為我們將每週進行一次批量插入）。
一旦我們打開所有數據庫，我計劃將 RAM 增加到 128GB。
我不能有第五個驅動器。LDF 不會被大量使用。我正在使用簡單恢復模式並且 DB 收縮已打開。
如果這是最好的本地儲存配置，請提出建議，或者我應該將 NVMe PCIe3 分配給臨時文件以進行最佳查詢並將 SSD 切換到 LDF（因為我們將每週進行一次批量插入）
在這種情況下 - 是的，最好將 NVMe PCIe3 分配給 Temp 文件以獲得最佳查詢並將 SSD 切換到 LDF。
因為根據您的描述，LDF 似乎每週只使用一次（不要忘記，您還可以
BULK_LOGGED在批量插入期間使用恢復模型來減少日誌記錄量），其間插入/更新/刪除的次數非常少或沒有.並且tempdb將受益於遷移到更快的 NVMe 驅動器，特別是如果您的並發昂貴查詢將大量使用臨時表。
另一方面，對於 1 TB 的數據庫，RAM 的數量似乎很小，128 GB 的 RAM 可能更適合您的情況。
另一件事是嘗試在單獨的驅動器上將 OS 與 LDF/tempdb 分開（第五），因為 LDF 或 tempdb 的高負載或意外增長會影響 OS 的工作並損害系統。
不建議使用 DB Shrink，您最好將其關閉並預增長到您知道在批量插入期間它不會再增長的特定大小。最好是讓數據庫顧問或數據庫供應商支持團隊調查您計劃的設置，調查未來的使用模式並在上線之前進行調整。