TSQL-28-数据库故障还原模型[2009-10-26].doc

茂名先锋商用设备有限公司 - 技术资料汇编 文档类别：内部第28讲 数据库故障还原模型在“用EM备份数据库”讲义的开头，我要求大家确保PPOS数据库选项中的“故障还原模型”为“完全”，这个称为“故障还原模型”的数据库选项有什么作用？本讲就讲这个问题。一、 不同用户对数据安全的重视程度不一样1、 不紧张的用户：他们定期备份一下数据库，如果某天数据库突然损坏了，他们就还原最近的备份集，然后，手工补回其后的工作就可以。这种用户一般数据量不大，数据内容也不是非常重要。2、 很紧张的用户：他们的数据事关重大（如：在线订货系统、交易管理系统等），如果发生数据库突然损坏，必须要有办法复原至尽可能少的损失，“手工补录”几乎是不现实的。从上面可以看出，不同的用户对数据库的“故障还原”有不同的需求，一些用户（如第1类）希望“减轻维护成本和工作量，即使存在一些风险也关系不大”；另一些用户（如第2类）则希望“必须要有足够的能力来尽可能确保数据不受损，即使多花精力、多花金钱也在所不惜”。这就是“数据库故障还原模型”的用途：使得不同的用户可以选择合适自己需要的模型。二、 SQL2000的三种“故障还原模型”在数据库属性的“选项”页，“故障还原模型”栏，共有三项选择：简单、完全、大容量日志记录。它们的根本差别在于SQL2000对数据库日志的维护方式不同。下面逐个讲述：1、 “完全”模型我们都想象得出，如果需要实现“时点还原”，则SQL2000必须将所有的事务记录无一遗漏地保存下来，成为一条不中断的链。在日志文件中，每一条事务记录都被编了号（称“LSN”），号码是连续的。在“完全”模型下，SQL2000对事务日志进行最严格、最彻底的管理。中心原理就是：如果你不备份事务日志，则日志文件将永远不会自行删除掉任何历史事务记录（结果将是文件无限增长）。当你备份日志文件（即“BACKUP LOG”）时，SQL2000会记下哪些LSN已经备份好了，下次再备份日志时，这些LSN不会重复出现在下一个事务日志备份集。而且，每次进行日志备份时，除非你指明“不要删除事务日志中不活动的条目”，则SQL2000一旦觉得时机合适，都会随时删除掉没有用了的历史记录（称为“截断事务日志”）。下图1是事务日志备份前的样子：活动部分（尚未提交或未写盘的修改）可用的日志文件空间非活动部分（已提交且数据文件更改已写盘）假设这时进行事务日志备份。SQL2000将“非活动部分”和“活动部分”都写入备份集内。备份好后，SQL2000有可能对日志文件进行截断。截断后，日志文件变成下图2的样子：可用的日志文件空间活动部分（尚未提交或未写盘的修改）非活动部分因截断而变为可用的空间截断日志时，不一定正好“截齐”非活动部分（SQL2000有它的习惯，不细讲），但是，它绝对不会截断活动部分。“因截断而变为可用的空间”有何意义？可以用于写以后的日志记录。可见，及时地进行日志文件备份是很有必要的，不但是数据安全的需要，也是防止日志文件无限增长（导致浪费磁盘空间、降低系统性能）的需要。如果先对数据库进行一次“完全备份”（即“打底备份”），然后，再连续对日志文件进行备份，所得的一连串有序的“日志文件备份集”将构成一条完整的“日志链”。只要取来“打底备份集”，结合这条“日志链”，我们就可以将数据库复原至日志链中任一时间点的状态。做到这点，作为DBA可以松一大口气了。再强调一下： 在“完全”模型下，只有“事务日志备份”才会导致日志文件被截断，“数据库完全备份”或“数据库差异备份”并不会截断日志。 一条日志链中，如果你不小心丢失了中间一个日志备份集，则整条链就废了（或者至少，从丢失处起后面的备份集废了），你必须重新“打底”起过头。所以，通常应连续追加入同一媒体集，不要每次备份生成一个文件，零散文件是不好管理的（严格来说，这是个人喜好问题）。2、 “简单”模型如果你为数据库选择了“简单”恢复模型，则SQL2000在记录事务日志时，对于日志中的“非活动部分”将随时截断（使之变为“可用空间”）。截断日志时，日志文件大小并不改变（除非你收缩数据库）。这里所说的“随时截断”是SQL2000自己抓主意的，并不需要通知你。原理如下：图3，新建立的日志文件，里面全部是可用空间：图4，数据库运作后，日志中有了一些事务记录，“活动部分”（浅灰）表示正在处理中的事务记录：活动部分图5，日志继续增加。其中，“非活动部分”（深灰）表示已完成且已写盘（数据文件写盘）的事务：非活动部分活动部分图6，日志记录继续增加。这时，SQL2000截断前面的非活动部分：因截断原非活动部分而来的可用空间新的非活动部分活动部分图7，日志记录继续增加。这时，活动部分到达日志文件尾：非活动部分活动部分图8，日志继续增加，但日志文件并不需要增长，因为活动部分可以“绕回去”利用文件前头的空间：非活动部分活动部分头活动部分尾图9，SQL2000再次截断非活动部分：非活动部分因截断原非活动部分而来的可用空间活动部分非活动部分从上面图3至图9可见，SQL2000对待日志文件是“蛇咬尾”式的。在“简单”模型下，日志的非活动部分随时被截断。这种模式的优点是“即使你不管理日志文件，它也不会增长得太大，不会占用太多硬盘”，缺点是“无法维护日志链”（原因是它里面的记录无连续保持性）。值得注意的一点：即使你将恢复模型设为“完全”，但如果该数据库从未进行过“完全备份”，则SQL2000也像“简单”模型那样维护它的日志。原因：你都未作“打底”备份，留那么多日志记录给你也是白废。3、 大容量日志记录（也称为“批日志”）“批日志”模型是对“完全”模型的一个补充，在某些特殊的情况下，使用“批日志”模型，能够提高SQL2000的性能（即“速度”），但它并不是必须的，即使永远不用“批日志”模型，也能工作得很好。SQL2000向表中插入数据时，通常每次只插入一行，而且总是先登记日志记录，然后插入。但是，SQL2000也提供了“批插入”语句，即是：一个语句就向表中插入成千上万行（如：INSERTSELECT语句），这种操作称为“批操作”。批操作时，SQL2000怎样进行日志记录呢？在“完全”模型下，它对每一行插入都作记录，其结果是日志量会很大；在“批日志”模型下，它只简单地标记一下哪些数据区域被“批操作”影响了（这张记录表称为“位映射表”），而并不将这些数据抄写入日志文件中，这样，日志量就大大减少。在“批日志”模型下备份日志时，SQL2000不但要将日志文件内容写入备份集，特殊之处在于，它还需要按“位映射表”将当前数据库中的内容复制入日志备份集中：凡是自上一次日志备份以来，被“批操作”影响了的“数据区域”，都要原样抄入。要不然，当需要还原时，靠什么来还原数据呢？（自己想通）。明白了上述“批日志”的本质，我们就能理解以下现象：在“批日志”模型下，假设有一个批操作（向表中一次过插入10000行），在进行到中途（已经插入了4800行）时，硬盘损坏，数据文件没有了。这时，我们利用日志文件无法复原回到“已插入4800行”的状态。原因很简单：日志中没有插入的数据。有鉴于此，我们应该怎样对待批操作呢？一是不要改为“批日志”模型，保留“完全”模型来运作，慢就慢些（因为要记录大量日志），咬紧牙关做。二是临时改为“批日志”模型，具体步骤如下： 在开始“批操作”（例如，大量导入基础资料）前，让所有其他用户退出连接； 进行一次日志备份（为方便说明，所得日志备份集称为“日志备份集A”）； 将“故障还原模型”改为“批日志”模型； 开始执行“批操作”。 若一切顺利（中间磁盘没有坏），则完成批操作后，即时改回“完全”模型，再进行一次日志备份。 如果第步中，批操作进行了一半，磁盘坏了，则利用“日志备份集A”复原，使数据库完全回