選擇是否恢複整個SQL Server的方法介紹

  這有一個具體例子:如果你有一個單個的出現問題的文件。這個文件有50MB大小,而你的整個數據庫運行著大約有幾十億的字節,這樣的話如果能恢複單個失敗文件的話就顯的非常有意義。這樣的事情發生的一個情景是當文件或者文件組在單獨的驅動器上,而驅動器出現了問題。通常,僅僅恢複單個文件或者文件組會使總的停止時間縮短,因爲它明顯減少了需要恢複的總的數據量。
  爲什麽你不選擇這麽做呢?這有一些原因:
  你需要有事務日志備份。如果你想從備份中恢複一個文件或者文件組,你同時也需要恢複與它們一起創建的事務記錄備份,從而使整個數據庫能夠處于一個一致的狀態。在SQL Server 2000 和 2005中,你需要使用Full Recovery或者Bulk-Logged Recovery模式(也就是說不是Simple Recovery)來使它成爲可能。我應該指出SQL Server的實現者們並沒有盡他們的努力來完成判斷從上一次備份一個文件或者文件組是否已經被修改了的功能。如果沒有被改變,那麽事務記錄是沒有什麽必要的。但是,總的來說,還是需要事務記錄備份的,如果你現在還沒有一個備份事務記錄的恢複或者備份計劃,那麽現在就創建一個吧。
  在要恢複的文件或者文件組中的表格與數據庫中其他的表格之間的數據不一致性成爲需要考慮的一個問題。如果你有相互之間依賴的表格,並且這些表格沒有被存儲在相同的物理文件或者文件組中(這有時是不可避免的),僅僅恢複一個文件或者文件組可能會導致它與數據庫其他部分不同步。例如,你有一個表格被另一個表格用JOIN關聯,並且這個JOIN使用了一個視圖和存儲過程,這時僅僅恢複一個而不恢複另一個可能會有問題。
  當你在數據庫中只有一個文件組。如果你的所有的數據僅僅存儲在一個文件或者文件組中,並且它又不是一個特別大的數據庫時,會發生什麽事情呢?那時恢複一個文件或者文件組的努力就變的沒有什麽意義了。
  選擇性的恢複文件或者文件組的主要原因是當恢複數據庫很大,以至于恢複整個數據庫的代價很大的時候,使得對數據庫的局部損壞的恢複成爲可能。在一個非常小的輕量級的數據庫裏,和nonproduction系統中,或者數據庫中只有一個文件組的時候,實現選擇性的恢複功能就顯的沒有太大的意義,因爲這時恢複整個數據庫和恢複單個的文件或者文件組沒有什麽太大的區別。
  我發現大多數時候當人們想使用文件或者文件組恢複時,他們實際上是想把一個特定的表格恢複到先前的一個點的時刻的狀態。這在SQL Server中不是一個顯式支特的特性,但是存在這麽做的方法,倘若你不介意由于采用這種方法而需要手工的來管理可能産生的不一致(就想上面#2所說的)。如果你手邊就有一個數據庫備份的話,你可以簡單的恢複那個備份,僅僅把它看作是相同數據庫的不同名字的實例。接著,通過事務記錄把數據庫向前滾動到指定的點(如果需要這樣做的話),然後手工的把當前的數據庫拷貝到目標數據庫中。
  我自己已經實驗過這種方法幾次,但是僅僅只有一個表格沒有與相同數據庫中的其他的表格有很大的關聯。我的例子涉及了一個包含了留言版系統的聊天網站。我不得不經常恢複一些在留言版上被意外刪除的消息,這些是自包含的:從留言版表格的數據産生的唯一的JOINs是外部的而不是內部的。因此,我可以隨意的更新表格因爲我知道我不會讓那個表格與其他表格不同步的。
  在SQL Server 2000和它更高的版本中,當你做一個RESTORE操作的時候你可以使用PARTIAL子句,從而使僅僅需要的文件組數據被恢複。這作爲一個時間和空間上的節約開銷的措施是非常有用的:你不需要進行繁重的恢複所有數據的工作,而僅僅只需要對一個表格進行操作。而且很可能也沒有足夠的空間來進行完全的恢複操作。