SQL Server恢複模型之批量日誌復原模式_MsSql

你是否想知道為什麼交易記錄檔會變得越來越大？交易記錄有時候甚至會比你的實際資料庫檔案還要大，尤其是在應用資料倉儲的情況下。為什麼會發生這種情況呢？如何控制其大小？資料庫恢複模型如何控制交易記錄增長？在本系列文章中，我們就將一一給出解答。

批量日誌復原模式

批量日誌復原模式與完整復原模式類似，都預期會有大批量的資料修改操作(例如，建立索引，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。資料區將複製到日誌中，後跟日誌資料。下圖顯示了記錄備份的構造方式。

重要提示：

在完整或大量記錄復原模式下，如果沒有其他因素使日誌記錄保持為活動狀態，則到進行第一次完整備份時，自動檢查點才會截斷交易記錄的未使用部分。第一次完整備份後，截斷要求備份交易記錄。有關截斷延遲因素的資訊，請參閱可能延遲日誌截斷的因素。