SQL2000的三种“故障还原模型”

一、SQL2000的三种“故障还原模型”

在数据库属性的“选项”页，“故障还原模型”栏，共有三项选择：简单、完全、大容量日志记录。它们的根本差别在于SQL2000对数据库日志的维护方式不同。下面逐个讲述：

1、“完全”模型

我们都想象得出，如果需要实现“时点还原”，则SQL2000必须将所有的事务记录无一遗漏地保存下来，成为一条不中断的链。在日志文件中，每一条事务记录都被编了号（称“LSN”），号码是连续的。

在“完全”模型下，SQL2000对事务日志进行最严格、最彻底的管理。中心原理就是：如果你不备份事务日志，则日志文件将永远不会自行删除掉任何历史事务记录（结果将是文件无限增长）。

当你备份日志文件（即“BACKUP LOG”）时，SQL2000会记下哪些LSN已经备份好了，下次再备份日志时，这些LSN不会重复出现在下一个事务日志备份集。而且，每次进行日志备份时，除非你指明“不要删除事务日志中不活动的条目”，则SQL2000一旦觉得时机合适，都会随时删除掉没有用了的历史记录（称为“截断事务日志”）。

可见，及时地进行日志文件备份是很有必要的，不但是数据安全的需要，也是防止日志文件无限增长（导致浪费磁盘空间、降低系统性能）的需要。

如果先对数据库进行一次“完全备份”（即“打底备份”），然后，再连续对日志文件进行备份，所得的一连串有序的“日志文件备份集”将构成一条完整的“日志链”。只要取来“打底备份集”，结合这条“日志链”，我们就可以将数据库复原至日志链中任一时间点的状态。做到这点，作为DBA可以松一大口气了。

再强调一下：

①  在“完全”模型下，只有“事务日志备份”才会导致日志文件被截断，“数据库完全备份”或“数据库差异备份”并不会截断日志。

②  一条日志链中，如果你不小心丢失了中间一个日志备份集，则整条链就废了（或者至少，从丢失处起后面的备份集废了），你必须重新“打底”起过头。所以，通常应连续追加入同一媒体集，不要每次备份生成一个文件，零散文件是不好管理的（严格来说，这是个人喜好问题）。

2、“简单”模型

如果你为数据库选择了“简单”恢复模型，则SQL2000在记录事务日志时，对于日志中的“非活动部分”将随时截断（使之变为“可用空间”）。截断日志时，日志文件大小并不改变（除非你收缩数据库）。这里所说的“随时截断”是SQL2000自己抓主意的，并不需要通知你。

在“简单”模型下，日志的非活动部分随时被截断。这种模式的优点是“即使你不管理日志文件，它也不会增长得太大，不会占用太多硬盘”，缺点是“无法维护日志链”（原因是它里面的记录无连续保持性）。

值得注意的一点：即使你将恢复模型设为“完全”，但如果该数据库从未进行过“完全备份”，则SQL2000也像“简单”模型那样维护它的日志。原因：你都未作“打底”备份，留那么多日志记录给你也是白废。

3、大容量日志记录（也称为“批日志”）

“批日志”模型是对“完全”模型的一个补充，在某些特殊的情况下，使用“批日志”模型，能够提高SQL2000的性能（即“速度”），但它并不是必须的，即使永远不用“批日志”模型，也能工作得很好。

SQL2000向表中插入数据时，通常每次只插入一行，而且总是先登记日志记录，然后插入。但是，SQL2000也提供了“批插入”语句，即是：一个语句就向表中插入成千上万行（如：INSERT…SELECT语句），这种操作称为“批操作”。批操作时，SQL2000怎样进行日志记录呢？在“完全”模型下，它对每一行插入都作记录，其结果是日志量会很大；在“批日志”模型下，它只简单地标记一下哪些数据区域被“批操作”影响了（这张记录表称为“位映射表”），而并不将这些数据抄写入日志文件中，这样，日志量就大大减少。

在“批日志”模型下备份日志时，SQL2000不但要将日志文件内容写入备份集，特殊之处在于，它还需要按“位映射表”将当前数据库中的内容复制入日志备份集中：凡是自上一次日志备份以来，被“批操作”影响了的“数据区域”，都要原样抄入。要不然，当需要还原时，靠什么来还原数据呢？（自己想通）。

明白了上述“批日志”的本质，我们就能理解以下现象：在“批日志”模型下，假设有一个批操作（向表中一次过插入10000行），在进行到中途（已经插入了4800行）时，硬盘损坏，数据文件没有了。这时，我们利用日志文件无法复原回到“已插入4800行”的状态。原因很简单：日志中没有插入的数据。

有鉴于此，我们应该怎样对待批操作呢？一是不要改为“批日志”模型，保留“完全”模型来运作，慢就慢些（因为要记录大量日志），咬紧牙关做。二是临时改为“批日志”模型，具体步骤如下：

①  在开始“批操作”（例如，大量导入基础资料）前，让所有其他用户退出连接；

②  进行一次日志备份（为方便说明，所得日志备份集称为“日志备份集A”）；

③  将“故障还原模型”改为“批日志”模型；

④  开始执行“批操作”。

⑤  若一切顺利（中间磁盘没有坏），则完成批操作后，即时改回“完全”模型，再进行一次日志备份。

⑥  如果第④步中，批操作进行了一半，磁盘坏了，则利用“日志备份集A”复原，使数据库完全回复到批操作开始前的状态，然后，再重新开始“批操作”。

无论如何，批操作结束后，千万别忘记撤换回“完全”模型。

其实，在我看来，无论你是否打算临时改用“批日志”模型，在“大规模导入数据”这种操作前，进行一次日志备份都是很有必要的，至少，有机会回头。

<来自转贴 ^_^>