解读选择是否恢复整个SQL Server的方法_Mssql数据库教程

推荐：浅析管理SQL Server数据库和应用元数据
问题 我常被问到如何把驻留在物理服务器/SQL 实例上的数据库转变为它们相应的应用程序名称。在准备计划好的服务器停机通知时，这种需要就产生了，但在我的组织内与IT经理或非技术

这有一个具体例子：如果你有一个单个的出现问题的文件。这个文件有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子句，从而使仅仅需要的文件组数据被恢复。这作为一个时间和空间上的节约开销的措施是非常有用的：你不需要进行繁重的恢复所有数据的工作，而仅仅只需要对一个表格进行操作。而且很可能也没有足够的空间来进行完全的恢复操作。

分享：浅析SQL Server 2008中不推荐及不支持的功能
每个人都在等着Microsoft SQL Server 2008的新功能出现，不过我们首先应该知道有哪些“不推荐(deprecated)”以及“不支持(Discontinued)”的功能。“不推荐