當微軟發布SQL Server2005時，它通過引入分區極大擴展了利用文件組的功能。另外，我們現在可以 用SQL Server2005引擎做在線數據庫恢復。所以有了所有這些可用的功能，你應該怎麼優化你的文件組用 於備份和恢復?讓我們來看看文件組和當他們使用的時候是怎樣建立備份和恢復策略的。
在SQL Server2005中文件和文件組是怎樣工作的?每一個數據庫都是由文件組組成的。你的數據庫可以 由幾個文件組組成，它們允許你分離數據。你可以選擇將主要做讀操作的表和主要做寫操作的表分離，或 者選擇將表和他們的非聚簇索引分離。你還可以用表分區來分離數據。
文件組的用途逐項說有幾百個。文件組是由磁盤上的一個或多個物理文件組成的。為什麼你會在一個 文件組裡有多個文件呢?盡管有許多理由，例如一個完全的硬盤，要有多個文件;要理解的重要核心原因是 數據庫由文件組組成而文件組由文件組成。
你怎麼使用文件組將很大程度上取決於我們正在討論的數據庫。文件組可以嚴格用於恢復性原因或你 可以用它們提高數據庫性能。不過有時你因為較差的容量規劃或無法預料的發展而終止於文件組或多個文 件。無論你是因為什麼而采用文件組的，都要了解它們是怎麼影響你的備份和恢復數據庫的能力。
在SQL Server中文件組備份
當備份一個數據庫時，一個選擇是備份一個文件組而不是整個數據庫。這對於大型數據庫特別有用。 一個大型數據庫，取決於硬件，大概500GB，備份會花費幾個小時。事實上，我曾看過一個系統花費四到 五個小時去備份一個那麼大的數據庫。備份花費資源，並且可能並不值得每天晚上花五小時做完全備份工 作。
這個問題有幾種解決方案。我曾見過設定每周做一次完全備份，一系列事務日志和一整個星期執行的 差異備份。這樣可行，但是你每個星期將仍然需要一個長時間的單獨窗口來做完全備份。
如果你將數據庫分解為大小都差不多的七個文件組來替代， 那會怎麼樣呢?在那種情況下，它們都是 72GB左右大小，並且你將每天晚上備份一個文件組。這會將原來很長的完全的備份縮短為七個較短的文件 組的備份，並經過一個星期你將完成整個數據庫的備份。我曾經用過一些包含海量數據的數據庫，其相當 大的一部分是只讀的。
依據遵從性檢查的要求，像Sarbanes-Oxley，一個大型的金融數據庫大小可能為600GB或700GB，但經 常大部分是回溯到七年或更久以前的歷史數據。如果你有這樣的數據庫並且只有20%的數據有規律地改變 ，那你可能可以通過利用文件組來提高效率。把規律變化的表放到你的主要文件組裡，把歷史的或存檔表 放到一個存檔文件組裡。現在你可以每天備份主要文件組，或許一個星期或一個月備份一次存檔文件組。
在SQL Server中文件組恢復
文件組恢復提供了一些額外的復雜性，尤其是在SQL Server 2005中。如果一個單獨的文件壞掉了，你 可以恢復一個文件或文件組到一個數據庫中去。使用更大型的數據庫允許更高的復雜性。假設你的文件在 不同的分區上，一個單獨的分區壞掉了不是必須要整個數據庫做恢復。當你從失敗中恢復時這可以節省寶 貴的時間。
大型數據庫會花很長的時間恢復——就像備份一樣——但具有多個文件組使你 能縮短它花費的時間。另外，SQL Server 2005引入了在線恢復。這裡要注意的是，數據庫將在線一次恢 復一個文件組。換句話說，你首先恢復主要文件組，當繼續恢復其他文件組時用戶可以訪問這個文件組裡 的數據。
隨著每一個文件組的恢復完成，這個文件組的數據就對終端用戶可用。這確實要求管理員方面要具有 仔細的計劃。你要確保關鍵數據先被恢復，存檔和不常訪問的數據後恢復。要恰當的做到這一點，你必須 對你的數據庫和它是怎麼被使用的有很好的了解。
我所要說的話可能會令一些數據庫管理員敬而遠之，但是你必須花些時間和開發要訪問這個數據庫的 應用的人員討論。你需要了解什麼數據是關鍵的和什麼數據可以晚些提供在線。一旦你完全了解了，你就 可以開發一個能夠很好的在線備份的文件組策略。
文件組計劃
當做文件組計劃時，它的可復原性就像它的性能一樣多。確保考慮了備份和恢復你的數據庫的需求。 不要進入到一種情況，就是為一錯誤的原因采用文件組，並且確保避免文件組結構阻礙你備份和恢復的能 力。另一個普遍錯誤是采用太多的文件組。如果你以錯誤的方式分離數據，實際上性能會降低。所以牢記 當你做恢復計劃時要考慮性能。
避免工作於幻想之中，當與數據庫打交道時這會是雙倍的。太多不同的過程和應用可以訪問數據庫。 甚至其他數據庫也可以依賴於你的數據庫。一個只優化備份和恢復而不考慮性能的計劃不是一個好計劃， 反之亦然。在你進入執行階段之前要了解總體情況;並利用額外的時間預先防止之後出現重大問題。我不 是在建議你跑去把你所有的數據庫劃分為多個文件或文件組，但是確實有地方和時間應該使用他們。
