索引重建日誌增長
將生成多少日誌索引重建。我記得閱讀重建索引應該生成與表大小相同數量的日誌文件。但我的測試顯示並非如此。我們需要這個估計，因為我們正在嘗試建構 azure 數據庫索引並且它有一個限制最大 2 GB。
我的數據庫處於完全恢復模式。
表大小：
日誌大小：
從圖片中您可以看到線上索引重建操作的日誌生成非常少。如果我遺漏任何內容，有人可以糾正我嗎
如果您正在重建聚集索引，則實質上是在重建表，但非聚集索引只是表的子集（通常）。如果您使用 SORT_IN_TEMPDB 選項，您將解除安裝一些日誌記錄到tempdb 事務日誌。版本也很重要，在 2005 年，線上重建的日誌記錄最少，但在 2008 年改回完全記錄。您可能還想看看這篇文章，這可能有助於決定是否重建或重新組織考慮日誌大小.
- 更新 - -
使用 Shanky 的測試設置，我執行了相同的步驟，但我添加了一些額外的尺寸檢查。在重建之前，我會執行日誌備份並檢查日誌空間和使用率以及我的索引的事務日誌中的記錄。然後我進行重建測試並重新檢查日誌大小和日誌記錄數：
backup log IndexLogging to disk = 'NUL' --check log space/usage dbcc sqlperf (logspace) --check log records for the index, exclude the where for the total number of logs generated SELECT LogRecordsGenerated = COUNT(*) FROM sys.fn_dblog(NULL, NULL) WHERE AllocUnitName = 'dbo.Logging.IX_LOGGING' --Perform your rebuild operation and then recheck the same parameters我嘗試了十多次，每次得到相同的結果時，DMV 只告訴你事務，但是有幾個嵌套事務是由於 log_test 事務而產生的，這些事務沒有顯示，包括範圍和頁面的分配以及數據的插入。如果您查看日誌文件的實際內容，您會發現離線重建非常高效。它只是分配頁面/範圍，格式化它們並設置它們，然後釋放舊的。線上重建需要做更多的工作，因為它必須在重建時保持索引可用。這在鎖定中可能更明顯：離線它鎖定整個對象，但線上它必須逐頁逐個鍵。你可以自己看看比較：
SELECT OPERATION, Context, [Transaction Name], [AllocUnitName], [AllocUnitId], [Page ID], Description, [Lock Information], [Transaction ID] FROM FN_DBLOG(NULL,NULL)您可以通過在索引維護執行時臨時切換到 BULK_LOGGED 來減少生成的日誌，但您將無法在該時間段內進行時間點恢復。顯然它也不會減少您的日誌備份。
–更多關於從 DBCC SQLPERF (logspace) 和 SELECT LogRecordsGenerated = COUNT(*) FROM sys.fn_dblog(NULL, NULL) WHERE AllocUnitName = ‘dbo.Logging.IX_LOGGING’ 來顯示實際日誌大小的資訊，注意索引是只有 648KB
這是用數據填充後的日誌：
數據庫名稱 日誌大小 (MB) 已用日誌空間 (%) 狀態
索引記錄 14.99219 70.89956 0
生成的日誌記錄
10903
這是日誌備份後的日誌：
數據庫名稱 日誌大小 (MB) 已用日誌空間 (%) 狀態
索引記錄 14.99219 5.100313 0
生成的日誌記錄
0
日誌備份後登錄，然後線上重建：
數據庫名稱 日誌大小 (MB) 已用日誌空間 (%) 狀態
索引記錄 14,99219 22,642 0
生成的日誌記錄
11160
日誌備份後登錄，然後離線重建：
數據庫名稱 日誌大小 (MB) 已用日誌空間 (%) 狀態
索引記錄 14.99219 10.79338 0
生成的日誌記錄
140