恢複整個SQL server資料庫還是只恢複錯誤檔案組

這有一個具體例子：如果你有一個單個的出現問題的檔案。這個檔案有50MB大小，而你的整個資料庫 運行著大約有幾十億的位元組，這樣的話如果能恢複單個失敗檔案的話就顯的非常有意義。這樣的事情發生 的一個情景是當檔案或者檔案組在單獨的磁碟機上，而磁碟機出現了問題。通常，僅僅恢複單個檔案或者 檔案組會使總的停止時間縮短，因為它明顯減少了需要恢複的總的資料量。

現在，為什麼你不選擇這麼做呢?這有一些原因：

你需要有交易記錄備份。如果你想從備份中恢複一個檔案或者檔案組，你同時也需要恢複與它們一起 建立的事務記錄備份，從而使整個資料庫能夠處於一個一致的狀態。在SQL Server 2000 和 2005中，你 需要使用Full Recovery或者Bulk-Logged Recovery模式(也就是說不是Simple Recovery)來使它成為可能 。我應該指出SQL Server的實現者們並沒有盡他們的努力來完成判斷從上一次備份一個檔案或者檔案組是 否已經被修改了的功能。如果沒有被改變，那麼事務記錄是沒有什麼必要的。但是，總的來說，還是需要 事務記錄備份的，如果你現在還沒有一個備份事務記錄的恢複或者備份計劃，那麼現在就建立一個吧。

在要恢複的檔案或者檔案組中的表格與資料庫中其他的表格之間的資料不一致性成為需要考慮的一個 問題。如果你有相互之間依賴的表格，並且這些表格沒有被儲存在相同的物理檔案或者檔案組中(這有時 是不可避免的)，僅僅恢複一個檔案或者檔案組可能會導致它與資料庫其他部分不同步。例如，你有一個 表格被另一個表格用JOIN關聯，並且這個JOIN使用了一個視圖和預存程序，這時僅僅恢複一個而不恢複另 一個可能會有問題。

當你在資料庫中只有一個檔案組。如果你的所有的資料僅僅儲存在一個檔案或者檔案組中，並且它又 不是一個特別大的資料庫時，會發生什麼事情呢?那時恢複一個檔案或者檔案組的努力就變的沒有什麼意 義了。

選擇性的恢複檔案或者檔案組的主要原因是當恢複資料庫很大，以至於恢複整個資料庫的代價很大的 時候，使得對資料庫的局部損壞的恢複成為可能。在一個非常小的輕量級的資料庫裡，和nonproduction 系統中，或者資料庫中只有一個檔案組的時候，實現選擇性的恢複功能就顯的沒有太大的意義，因為這時 恢複整個資料庫和恢複單個的檔案或者檔案組沒有什麼太大的區別。

我發現大多數時候當人們想使用檔案或者檔案組恢複時，他們實際上是想把一個特定的表格恢複到先 前的一個點的時刻的狀態。這在SQL Server中不是一個顯式支特的特性，但是存在這麼做的方法，倘若你 不介意由於採用這種方法而需要手工的來管理可能產生的不一致(就想上面#2所說的)。如果你手邊就有一 個Database Backup的話，你可以簡單的恢複那個備份，僅僅把它看作是相同資料庫的不同名字的執行個體。接著， 通過事務記錄把資料庫向前滾動到指定的點(如果需要這樣做的話)，然後手工的把當前的資料庫拷貝到目 標資料庫中。

我自己已經實驗過這種方法幾次，但是僅僅只有一個表格沒有與相同資料庫中的其他的表格有很大的 關聯。我的例子涉及了一個包含了留言版系統的聊天網站。我不得不經常恢複一些在留言版上被意外刪除 的訊息，這些是自包含的：從留言版表格的資料產生的唯一的JOINs是外部的而不是內部的。因此，我可 以隨意的更新表格因為我知道我不會讓那個表格與其他表格不同步的。

在SQL Server 2000和它更高的版本中，當你做一個RESTORE操作的時候你可以使用PARTIAL子句，從而 使僅僅需要的檔案組資料被恢複。這作為一個時間和空間上的節約開銷的措施是非常有用的：你不需要進 行繁重的恢複所有資料的工作，而僅僅只需要對一個表格進行操作。而且很可能也沒有足夠的空間來進行 完全的恢複操作。