遷移前縮小數據文件以節省磁碟空間
我知道這是在各種論壇上討論最多的答案：我完全理解在大多數情況下答案是否定的。
但是想知道在任何情況下它是否都是好方法：
假設目前的產品數據庫在我們的例子中超過 30 TB，並且數據保留了 1 年。表大多是壓縮和分區的。
開發團隊提出了他們不需要數據來保持長達一年的邏輯，並希望將保留期更改為 6 個月。因此，預計清除後數據將減少一半，並且只有 6 個月的數據。
這是我們被要求處理壓縮數據文件的地方，以便可以返回那些具有 TB 空間的 LUN，或者如果我們遷移到新的 sql 版本，我們會要求讓我們說少一些（大約 10）TB，這確實可以節省一些錢，假設我們為未來的數據庫增長保留了 5Tb 的額外空間。
在這種情況下，如果我們假設在低峰值時間阻塞可以被接受或者如果收縮執行更長的時間可以被取消，那麼我們在小塊中進行收縮會有所幫助嗎？
上述收縮數據文件活動的價值是多少，還是有更好的方法？
編輯 –> 我們正在遷移到最新版本，可能是 SQL 2017 或 SQL2K19。這些表不是基於文件組進行分區的，因為對於這個數據庫，所有 30 多個文件都在主數據庫上。我知道，它只是一個供應商數據庫設計，我手裡沒有太多東西。
這是一個非常龐大的數據庫，需要縮小。在開始收縮操作之前，我只想指出您要檢查的兩件事：
LOB 數據。這將永遠持續下去，因為 LOB 數據沒有反向指針。即，一個LOB 頁面被移動並且所有SQL Server 都知道它屬於哪個表。它必須進行表掃描才能找到該行，該行對應於該頁面上的每個 lob 值。
堆表。對於移動的每個頁面，SQL Server 必須修改該頁面上每一行的每個 nc 索引。與聚群表相比，縮小堆表所需的時間很容易延長 5-10 倍。
對於該大小，您可能要考慮的一個選項是在收縮之前將數據移動到其他地方（文件組）（或者如果該文件組現在為空，則可能只是刪除該文件組）。