SQL Server大型事務日誌的備份

備份資料庫包含兩個步驟。主要就是對資料庫執行 IO 讀取操作以及對備份裝置執行 IO 寫入操作：

　　備份步驟 1 讀取資料檔案中所有分配的資料，然後將其寫入備份裝置。

　　備份步驟 2 讀取某些事務日誌，然後將其寫入備份裝置。

　　所需的事務日誌數量可能會差異很大，但其數量一定能將還原的資料庫恢復到相同的時間點

　　而還原資料庫最多可能包含四個步驟。涉及的工作要比讀寫 IO 複雜得多：

　　還原步驟 1 如果資料庫檔案不存在，則建立它們。

　　還原步驟 2 從備份中讀取所有資料和事務日誌，然後將其寫入相關的資料庫檔案。

　　還原步驟 3 對事務日誌執行恢復過程的“重做”階段。

　　還原步驟 4 對事務日誌執行恢復過程的“撤消”階段。

　　兩個備份步驟所需時間與還原步驟 2 所需時間大致相同(假定硬體配置類似並且伺服器上沒有使用者活動)。如果資料檔案較大並且需要進行零初始化(這在 SQL Server 2000 中是需要執行的操作，在 SQL Server 2005 中是預設操作)，則還原步驟 1 可能需要較長時間。

　　為避免花費較長時間，請不要在開始還原之前刪除現有檔案。或者，也可以啟用即時初始化，以便快速建立這些檔案(有關詳細資訊，請訪問 msdn.microsoft.com/­library/ms175935.aspx)。

　　還原步驟 3 和 4 是對還原的資料庫進行恢復，以便確保事務一致性;此流程與崩潰恢復期間對資料庫執行的操作流程相同。恢復操作所需時間取決於需要處理的事務日誌量。例如，如果在進行備份時恰好有一個長時間執行的事務處於活動狀態，則該事務的所有事務日誌都會被備份進來，因此屆時不得不進行回滾。

　　資料庫映象過程是通過將實際的事務日誌記錄從主體資料庫傳送到映象伺服器來完成的，這些記錄在映象資料庫中將被“重播”。對於映象的資料庫，既不存在任何型別的轉換或篩選，也不存在任何型別的 T-SQL 命令攔截。

　　資料庫映象僅支援 FULL 恢復模式，這意味著始終會完全記錄索引重建操作。根據涉及的索引大小的不同，這可能意味著會生成大量事務日誌，從而導致主體資料庫的日誌檔案很大，在將日誌記錄傳送到映象時需要佔用大量的網路頻寬。

　　您可以將資料庫映象視為實時日誌傳送(實際上，這正是早期在 SQL Server 2005 開發期間該功能所使用的名稱)。在日誌傳送過程中，主資料庫的事務日誌備份會定期傳送到輔助伺服器上，並在輔助資料庫中進行還原。

　　日誌傳送功能支援 FULL 和 BULK_LOGGED 恢復模式。對於使用 FULL 恢復模式在日誌傳送資料庫中所執行的索引重建操作，生成的事務日誌量將與映象資料庫中生成的數量完全相同。但是，在日誌傳送資料庫方案中，資料是以日誌備份(或系列日誌備份)而非連續流的形式傳送到冗餘資料庫的。

　　如果在索引重建完畢後在日誌傳送資料庫中使用 BULK_LOGGED 恢復模式，則只會生成少量的事務日誌。但是在下次事務日誌備份時，還將會包含被所記錄的最低限度索引重建操作改變的全部資料檔案範圍。這意味著無論是納入在 BULK_LOGGED 恢復模式下重建的索引的日誌備份還是納入在 FULL 恢復模式下重建的索引的日誌備份，其大小都幾乎完全相同。

　　因此，對於映象資料庫與日誌傳送資料庫中的索引重建而言，需要傳送到冗餘資料庫的資訊量幾乎完全相同。實際的差別僅在於傳送資訊的方式 — 是連續傳送還是成批傳送。

　　在這兩種方法之間進行選擇時需要考慮許多其他因素(因素太多，僅在一次 SQL 問題解答中無法全部討論)。您應該先了解所有這些因素與您的需求的關聯程度(例如，可接受的資料丟失限制和允許的停機時間)，然後再做決定。

　　在完全恢復模式下進行事務日誌備份很重要，在這一點上您是對的。但是，還有其他一些因素可導致事務日誌增大。這完全取決於究竟是什麼在要求事務日誌成為被使用的日誌(或活動日誌)。除了缺乏事務日誌備份以外，可能會導致此現象發生的其他常見因素還包括複製、資料庫映象和活動事務等。

　　複製過程是通過非同步讀取事務日誌記錄，然後載入這些事務並將其複製到單獨的分佈資料庫來完成的。尚未被複制日誌讀取器任務讀取的任何事務日誌記錄都無法被釋放。如果您的工作負載生成了大量事務日誌記錄，而您又為複製日誌讀取器的執行頻率設定了較長的時間間隔，則會累積大量記錄，導致事務日誌增大。

　　如果您執行的是非同步資料庫映象，則可能會存在尚未從主體資料庫傳送到映象伺服器的事務日誌記錄儲備(稱為資料庫映象 SEND 佇列)。這些事務日誌記錄在成功發出之前無法被釋放。如果生成了大量事務日誌記錄，而網路頻寬又受到限制(或出現其他硬體問題)，則儲備可能會變得很大，導致事務日誌不斷增大。

　　最後，如果使用者啟動了一個顯式事務(如使用 BEGIN TRAN 語句)，然後進行了某些形式的修改(如 DDL 語句或插入/更新/刪除操作)，則所生成的事務日誌記錄在使用者提交或回滾該事務前都需要進行保留。這意味著由其他事務生成的任何後繼事務日誌記錄也無法被釋放，因為事務日誌無法選擇性地進行釋放。如果假設該使用者當天沒有結束該事務就下班回家了，則隨著越來越多的事務日誌記錄被不斷生成而又無法釋放，事務日誌就會越來越大。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-541410/，如需轉載，請註明出處，否則將追究法律責任。