為 Microsoft SQL Server 安裝配置物理儲存
我正在配置 Microsoft SQL Server 安裝，它將使用 SAN 進行儲存。對於 SAN 儲存，我有：
- 少量SSD盤
- 更多的 10K 磁碟
我的 SAN 支持儲存分層。
我對如何使用 SSD 磁碟持懷疑態度。以下是想到的選項：
- *選項 1：*使用 SSD 和 10K 磁碟創建分層儲存，並使用自動分層將高度訪問的數據移動到 SSD。然後將該儲存池分成幾個不同的驅動器。
- *選項 2：*將關鍵（I/O 密集型）數據放在 SSD 上，並將其他所有數據放在 10K 磁碟上。
問題
我沒有足夠的 SSD，所以一切都可以駐留在 SSD 上。那麼對於 SSD 儲存而言，最重要的性能是什麼？
tempdbs?LDF文件？MDF文件？我的數據庫的寫入密集度高於讀取密集型（如果這有所不同）。其次，在設置驅動器時我應該遵循哪些最佳實踐？
我應該為每個單獨的驅動器
tempdb嗎？LDF文件？MDF文件？系統數據庫怎麼樣
master，model等等，應該放在自己的專用驅動器上還是在C:驅動器上？伺服器磁碟活動
順便說一下，這是我們現有數據庫伺服器磁碟活動的螢幕截圖。似乎
tempdbs是最密集的讀/寫，其次是我們的MDF文件，令人驚訝的是，該LDF文件似乎具有最少的 I/O。
任何意見，將不勝感激。
首先，查看您的 SAN 供應商的文件以獲取有關 SQL Server 儲存的建議。這確實應該是您的第一步，因為供應商希望已經為您完成了很多此類一般性分析。
如果文件未提及託管數據庫，請在選擇使用分層儲存之前進行更多探勘。了解層之間的數據遷移如何在您的 SAN 上工作以及它發生的頻率。請注意任何會執行計劃作業的任何事情，該作業會跟踪一段時間內（通常是 24 小時，但如果經常可配置）內扇區的活躍程度。我發現在這種情況下，當需要遷移數據時，在操作過程中訪問數據的速度通常很慢。您需要確保此過程在數據庫活動較少的時期內執行（這意味著不要在備份數據庫的同時執行此過程）。如果您有一個全天都處於活動狀態的數據庫，我建議您根本不要使用分層儲存，如果這是分層在您的 SAN 上的工作方式。執行此類分析時，在層之間遷移數據的另一個問題是，數據訪問模式經常發生變化，並且在一天中不一致。這可能導致數據存在於真正不應該存在的更快層上。例如，當您在夜間執行索引維護時，SAN 可能會將該數據標記為熱數據並將其遷移到更高層。如果在下一個遷移分析視窗期間沒有訪問這些索引，那麼您現在將 I/O 浪費在空閒數據上。根據您的數據庫使用模式，這可能經常發生，您的數據被遷移到更快的層只是閒置在那裡。這可能導致數據存在於真正不應該存在的更快層上。例如，當您在夜間執行索引維護時，SAN 可能會將該數據標記為熱數據並將其遷移到更高層。如果在下一個遷移分析視窗期間沒有訪問這些索引，那麼您現在將 I/O 浪費在空閒數據上。根據您的數據庫使用模式，這可能經常發生，您的數據被遷移到更快的層只是閒置在那裡。這可能導致數據存在於真正不應該存在的更快層上。例如，當您在夜間執行索引維護時，SAN 可能會將該數據標記為熱數據並將其遷移到更高層。如果在下一個遷移分析視窗期間沒有訪問這些索引，那麼您現在將 I/O 浪費在空閒數據上。根據您的數據庫使用模式，這可能經常發生，您的數據被遷移到更快的層只是閒置在那裡。
再次，查看您的供應商文件。我希望他們清楚地概述了他們的硬體所需的推薦方法。另外，請閱讀 Brent Ozar 的SAN Storage Best Practices for SQL Server。這對一些最佳實踐有更深入的了解，非常值得一讀。
嗯，一般來說：
- LDF 對延遲敏感但線性。SAN WriteBack 記憶體（或帶有 BBU 和回寫的本地 Raid 控制器）足以處理延遲，吞吐量可以由體面的 HDD 處理。
- Tempdb 可以對延遲和吞吐量敏感。一般來說，我根本不會把它們放在 SAN 上 - 零意義。使用本地 M.2 NVM 光碟。如果需要，請為他們準備一張 PCIe Raiser 卡。關鍵是每次重新啟動時都會重新生成 TempDB - 所以當機器故障轉移時不會“失去”任何東西。一個像樣的 M.2 SSD 有大量的頻寬（除非你使用 128g 光纖）。也就是說，大多數 TempDb 不需要這個，因為它們從未受到挑戰。根據您對數據的處理方式，tempdb 可能會過得很平靜。
對於其餘部分，我會選擇明智的儲存分層。或者，使用多個文件組並將熱門文件組放在 SSD 上（如果是按表）（使用分區會變得笨拙）。很多取決於數據 - 但分層可能是最好的解決方案（也是從易用性的角度來看）。