恢复整个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子句，从而使仅仅需要的文档组数据被恢复。这作为一个时间和空间上的节约开销的措施是很有用的：您无需进行繁重的恢复任何数据的工作，而仅仅只需要对一个表格进行操作。而且很可能也没有足够的空间来进行完全的恢复操作。

　　TechTarget独家授权文章，严禁转载

　　查看本文国际来源 >>

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有