SQL Server恢復模子之批量日記恢復形式。本站提示廣大學習愛好者：（SQL Server恢復模子之批量日記恢復形式）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server恢復模子之批量日記恢復形式正文
你能否想曉得為何事務日記文件會變得愈來愈年夜？事務日記有時刻乃至會比你的現實數據庫文件還要年夜，特別是在運用數據倉庫的情形下。為何會產生這類情形呢？若何掌握其年夜小？數據庫恢復模子若何掌握事務日記增加？在本系列文章中，我們就將逐個給出解答。
批量日記恢復形式
批量日記恢復形式與完全恢復形式相似，都預期會有年夜批量的數據修正操作(例如，創立索引，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。數據區將復制到日記中，後跟日記數據。下圖顯示了日記備份的結構方法。
主要提醒：
在完全或年夜容量日記恢復形式下，假如沒有其他身分使日記記載堅持為運動狀況，則到停止第一次完全備份時，主動檢討點才會截斷事務日記的未應用部門。第一次完全備份後，截斷請求備份事務日記。有關截斷延遲身分的信息，請參閱能夠延遲日記截斷的身分。
