当微软发布SQL Server2005时，它通过引入分区极大扩展了利用文件组的功能。另外，我们现在可以用SQL Server2005引擎做在线数据库恢复。所以有了所有这些可用的功能，你应该怎么优化你的文件组用于备份和恢复?让我们来看看文件组和当他们使用的时候是怎样建立备份和恢复策略的。

　　在SQL Server2005中文件和文件组是怎样工作的?每一个数据库都是由文件组组成的。你的数据库可以由几个文件组组成，它们允许你分离数据。你可以选择将主要做读操作的表和主要做写操作的表分离，或者选择将表和他们的非聚簇索引分离。你还可以用表分区来分离数据。

　　文件组的用途逐项说有几百个。文件组是由磁盘上的一个或多个物理文件组成的。为什么你会在一个文件组里有多个文件呢?尽管有许多理由，例如一个完全的硬盘，要有多个文件;要理解的重要核心原因是数据库由文件组组成而文件组由文件组成。

　　你怎么使用文件组将很大程度上取决于我们正在讨论的数据库。文件组可以严格用于恢复性原因或你可以用它们提高数据库性能。不过有时你因为较差的容量规划或无法预料的发展而终止于文件组或多个文件。无论你是因为什么而采用文件组的，都要了解它们是怎么影响你的备份和恢复数据库的能力。

　　在SQL Server中文件组备份

　　当备份一个数据库时，一个选择是备份一个文件组而不是整个数据库。这对于大型数据库特别有用。一个大型数据库，取决于硬件，大概500GB，备份会花费几个小时。事实上，我曾看过一个系统花费四到五个小时去备份一个那么大的数据库。备份花费资源，并且可能并不值得每天晚上花五小时做完全备份工作。

　　这个问题有几种解决方案。我曾见过设定每周做一次完全备份，一系列事务日志和一整个星期执行的差异备份。这样可行，但是你每个星期将仍然需要一个长时间的单独窗口来做完全备份。

　　如果你将数据库分解为大小都差不多的七个文件组来替代， 那会怎么样呢?在那种情况下，它们都是72GB左右大小，并且你将每天晚上备份一个文件组。这会将原来很长的完全的备份缩短为七个较短的文件组的备份，并经过一个星期你将完成整个数据库的备份。我曾经用过一些包含海量数据的数据库，其相当大的一部分是只读的。

　　依据遵从性检查的要求，像Sarbanes-Oxley，一个大型的金融数据库大小可能为600GB或700GB，但经常大部分是回溯到七年或更久以前的历史数据。如果你有这样的数据库并且只有20%的数据有规律地改变，那你可能可以通过利用文件组来提高效率。把规律变化的表放到你的主要文件组里，把历史的或存档表放到一个存档文件组里。现在你可以每天备份主要文件组，或许一个星期或一个月备份一次存档文件组。

　　在SQL Server中文件组恢复

　　文件组恢复提供了一些额外的复杂性，尤其是在SQL Server 2005中。如果一个单独的文件坏掉了，你可以恢复一个文件或文件组到一个数据库中去。使用更大型的数据库允许更高的复杂性。假设你的文件在不同的分区上，一个单独的分区坏掉了不是必须要整个数据库做恢复。当你从失败中恢复时这可以节省宝贵的时间。

　　大型数据库会花很长的时间恢复——就像备份一样——但具有多个文件组使你能缩短它花费的时间。另外，SQL Server 2005引入了在线恢复。这里要注意的是，数据库将在线一次恢复一个文件组。换句话说，你首先恢复主要文件组，当继续恢复其他文件组时用户可以访问这个文件组里的数据。

　　随着每一个文件组的恢复完成，这个文件组的数据就对终端用户可用。这确实要求管理员方面要具有仔细的计划。你要确保关键数据先被恢复，存档和不常访问的数据后恢复。要恰当的做到这一点，你必须对你的数据库和它是怎么被使用的有很好的了解。

　　我所要说的话可能会令一些数据库管理员敬而远之，但是你必须花些时间和开发要访问这个数据库的应用的人员讨论。你需要了解什么数据是关键的和什么数据可以晚些提供在线。一旦你完全了解了，你就可以开发一个能够很好的在线备份的文件组策略。

　　文件组计划

　　当做文件组计划时，它的可复原性就像它的性能一样多。确保考虑了备份和恢复你的数据库的需求。不要进入到一种情况，就是为一错误的原因采用文件组，并且确保避免文件组结构阻碍你备份和恢复的能力。另一个普遍错误是采用太多的文件组。如果你以错误的方式分离数据，实际上性能会降低。所以牢记当你做恢复计划时要考虑性能。

　　避免工作于幻想之中，当与数据库打交道时这会是双倍的。太多不同的过程和应用可以访问数据库。甚至其他数据库也可以依赖于你的数据库。一个只优化备份和恢复而不考虑性能的计划不是一个好计划，反之亦然。在你进入执行阶段之前要了解总体情况;并利用额外的时间预先防止之后出现重大问题。我不是在建议你跑去把你所有的数据库划分为多个文件或文件组，但是确实有地方和时间应该使用他们。