add

Author: kingshaohua

aries_10.md

@@ -17,4 +17,9 @@
 调换选择redo和undo遍历的顺序同样也没法解决此问题。【3】中提出的是一种错误的方案。如果undo遍历先于redo遍历，那么我们就会丢失对那些需要redo动作的跟踪。在图15中，20的undo使得页LSN大于30，因为，CLR的输出，是的该CLR的LSN设置为该页的CLR。由于在redo遍历期间，只有当页LSN小于日志的LSN时，该日志才会redo，我们不能redo30，即使之前对该页没有做更新。不做redo会影响事务的持久性和原子性。  
 System R 使用的影子页技术并不需要page_LSN来决定哪些需要undo，哪些需要redo。通过影子页技术，在checkpoint的时候，一种包含该数据库的连续版本的操作称为影子版本，保存在持久化存储中。两个checkpoint创建了一个新的更新页版本，继而构建了数据库的当前版本（参见图1）。在重启时，从影子版本开始恢复，并且在恢复过程中执行影子操作。因此，哪些更新以及在数据库中，哪些不在，毫不含糊。在最后一次checkpoint之后的所有更新日志都不在数据库中，在这之前的都在数据库中。这就是为什么System R使用选择redo也能正确恢复的原因。还有些其他原因：虽然索引和空间变更不记录日志，但是它们会逻辑redo或逻辑undo。  
 正如之前所说，ARIES并不使用选择redo，而是使用历史重演。除了可以支持低颗粒度锁，历史重演还有其他优势。它可以使我们提交事务中的一些操作，不管这个事务最后有没有提交，第9节有详细描述。  
+**10.2 Rollback State回滚状态**  
+本节的目标是讨论回滚中跟踪其步骤的难点以及如何使用CLR来描述回滚中的更新操作，继而解决一些问题。虽然CLR已经应用到很多系统中，也存在了很长时间，但是还没有哪篇文章着重讨论过CLR：使用它们的问题与优势。它们在数据库恢复中所扮演的角色仍没得到研究社区的关注。undo操作是否需要undo以及一些其他的问题会在【56】做为开放问题。在本节中，以及在本文的其他地方，在合适的上下文中，我们会提到CLR所有已知的优势。在13节会总结CLR的这些优点。  
+事务可能会因为很多原因进行全部或部分回滚。比如：违反唯一性约束只会导致违规的这条操作回滚而不影响整个事务。图3描绘了一种部分回退。对于部分回退的支持【1,31】，至少在内部支持，如果不是在应用层支持，对于当今的现有的事务系统也是一个很重要的需求。当系统崩溃时，某个事务正在回滚，并且回滚的一些操作已经写到持久化存储上，因此，我们需要使用一种方式来跟踪事务回滚的状态。这对System R系统相对比较简单。在System R中我们唯一需要关心事务状态的时刻是在执行checkpoint的时候。所以System R中的checkpoint记录了每个活动事务的下一个待undo的记录，一些事务可能正在回滚。在系统崩溃时，事务的回滚状态并不重要，因为在重启时，从最近一次checkpoint开始的数据库变更并'不可见'。也就是说，重启恢复是从系统崩溃前的最后一次checkpoint开始---这个是系统崩溃时的影子版本。除此之外，因为没有写CLR，System R需要执行一些特殊流程来处理那些已经提交的或在in-doubt态的事务，这些事务在最近一次checkpoint之后初始化的或者完成了部分回退的。这种特殊处理是为了避免在redo遍历的时候对日志进行多次遍历。设计者们通过向后扫描来避免一种情况：redo一些操作，不久之后又undo这些操作，比如部分回退操作。 
+![](./img/fig17.png)  
+![](./img/fig18.png)