將現有生產數據庫遷移到新物理儲存結構的最佳方法
我最近在一家規模雖小但發展迅速的公司擔任高級數據庫管理員。我的首要任務是清理主數據庫的邏輯設計（向現有表添加主鍵和外鍵，刪除不再使用的數據庫對象，消除冗餘索引，添加缺失索引等），但現在初步的邏輯清理已完成我已將自己轉向物理設計。
目前的生產設置是我們有一個物理數據庫伺服器，4 個插槽，16 個核心，超執行緒，具有 32 個邏輯處理器和 256 GB 記憶體。CPU 使用率，即使在最繁忙的時候，通常也低於 15%。
對於儲存，我們有四個驅動器，C、D、E 和 T，其中 C 用於作業系統，D 用於數據文件，E 用於日誌，T 用於 TempDB。主數據庫的主數據文件的大小目前為 650 GB，但隨著公司的發展而不斷增長。D：驅動器上有 700 GB 可用空間，這是 Raid 10 中的 SSD，總容量為 1.45 TB。
我們使用的是 SQL Server 2014，但主數據庫處於 2008 兼容模式，由於在 2012/2014 兼容模式下發生的儲存過程之一的性能問題（在 2014 兼容中性能問題是一致的，在 2012 兼容中性能問題僅在負載下出現）
我想做的間歇性更改是將一個 650 GB 數據文件用於主數據庫並將其拆分為 2 個文件組（一個用於主數據，另一個用於非聚集索引），每個文件 8 個文件團體。所以我的問題是這樣的：
1）我是否應該期望以我描述的方式分解主要數據文件的性能或可靠性方面的任何收益？
- 我如何在生產數據庫伺服器上進行這些更改，我可以每天（最多）安排 30 分鐘的停機時間視窗？
另請注意，雖然我可以使用許多伺服器來測試這些更改，但在將它們投入生產之前，與實際生產相比，非生產硬體的動力不足。例如，我計劃用於測試的盒子承載了一個每天刷新的生產數據庫副本。它是一個 8 核、35.6 GB 記憶體的虛擬機，D: Drive 是託管在 SAN 上的虛擬磁碟，總空間為 1.19 TB。因此，雖然我可以在這台機器上測試我的更改，但我不能確信這台機器上的任何性能提升都將代表實際生產。
到目前為止，向我描述的狀態移動的所有嘗試都涉及到我的會話的 session_id 在 DbccFilesCompact 命令期間卡住了。發生這種情況時，percent_complete 不會增加，並且 SPID 被掛起，並且 dm_exec_requests 顯示它循環通過 PAGEIOLATCH_SH 等待各種資源。我不確定它需要多長時間才能完成（如果可以完成的話），但我一次執行了幾個小時，沒有任何進展。我可以終止該程序並且該終止會立即解決，但是當該程序被終止時，不會朝著所需的最終狀態取得任何進展。
有沒有人在自己的公司遇到過這個問題？如果是這樣，決議是什麼？
我不是 SQL Server DBA，我在工作中使用 MySQL。但有些真理是普遍的。:-)
1）我是否應該期望以我描述的方式分解主要數據文件的性能或可靠性方面的任何收益？
我觀察到任何可擴展性優化的好處取決於您執行的查詢。
實際上，優化的定義是，任何優化方法都會改善一種類型的查詢工作負載，因為它會惡化一些其他類型的工作負載。
- 我如何在生產數據庫伺服器上進行這些更改，我可以每天（最多）安排 30 分鐘的停機時間視窗？
我會設置一個副本伺服器（我在 SQL Server 土地上收集這些稱為訂閱伺服器）。重構副本的物理表空間。然後不管用多長時間，只要改製完成後能趕上master就行了。
我假設 SQL Server 複製是非同步的，並且與物理佈局無關，就像 MySQL 複製一樣。但我不知道 SQL Server 是否支持這一點。
一旦你完成了對副本的重構，並且它趕上了與它的主同步，你可以通過更改相應伺服器實例的 DNS 條目來“切換”。然後，無論數據庫的大小如何，停機時間都很短且很短。停機時間應該包括一些時間，以確保來自主伺服器的所有更改都已“耗盡”並完全應用於副本。
權衡是您需要一組額外的數據庫伺服器，至少是暫時的。這是使用虛擬伺服器或云伺服器真正可以為您節省的情況！
如上所述分解數據文件幾乎肯定不會帶來性能優勢。如果將聚集索引和非聚集索引放在單獨的機械陣列上，而不是放在單個陣列、SSD 或其他位置上，則拆分聚集索引和非聚集索引的做法可能會有所幫助。雖然，如果您在一個 SSD 驅動器/陣列上最大限度地提高吞吐量，那麼根據控制器等，拆分為兩個 SSD 驅動器/陣列理論上可能會受益。
您的伺服器更有可能從獲取 Tempdb 並將其登錄到 SSD 中受益。
而且，如果/當您的工作負載寫入繁重時，將數據日誌放在 SSD 上也可能會顯著提升。
如果您一直在使用目前配置，那麼我認為您可以確定將所有數據庫和日誌文件放在同一個 SSD 陣列上（儘管可能為空間管理分區）不會有不利影響。