如何防止在索引重組期間事務日誌變滿？
我們有多台機器，我們已將事務日誌的大小預分配為 50gb。我嘗試重組的表大小為 55 - 60 GB，但會不斷增加。我想重組的主要原因是回收空間和任何性能優勢，因為這是額外的好處。
表的碎片級別為 30 - 35%。在其中一些機器上，我收到“事務日誌已滿”錯誤並且重組失敗。事務日誌大小達到 48GB。有什麼好的方法可以解決這個問題？我們沒有打開自動增量，我不願意這樣做。
我可以將日誌大小增加到更大的值，但是隨著將來表大小的增加，該值可能不夠。如果我要平等地增加日誌大小，它也違背了進行重組以回收空間的目的。關於如何有效應對這種情況的任何想法？使用批量模式不是一種選擇，因為數據失去是不可接受的。
最佳做法是
REORGANIZE低於 30% 左右的碎片並REBUILD高於此。簡單地說，REBUILD製作一個乾淨的副本，REORGANIZE在原位進行。檢查你實際在做什麼：你沒有維護計劃，對嗎？
在較大的表（50GB 表到達那裡）上，
REORGANIZE如果您遵循此規則，我已經看到消耗了所有事務日誌空間。不經常：只有一個系統具有一定的負載模式。剛剛執行，REORGANIZE直到日誌擴展並消耗了所有磁碟空間。我們轉而
REBUILD使用，沒有更多問題，但忽略了低於 25% 的碎片。這對我們來說效果更好：你必須看看它是否適合你。
REBUILD可能對性能的影響比REORGANIZE在生產中更大，但有時可以通過ONLINE選項（需要企業版）來緩解這種情況。
REORGANIZE（如在 ALTER INDEX … REORGANIZE 中）是一個非常快速的操作（嗯，主要是…），它需要少量的日誌，可以隨時中斷並稍後恢復，並且在小批量事務中在內部工作：
碎片整理是作為一系列短事務執行的，因此如果經常進行日誌備份或恢復模式設置為 SIMPLE，則不需要大日誌。
你確定你不是在談論重建？索引 REBUILD 緩慢、昂貴、消耗大量日誌（如果不離線且無法最小化記錄，則線上重建無法最小化記錄），是單個巨型事務，不能在不失去所有工作的情況下中斷。
在我看來，您正在進行重建，這是一項非常特殊的操作，除非您有非常深思熟慮的理由，否則您不應該這樣做。你想要什麼樣的空間回收？有什麼
DBCC CLEANTABLE處理不了的？您是否檢查過表的物理結構，它是否偏離了邏輯結構（有關詳細資訊，請參閱SQL Server 表列）？如果你真的要重建表，那麼恐怕你別無選擇，只能硬著頭皮分配必要的日誌。不要讓它自動增長，它只會減慢這個過程。將其預先增長到桌子大小的 2.5 倍。
如果表是分區的，那麼您可以一次離線重建（並重新組織）一個分區。線上重建只能在整個表級別進行。