問：我在備份時注意到一些異常現象，希望您能解釋一下。我們需要經常備份 62GB 的生產數據庫，以刷新應用程序開發人員所使用的數據。我們總是先刪除舊副本然後再還原新副本。還原的副本與生產數據庫大小相同，而且數據看起來也一樣，但是與備份過程相比，還原過程所需的時間要長很多。這是怎麼回事?為什麼還原比備份需要更長的時間?
答：其實這不屬於異常現象。根據您所處的環境，這種現象通常是預料之中的。備份和還原所需的時間之所以不同，是由於每個流程必須執行的步驟不同。
備份數據庫包含兩個步驟。主要就是對數據庫執行 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 是對還原的數據庫進行恢復，以便確保事務一致性;此流程與崩潰恢復期間對數據庫執行的操作流程相同。恢復操作所需時間取決於需要處理的事務日志量。例如，如果在進行備份時恰好有一個長時間運行的事務處於活動狀態，則該事務的所有事務日志都會被備份進來，因此屆時不得不進行回滾。
問：我打算在日志傳送和數據庫鏡像之間選擇一種提供生產數據庫冗余副本的方法。我很擔心需要在兩個服務器之間傳送的事務日志數量，尤其是對於我們每晚都需要執行的索引重建操作。聽說鏡像功能發送的是實際的重建命令而非事務日志，而重建是在鏡像中完成的。真的是這樣嗎?如果是這樣，那麼對於 BULK_LOGGED 恢復模式，鏡像解決方案要優於日志傳送，對嗎?
答：您聽說的觀點是錯誤的。數據庫鏡像過程是通過將實際的事務日志記錄從主體數據庫發送到鏡像服務器來完成的，這些記錄在鏡像數據庫中將被“重播”。對於鏡像的數據庫，既不存在任何類型的轉換或篩選，也不存在任何類型的 T-SQL 命令攔截。
數據庫鏡像僅支持 FULL 恢復模式，這意味著始終會完全記錄索引重建操作。根據涉及的索引大小的不同，這可能意味著會生成大量事務日志，從而導致主體數據庫的日志文件很大，在將日志記錄發送到鏡像時需要占用大量的網絡帶寬。
您可以將數據庫鏡像視為實時日志傳送(實際上，這正是早期在 SQL Server 2005 開發期間該功能所使用的名稱)。在日志傳送過程中，主數據庫的事務日志備份會定期傳送到輔助服務器上，並在輔助數據庫中進行還原。
日志傳送功能支持 FULL 和 BULK_LOGGED 恢復模式。對於使用 FULL 恢復模式在日志傳送數據庫中所執行的索引重建操作，生成的事務日志量將與鏡像數據庫中生成的數量完全相同。但是，在日志傳送數據庫方案中，數據是以日志備份(或系列日志備份)而非連續流的形式發送到冗余數據庫的。
如果在索引重建完畢後在日志傳送數據庫中使用 BULK_LOGGED 恢復模式，則只會生成少量的事務日志。但是在下次事務日志備份時，還將會包含被所記錄的最低限度索引重建操作改變的全部數據文件范圍。這意味著無論是納入在 BULK_LOGGED 恢復模式下重建的索引的日志備份還是納入在 FULL 恢復模式下重建的索引的日志備份，其大小都幾乎完全相同。
因此，對於鏡像數據庫與日志傳送數據庫中的索引重建而言，需要發送到冗余數據庫的信息量幾乎完全相同。實際的差別僅在於發送信息的方式 — 是連續發送還是成批發送。
在這兩種方法之間進行選擇時需要考慮許多其他因素(因素太多，僅在一次 SQL 問題解答中無法全部討論)。您應該先了解所有這些因素與您的需求的關聯程度(例如，可接受的數據丟失限制和允許的停機時間)，然後再做決定。
