如果需要終止/回滾集群/分區/移動操作，請維護超大表的最新副本
我在上一篇文章中附加了以下資訊，但我問的是“為什麼”而不是“如何”。
那麼問題來了…
SQL Server 2014，CU6。4.5 TB 數據庫，簡單恢復。最重要/訪問的表是 1.6 TB，位於主文件組上。它目前大約 95% 是碎片化的，因此大多數查詢都需要對其 600M+ 行進行全面掃描。毫不奇怪，這是一個 IO 瓶頸，我無法在任何可接受的時間視窗內進行碎片整理。我的目標是將這個表從 .mdf 和集群/分區移到它自己的文件組 (
ONLINE=ON & SORT_IN_TEMPDB=ON) 中。這個新文件組將在一個專用磁碟陣列上進行物理隔離。但我非常擔心任何可能導致（或必須）回滾的問題（例如電源故障、死鎖、損壞、操作期間性能過慢等）。
此外，考慮到此集群/分區/移動過程可能花費的時間長度，在此期間進行的任何備份都將是無用的。它們在恢復後會立即進入恢復狀態，並且再次回滾/前滾時間將是不可接受的。如果我要打開完整的日誌記錄並使用事務複製或日誌傳送，同樣的交易——毫無價值的輔助或訂閱者。
你會如何處理這個過程？
我考慮過製作表格的副本，在源上觸發以使副本保持最新。
我在所有涉及的捲上都有很大的空間緩衝區。我想扣動扳機。老闆說“還沒有”。
謝謝閱讀…
-格雷格
我已經做過幾次了。但是，我的伺服器只有 2008R2。我已經移動了這樣的表和“分區”數據，因為數據文件達到了最大大小（16tb）並且標識列達到了整數最大值。
大表上的索引重建可能需要一些時間才能回滾。重組不會，但是它要慢得多（單執行緒）。你可以立即殺死它，它會停在原地，所以如果需要，你可以在幾個晚上的過程中完成它。我不得不用一些相當笨重的全文目錄來做到這一點。
如果表中有 (MAX) 數據類型，則將聚集索引重建到新文件組不是線上操作 - 請參閱下面的註釋。當我在處理我的流程時，這讓我感到驚訝。此外，請注意在 tempdb 中進行排序。我曾經嘗試對 3tb 表進行全面統計掃描，但我的 500gb tempdb LUN 一夜之間空間不足。
如果您有任何問題，請告訴我。
謝謝
取消索引建構（無論是線上還是離線）幾乎是即時操作。回滾工作很少。我的猜測是必須回滾一些元數據更改，並且必須釋放內置索引頁面。
我剛剛在我手頭的數據庫上測試了這個。
如果此過程失敗（即使由於斷電），索引重建將被取消並且回滾將非常快。
索引建構會生成大量日誌記錄（線上建構甚至比離線建構更多）。您可能會使日誌傳輸網路或輔助網路飽和。這是一個有效的問題，但它適用於任何索引建構。很有可能這對您來說不是問題。