你是否想知道為什麼事務日志文件會變得越來越大？事務日志有時候甚至會比你的實際數據庫文件還要大，尤其是在應用數據倉庫的情況下。為什麼會發生這種情況呢？如何控制其大小？數據庫恢復模型如何控制事務日志增長？在本系列文章中，我們就將一一給出解答。
批量日志恢復模式
批量日志恢復模式與完整恢復模式類似，都預期會有大批量的數據修改操作(例如，創建索引，SELECT INTO，INSERT SELECT，BCP，BULKINSERT)，在這種情況下可以最小化日志記錄量，因此它降低了性能影響。但是同時代價就是你可能不能做任何時點的恢復了。作為一種推薦的實踐，批量日志恢復模式可以與完整恢復模式一起使用，例如，你通常應該在常規操作時設置為完整恢復模式，然後在偶爾發生大批量操作時臨時切換到批量日志恢復模式。最後在完成大批量操作以後，再回到完整恢復模式。如果時間點恢復很重要的話，我們非常推薦在切換回到完整恢復模式以後做一次事務日志備份。
與完整恢復模式類似，事務日志文件將會持續增長，因此你需要頻繁做事務日志備份。如果沒有大批量操作，批量日志模式與完整恢復模式是一樣的，你可以恢復到任何時點，只要事務日志包含對數據庫後續做的所有變更記錄。
優點：通過對一些事務做最小化日志記錄優化大批量操作的性能。不會讓事務日志由於這些大批量數據操作而顯著增長。
缺點：如果日志損壞，或者在最近日志備份之後發生大批量數據操作，存在數據丟失的可能性。因此自最後一次備份後的變化必須被重做。
何時采用：推薦在偶爾發生的大批量數據操作之前切換到批量日志恢復模式，然後在完成大批量數據操作之後切換回到完整恢復模式。采用這種方式你仍然可以恢復到任何時間點，只是你最後一次事務日志備份不包含大批量數據操作，同時可以將大批量數據操作的日志量最小化。
要注意的是，最小化日志記錄意味著只記錄恢復事務需要的信息，而不支持時間點恢復。在最小化日志的情況下，事務日志基於大批量變更映射(MCP)頁做的大批量數據變更記錄頁軌跡，而不是對每次變化做日志。這種方式數據庫日志會更小，但是在你備份事務日志時，它包括了所有變更頁，因此即使事務日志非常小，事務日志備份也可能比它更大。
大容量日志恢復模式bulk_logged recovery model
The bulk-logged recovery model minimally logs bulk operations, although fully logging other transactions. The bulk-logged recovery model protects against media failure and, for bulk operations(bcp,BULK INSERT,SELECT INTO), provides the best performance and least log space usage.
The bulk-logged recovery model increases the risk of data loss for these bulk-copy operations, because bulk logging operations prevents recapturing changes on a transaction-by-transaction basis. If a log backup contains any bulk-logged operations, you cannot restore to a point-in-time within that log backup; you can restore only the whole log backup.
Bulk Changed Map (BCM) tracks the extents that have been modified by bulk logged operations since the last BACKUP LOG statement.
If using the bulk-logged recovery model, only details of the modified data pages are logged, allowing for better performance.
Tail Log backup
If your database is using the bulk-logged recovery model, and the transaction log contains minimally logged transactions, the data files which contain the modified pages must also be available. If those data files are unavailable, you will not be able to back up the tail of the transaction log. This is another point to consider when using the bulk-logged recovery model.
However, please note that the situation with the bulk-logged recovery model is identical to the full recovery model if no minimally logged transactions are created in the database
大容量日志恢復模式的工作原理
與完整恢復模式（完全記錄所有事務）相比，大容量日志恢復模式只對大容量操作進行最小記錄（盡管會完全記錄其他事務）。大容量日志恢復模式保護大容量操作不受媒體故障的危害，提供最佳性能並占用最小日志空間。
但是，大容量日志恢復模式會增加這些大容量復制操作丟失數據的風險，因為大容量日志操作阻止再次捕獲對每個事務逐一所做的更改。如果日志備份包含大容量日志操作，則無法還原到該日志備份中的時點，而只能還原整個日志備份。
在大容量日志恢復模式下，如果日志備份覆蓋了任何大容量操作，則日志備份包含由大容量操作所更改的日志記錄和數據頁。這對於捕獲大容量日志操作的結果至關重要。合並的數據區可使日志備份變得非常龐大。此外，備份日志需要訪問包含大容量日志事務的數據文件。如果無法訪問任何受影響的數據庫文件，則事務日志將無法備份，並且在此日志中提交的所有操作都會丟失。
為跟蹤數據頁，日志備份操作依賴於位圖頁的大容量更改，位圖頁針對每個區包含一位。對於自上次日志備份後由大容量日志操作所更新的每個區，在位圖中將每個位都設置為 1。數據區將復制到日志中，後跟日志數據。下圖顯示了日志備份的構造方式。
重要提示：
在完整或大容量日志恢復模式下，如果沒有其他因素使日志記錄保持為活動狀態，則到進行第一次完整備份時，自動檢查點才會截斷事務日志的未使用部分。第一次完整備份後，截斷要求備份事務日志。有關截斷延遲因素的信息，請參閱可能延遲日志截斷的因素。
