為什么我的日志文件需要sql server中物理表大小的3倍

Question

我有一張約有600 million records的表，表大小約為45 GB 。 我剛剛觸發了一個查詢，向其中添加了另一個bigint列，即存儲大約需要4GB，即

4GB = 600 Million * 8bytes

該表上沒有索引。 然后，為什么此操作占用日志文件超過150GB的空間。

這是我正在研究的垃圾數據，以了解不同操作的影響。

我正在尋找此問題的原因和解決方案。

Answer 1

添加列時，必須更改包含該表中數據的每個頁面，並且必須記錄每個更改，以便可以在需要時將其回滾。

參見https://dba.stackexchange.com/questions/29522/why-does-alter-column-to-not-null-cause-massive-log-file-growth

另外https://social.msdn.microsoft.com/Forums/sqlserver/zh-CN/6d7aacf6-ff41-4f59-8d4a-bd0909568626/excessive-log-growth-for-alter-column-and-insert-into並閱讀萊克斯的回答。

Answer 2

您可能會考慮使用BULK LOGGED恢復模式進行此類更改...在更改之前將其打開，然后再返回到常規日志記錄。 在較少的使用時間或（最好是）計划的停機時間內進行更改。

此外，如果您處於“完全恢復”模式（與“簡單恢復”模式相對），則僅在備份事務日志后才清除事務日志。 完全備份將不允許事務日志進行清理，並明確收縮或截斷日志，在這種情況下， 也無濟於事。 您希望將事務日志備份的發生頻率設置為您的I / O性能所需的頻率，這可能比您想象的要頻繁得多 。 SIMPLE RECOVERY模式可以避免此問題（完全備份確實可以完成所有操作），但是您將失去執行時間點還原的能力。