第10章补充.ppt

§10.4 拓展一 以后备副本和运行记录（LOG）为基础的恢复技术 运行记录的内容： 前像BI：物理块，Undo； 后像AI：物理块，Redo； 事务状态： 事务状态： 每个事务从交付DBMS到结束为止，状态变迁如上图。 每个事务有两种可能的结局： 一是提交（commit）而结束，这标志着事务已成功的执行，只有事务提交后，事务对数据库的更新才能被其它事务访问； 二是由于事务本身或外部的原因，事务失败，要消除事务对数据库的影响。对事务这种处理称为卷回。对恢复来说，不必记下上图的每个状态，但至少要区分出一个事务是提交，还是未提交的。 当数据库失效时，可取出最近的后备副本，然后根据LOG，对未提交的事务用前像卷回【即向后恢复】，对已提交的事务，必要时用后像重做【即向前恢复】。 这种恢复技术，必须有运行记录，既花费较大的存储空间，又影响数据库正常工作的性能。但能使数据库恢复到最近的一致性状态，应用广泛。 以后备副本和运行记录（LOG）为基础的恢复技术 运行记录的结构： 活动事务列表（ATL）：所有正在执行，尚未提交的事务的标识符（TID）。 提交事务列表（CTL）：所有已提交的事务的标识符（TID）。在提交时，先将要提交的TID列入CTL，然后再从ATL中删除该TID。【顺序不可颠倒】 前像文件：一个堆文件，每个物理块有个块标识符（BID）BID中包含TID、关系名、逻辑块号，TID表示执行更新的事务，关系名表示被更新的关系，逻辑块号表示该块是关系中哪块的前像，具有唯一性，即使被删除了，该块号也不允许重复使用。 卷回：从前像文件中找出该事务的所有前像块，按逻辑块号写入关系的对应块中。 Undo操作满足幂等性：undo（undo（undo…（x）））=undo（x）因此，即使数据库中某块还没有来得及更新，在恢复时对它做一次undo操作也无妨。 后像文件：与前像文件相仿，记录的是后像。恢复时，可以按提交事务列表中的事务次序，按逻辑块号写入其后像。相当于按提交的次序，重做各个事务。 Redo操作满足幂等性：redo（redo（redo…（x）））=redo（x）因此，即使数据库中某块没有丢失，在恢复时对它做一次redo操作也无妨。 运行记录是累积的，很费存储空间。取后备副本后，以前的运行记录就失去价值。对恢复而言，只要保存最近后备副本以后的运行记录。即使如此，对大数据库来说，运行记录还是很可观的。为此，可采取如下措施： 不保留已提交事务的前像；对于已提交的事务，只会redo，不会undo，故其前像可不保留。 有选择性的保留后像；当更新的内容写入数据库后，只要磁盘不出故障，后像可以不再保留。由于磁盘发生故障的概率较小，且并非所有数据在发生故障时都要求恢复到最近的一致状态；有些DBMS中，允许用户作出是否保留后像的选择。 合并后像对于给定逻辑号的物理块，如果多次更新，只要保留最近的后像即可。 §10.5 拓展二——更新事务的执行与恢复 更新事务在执行时应遵守下列2条规则： 提交规则；后像必须在事务提交前写入非易失存储器中，即写入数据库或运行记录。根据ACID特性，提交的事务对数据库所产生的影响应是持久的，后像只有写入非易失存储器中，才能保证持久性。但提交规则并不要求后像一定要在事务提交前写入数据库。若后像已写入运行记录，即使还没 或未完全写入数据库，事务仍可提交。待事务提交后，再继续写入数据库。在此期间，若发生故障，可用运行记录的后像重做；若有其它事务访问这些数据，由于更新的内容在未写入数据库前，仍在缓冲块中，其它事务可从缓冲块中访问更新后的内容。 更新事务在执行时应遵守下列2条规则： 先记后写规则；若后像在事务提交前写入数据库，则必须把前像首先记入运行记录。事务在提交前，都有可能失败。事务失败后，须先撤销事务对数据库所做的一切更新。为此，必须在改动数据库前，先把前像记入运行记录。也就是先“留老底”，再写入新内容。 在执行更新事务时，按后像写入数据库的时间不同，有3种可能的方案，讨论如下： 后像在事务提交前完全写入数据库 步骤如下：[AI：后像；BI：前像] ⑴ TID→ATL ⑵ BI→LOG /*先记后写规则*/ ⑶ AI→DB /*在提交前，后像完全写入数据库，满足提交规则*/ ⑷ TID→CTL ⑸ 从ATL删除TID 当事务执行过程中发生故障，可以根据ATL和CTL中是否 有该事务的TID，采取不同的恢复措施，具体见下表。 后像在事务提交后才写入数据库 步骤如下：[AI：后像；BI：前像] ⑴ TID→ATL ⑵ AI→LOG /*提交规则*/ ⑶ TID→CTL ⑷ AI →DB ⑸ 从ATL删除TID 因为后像在事务提交前未写入数据库，根据先记后写原