你是否想知道為什麼事務日志文件會變得越來越大？事務日志有時候甚至會比你的實際數據庫文件還要大，尤其是在應用數據倉庫的情況下。為什麼會發生這種情況呢？如何控制其大小？數據庫恢復模型如何控制事務日志增長？在本系列文章中，我們就將一一給出解答。
批量日志恢復模式
批量日志恢復模式與完整恢復模式類似，都預期會有大批量的數據修改操作(例如，創建索引，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。數據區將復制到日志中，後跟日志數據。下圖顯示了日志備份的構造方式。
重要提示：
在完整或大容量日志恢復模式下，如果沒有其他因素使日志記錄保持為活動狀態，則到進行第一次完整備份時，自動檢查點才會截斷事務日志的未使用部分。第一次完整備份後，截斷要求備份事務日志。有關截斷延遲因素的信息，請參閱可能延遲日志截斷的因素。
管理員可以選擇在運行時對系統的影響最小，同時又能滿足還原要求的備份過程。管理員還根據資源要求選擇數據庫的恢復模式。恢復模式將針對完全恢復數據的重要程度來平衡記錄開銷。恢復模式包括：
◆完全
數據非常重要並且必須能夠恢復到故障點。記錄所有的數據修改。可使用SQL Server 2000的所有恢復選項。
◆大容量日志記錄
如有必要，可重播某些大容量操作（大容量復制操作、select INTO、文本處理），因此不完全記錄這些操作。只能恢復到上一次數據庫或日志備份的末尾。
◆簡單
自上次備份後所做的所有數據更改都是可替代的，或是可重做的。記錄開銷最小，但不能恢復自上次備份結束後的內容。
後綴為.mdf和.ldf的文件分別為數據文件和日志文件，SQL SERVER2005數據庫只有具有這兩個文件才能恢復呢。在對象資源管理器中右鍵單擊“數據庫”節點，使用其中的“附加”功能來完成。
