減小 8 TB 數據庫大小的最佳方法？
我們有一個大小為 8 TB 的舊版 SQL Server 2005 數據庫。我們將從該數據庫中清除 5 年以上的數據。清除過程完成後，我希望能夠縮小數據庫或減小數據庫的文件大小。
我知道收縮（DBCC 收縮..）不是一個好的選擇。因此，正在考慮通過 SSIS 包將所有表/對象/數據導出到新數據庫，以便我可以回收所有空間。有沒有其他方法可以減小 mdf 和 ndf 文件的大小？
或者，我可以嘗試將所有數據導出到新文件組並刪除原始文件組。但是，大多數表都是堆並且沒有聚集索引。是否可以將所有數據/表移動到另一個沒有聚集索引的文件組？另外，如果我將所有數據移動到不同的文件組，我可以刪除主文件組嗎？
使用您的替代選項 - 創建一個新文件組，將數據移到那裡，然後刪除舊文件組。這是Paul Randall的建議，甚至：
那麼，如果您確實需要進行收縮怎麼辦？例如，如果您刪除了一個非常大的數據庫的大部分並且該數據庫不太可能增長，或者您需要在刪除之前清空文件？
我喜歡推薦的方法如下：
創建一個新的文件組。使用 CREATE INDEX … WITH (DROP_EXISTING = ON) ON 語法將所有受影響的表和索引移動到新文件組中，以同時移動表並從中刪除碎片。刪除您將要縮小的舊文件組（如果它是主文件組，則將其縮小）
基本上，您需要在壓縮舊文件之前提供更多空間，但這是一種更簡潔的機制。
如果您絕對別無選擇並且必須執行數據文件收縮操作，請注意您將導致索引碎片，如果它會導致性能問題，您應該在之後採取措施將其刪除。在不導致數據文件再次增長的情況下刪除索引碎片的唯一方法是使用 DBCC INDEXDEFRAG 或 ALTER INDEX … REORGANIZE。這些命令只需要一個 8KB 頁的額外空間，而不需要在索引重建操作的情況下建構一個全新的索引。
底線——不惜一切代價盡量避免執行數據文件收縮！
收縮不好，因為它會分散您的索引，如果您的大多數表都是 HEAPS，那麼聽起來 SHRINK 是一個可行的選擇。Shrink 最令人頭疼的是它對索引的作用。
收縮不必一次完成，分階段進行，通過可管理的塊減少。
對數據類型進行審查。如果您可以在轉換期間將列從 BIGINT 更改為 INT，那麼您將節省額外的空間。減少列的佔用空間將使索引修復變得不那麼麻煩。
使用 sys.dm_db_index_usage_stats 監視索引使用情況，應該刪除沒有掃描、搜尋或查找的索引。（注意：這些數字會在伺服器重新啟動時重置）請記住，對聚集索引的掃描與表掃描相同。刪除索引使縮小變得不那麼麻煩。