SQL Server 段落还原

　　在我们的例子中，假定我们有一个数据仓库记录了从1996年直到现在每年产生的销售数据业务。我们进一步假设，除了当年的那部分销售数据，其他所有的历史销售数据都存储在“历史”文件组。历史数据是静态的：我们不会改变那个文件组中的任何记录。作为笃信地坚持最佳实践的优秀数据库管理员，我们已经把所有用户定义对象放到了此文件组，不在主文件组中。因为“历史”文件组的数据从不变化，我们只需要一个月对它备份一次。“当前”文件组存储当年的销售数据，每天备份一次。

　　在一个晴朗的早晨，我们接到运营部门的电话：数据库宕机了。我们的服务器出现了某些硬件问题，我们需要把数据库恢复到另一台服务器上。“当前”文件组和“主”文件组相对较小，可以在一个小时内恢复。“历史”文件组需要花很多个小时才能恢复。幸运的是，我们的用户主要关心当前业务，只是偶尔才查看历史数据。所以我们决定使用段落还原功能，使数据库对用户尽快可用。

　　假定我们已经用下面的语句建立了我们的新数据仓库：

　　既然不允许对历史文件组更新数据，我们就用下面的命令把它标记为只读。

　　ALTER DATABASE [TeraWarehouse] MODIFY FILEGROUP [History] READONLY

　　我们假定之前已经创建了如下备份：

　　1. 硬件故障前一天晚上执行的主文件组和当前文件组备份: BACKUP DATABASE TeraWarehouse

　　历史文件组是在当月初备份的。使用的语句如下：

　　2. 当晚之前执行的事务日志备份，第二天早上硬件出的故障：

　　因为我们的数据库宿主于一个数据仓库，我们只是在每一数据加载之后执行事务日志备份。除了数据传输和加载，不允许有其他事务。我们每八个小时从事务源加载一次数据。

　　我们在早上六点十分接到了运营部门打来的这个光荣的电话，需要尽快使当前数据联机可用。我们将按如下步骤操作：

　　首先恢复主文件组;注意我们使用“PARTIAL”关键字来告诉SQL Server数据库我们不是要恢复所有文件组。

　　接下来我们来还原当前文件组。在这个命令执行以后，数据库仍然没有完全恢复(或可用)，因为我们仍然需要恢复事务日志。如果用户试图在这时候查询数据库，他们将会遇到数据库错误“数据库正在恢复过程中”。下面是还原当前文件组的命令：

　　按照日志创建的顺序恢复事务日志备份 。最后，事务日志备份将使用“WITH RECOVERY”选项恢复：

　　此时数据库处于联机状态，用户可以恢复查询操作了，尽管历史文件组还没有被还原。但是，好的，任务也算完成了，至少部分完成了。如果用户试图查询历史文件组中的对象，他们会得到如下错误信息：

　　查询处理器不能给表‘my_old_fact’生成执行计划，因为文件组中的表不是联机状态。

　　在稍后的时间段，可能在有限的用户在活动的时候，我们可以继续进行，恢复脱机文件组。命令如下：

　　一旦这一恢复命令成功执行，用户就可以查询所有数据了(包括历史数据和当前数据)。

　　总结

　　在本文中，我论述了段落还原方案，它对于企业级的数据库非常有用，特别是对于那些只读历史数据被从多少有点操作频繁的当前数据中分离的数据仓库。熟悉这一功能会给你自己帮大忙的：它可能有一天会保住你的工作。