812
技術社區[雲棲]
不可不知的SQL Server還原過程
為何要對數據庫的還原過程進行“長篇大論”？
如果一個數據庫還原的時間遠超日常均值，眼看時間一分分過去，但還未結束，更嚴重的是，你不知道什麼時候能結束，出了焦急等待，你可能會這麼做：
- 還原假死了，我要停止這次還原，重新還原一次；
- 備份文件有問題，換個備份文件再試一次（盡管會有數據丟失）；
然而你以為的解決方法並沒有出現預期的效果，而浪費在這些方法上的時間讓業務係統恢複變得更加遙不可及。
如果你熟知還原的過程，你就能跟蹤還原的進度，而當你看到進度在變化時，讓你至少能看到業務恢複的時間在一步步靠近。
數據庫還原有3個階段
階段1：複製文件的階段
在階段1中，SQL Server將備份文件中的所有的數據、日誌、索引拷貝到還原後的數據庫文件中。
此時，你在數據庫的日誌文件裏，可以看到數據庫start的記錄，同時該數據庫會被標記為restoring。
如下視圖可以幫助你查看複製的進度：
select percent_complete,last_wait_type,* from sys.dm_exec_requests
階段2：redo
階段2是還原的redo階段，
SQL Server根據日誌文件對已提交的事務進行redo，將數據庫恢複到recovery point，但此時，日誌文件中因存在未提交的事務需回滾，因此，此時數據庫還處於不可用狀態。
進入此階段時，你會在數據庫的日誌中看到數據庫會再次starting一次，且能看到百分比顯示的redo進度，注意，此時如果你查看sys.dm_exec_requests視圖中percent_complete字段，你會發現一直顯示100%，這是正常的，因為redo的進度並不會在sys.dm_exec_requests中顯示。所以切記不要以為還原卡死了而結束還原。
階段3：回滾
階段3是還原的回滾階段，
SQL Server對日誌文件中未提交的事務進行回滾，從而保證數據的一致性。數據庫隻有在回滾完成後，才會變得可用。
如果備份文件的事務日誌中存在大量未提交的事務，那回滾的過程就會很長，還原的時間可能遠超日常的均值。
筆者曾經遇到這樣的場景：數據庫的備份文件中包含了一個執行了10天沒有完的事務（死循環）的日誌，當我在進行還原時，整整還原了2天，客戶的業務係統也停了2天。
這個階段的還原進度也隻能在SQL Server的錯誤日誌中才能看到，當你看到進度為100%日誌時，SQL Server會執行一個checkpoint操作，它會將內存中的髒數據固化到磁盤。
checkpoint執行時間的長短取決於內存中髒數據的大小，保守的估算方法是：假設內存的大小就是髒數據的大小，
checkpoint執行時間= 內存大小/數據文件（mdf）的寫入速率
其中寫入的速率可以在資源監視器（win2012及以上的係統）中可以詳細看到。