這有一個具體例子：如果你有一個單個的出現(xiàn)問題的文件。這個文件有50MB大小，而你的整個數(shù)據(jù)庫運行著大約有幾十億的字節(jié)，這樣的話如果能恢復單個失敗文件的話就顯的非常有意義。這樣的事情發(fā)生的一個情景是當文件或者文件組在單獨的驅動器上，而驅動器出現(xiàn)了問題。通常，僅僅恢復單個文件或者文件組會使總的停止時間縮短，因為它明顯減少了需要恢復的總的數(shù)據(jù)量。

為什么你不選擇這么做呢?這有一些原因：

你需要有事務日志備份。如果你想從備份中恢復一個文件或者文件組，你同時也需要恢復與它們一起創(chuàng)建的事務記錄備份，從而使整個數(shù)據(jù)庫能夠處于一個一致的狀態(tài)。在SQL Server 2000 和 2005中，你需要使用Full Recovery或者Bulk-Logged Recovery模式(也就是說不是Simple Recovery)來使它成為可能。我應該指出SQL Server的實現(xiàn)者們并沒有盡他們的努力來完成判斷從上一次備份一個文件或者文件組是否已經(jīng)被修改了的功能。如果沒有被改變，那么事務記錄是沒有什么必要的。但是，總的來說，還是需要事務記錄備份的，如果你現(xiàn)在還沒有一個備份事務記錄的恢復或者備份計劃，那么現(xiàn)在就創(chuàng)建一個吧。

在要恢復的文件或者文件組中的表格與數(shù)據(jù)庫中其他的表格之間的數(shù)據(jù)不一致性成為需要考慮的一個問題。如果你有相互之間依賴的表格，并且這些表格沒有被存儲在相同的物理文件或者文件組中(這有時是不可避免的)，僅僅恢復一個文件或者文件組可能會導致它與數(shù)據(jù)庫其他部分不同步。例如，你有一個表格被另一個表格用JOIN關聯(lián)，并且這個JOIN使用了一個視圖和存儲過程，這時僅僅恢復一個而不恢復另一個可能會有問題。

當你在數(shù)據(jù)庫中只有一個文件組。如果你的所有的數(shù)據(jù)僅僅存儲在一個文件或者文件組中，并且它又不是一個特別大的數(shù)據(jù)庫時，會發(fā)生什么事情呢?那時恢復一個文件或者文件組的努力就變的沒有什么意義了。

選擇性的恢復文件或者文件組的主要原因是當恢復數(shù)據(jù)庫很大，以至于恢復整個數(shù)據(jù)庫的代價很大的時候，使得對數(shù)據(jù)庫的局部損壞的恢復成為可能。在一個非常小的輕量級的數(shù)據(jù)庫里，和nonproduction系統(tǒng)中，或者數(shù)據(jù)庫中只有一個文件組的時候，實現(xiàn)選擇性的恢復功能就顯的沒有太大的意義，因為這時恢復整個數(shù)據(jù)庫和恢復單個的文件或者文件組沒有什么太大的區(qū)別。

我發(fā)現(xiàn)大多數(shù)時候當人們想使用文件或者文件組恢復時，他們實際上是想把一個特定的表格恢復到先前的一個點的時刻的狀態(tài)。這在SQL Server中不是一個顯式支特的特性，但是存在這么做的方法，倘若你不介意由于采用這種方法而需要手工的來管理可能產(chǎn)生的不一致(就想上面#2所說的)。如果你手邊就有一個數(shù)據(jù)庫備份的話，你可以簡單的恢復那個備份，僅僅把它看作是相同數(shù)據(jù)庫的不同名字的實例。接著，通過事務記錄把數(shù)據(jù)庫向前滾動到指定的點(如果需要這樣做的話)，然后手工的把當前的數(shù)據(jù)庫拷貝到目標數(shù)據(jù)庫中。

我自己已經(jīng)實驗過這種方法幾次，但是僅僅只有一個表格沒有與相同數(shù)據(jù)庫中的其他的表格有很大的關聯(lián)。我的例子涉及了一個包含了留言版系統(tǒng)的聊天網(wǎng)站。我不得不經(jīng)常恢復一些在留言版上被意外刪除的消息，這些是自包含的：從留言版表格的數(shù)據(jù)產(chǎn)生的唯一的JOINs是外部的而不是內部的。因此，我可以隨意的更新表格因為我知道我不會讓那個表格與其他表格不同步的。

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