我們正在遵循供應商建議的索引重建更改填充因子並啟用數據壓縮，在測試伺服器上，結果讓我們想知道發生了什麼會導致 TLog 超過 650 GB（驅動器空間不足）。為什麼tlog增長如此之快？

SQL Server 版本 12.0.2456.0

提供的供應商程式碼：

alter index all on dbo.ACC_LOG_DTL_IX rebuild with   
( data_compression=PAGE, fillfactor=85, online=ON)

這是表和一個索引的腳本。

CREATE TABLE [dbo].[ACC_LOG_DTL_IX](
   [ACCESS_INSTANT] [numeric](16, 6) NOT NULL,
   [PROCESS_ID] [varchar](254) NOT NULL,
   [DATA_MNEMONIC_ID] [varchar](15) NOT NULL,
   [STRING_VALUE] [varchar](2000) NULL,
   [INTEGER_VALUE] [numeric](18, 0) NULL,
CONSTRAINT [PK_ACC_LOG_DTL_IX] PRIMARY KEY CLUSTERED 
(
   [ACCESS_INSTANT] ASC,
   [PROCESS_ID] ASC,
   [DATA_MNEMONIC_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

無論您的恢復模式如何，只要操作（索引重建或重組）修改數據頁面，頁面修改就會被放入日誌中。在您的情況下，更改填充因子可以添加更多數據頁面，並將數據移動到新頁面。SQL Server 必須為新數據騰出空間，為此它必須跟踪頁面更改。更改的頁面越多，事務日誌中的條目就越多。

在你的情況下，我會問，你使用什麼儲存，你的碎片是什麼樣的？如果您使用快閃記憶體儲存，我會告訴您重建索引變得比使用磁儲存更重要。

為什麼 LOG 文件增長如此之快？

答案在已執行的腳本（有問題中提到）中：

線上 = 開

正如評論中已經確認的那樣，當您線上重建索引時，日誌文件中需要額外的空間（可能是索引大小的兩倍），因為每個索引（集群或非集群）的線上操作都會比正常的離線重建產生更多的重做，這是您可能想要查看更多詳細資訊的案例研究

填充因子 = 85

填充因子是考慮減少潛在的頁面拆分，它基本上在頁面中為索引擴展提供足夠的空間，因為數據被添加到基礎表中，這意味著在您嘗試使用填充因子重建索引時 85% (其中預設為 100%），它試圖將 15% 的頁面重新定位到新頁面，這會導致更多的儲存需求，可能不是每個表都需要填充因子，必須考慮特定的讀寫成本操作來做出決定表/索引。有關填充因子的更多詳細資訊

引用自：https://dba.stackexchange.com/questions/100992