面，叫作Compensation Log Record（CLR），会和正常操作的SQL的Log区分开。
**3．ARIES恢复算法**
如图6-14所示，有T0～T5共6个事务，每个事务所在的线段代表了在Redo Log中的起始和终止位置。发生宕机时，T0、T1、T2已经完成，T3、T4、T5还在进行中，所以回滚的时候，要回滚T3、T4、T5。
图6-14 ARIES算法示意图
ARIES算法分为三个阶段：
**（1）阶段1：分析阶段**
分析阶段，要解决两个核心问题。
第一，确定哪些数据页是脏页，为阶段2的Redo做准备。发生宕机时，虽然T0、T1、T2已经提交了，但只是Redo Log在磁盘上，其对应的数据Page是否已经刷到磁盘上不得而知。如何找出从Checkpoint到Crash之前，所有未刷盘的Page呢？
第二，确定哪些事务未提交，为阶段3的Undo做准备。未提交事务的日志也写入了Redo Log。对应到此图，就是T3、T4、T5的部分日志也在Redo Log中。如何判断出T3、T4、T5未提交，然后对其回滚呢？
这就要谈到ARIES的Checkpoint机制。Checkpoint是每隔一段时间对内存中的数据拍一个“快照”，或者说把内存中的数据“一次性”地刷到磁盘上去。但实际上这做不到！因为在把内存中所有的脏页往磁盘上刷的时候，数据库还在不断地接受客户端的请求，这些脏页一直在更新。除非把系统阻塞住，不再接受前端的请求，这时Redo Log也不再增长，然后一次性把所有的脏页刷到磁盘中，叫作Sharp Checkpoint。
Sharp Checkpoint的应用场景很狭窄，因为系统不可能停下来，所以用的更多的是Fuzzy Checkpoint，具体怎么做呢？
在内存中，维护了两个关键的表：活跃事务表（表6-10）和脏页表（表6-11）。
活跃事务表是当前所有未提交事务的集合，每个事务维护了一个关键变量lastLSN，是该事务产生的日志中最后一条日志的LSN。
表6-10 活跃事务表
脏页表是当前所有未刷到磁盘上的Page的集合（包括了已提交的事务和未提交的事务），recoveryLSN是导致该Page为脏页的最早的LSN。比如一个Page本来是clean的（内存和磁盘上数据一致），然后事务1修改了它，对应的LSN是LSN1；之后事务2、事务3又修改了它，对应的LSN分别是LSN2、LSN3，这里recoveryLSN取的就是LSN1。
表6-11 脏页表
所谓的Fuzzy Checkpoint，就是对这两个关键表做了一个Checkpoint，而不是对数据本身做Checkpoint。这点非常巧妙！因为Page本身很多、数据量大，但这两个表记录的全是ID，数据量很小，很容易备份。
所以，每一次Fuzzy Checkpoint，就把两个表的数据生成一个快照，形成一条Checkpoint日志，记入Redo Log。
基于这两个关键表，可以求取两个问题：
问题（1）：求取Crash的时候，未提交事务的集合。
以图6-14为例，在最近的一次Checkpoint 2时候，未提交事务集合是{T2，T3}，此时还没有T4、T5。从此处开始，遍历Redo Log到末尾。
在遍历的过程中，首先遇到了T2的结束标识，把T2从集合中移除，剩下{T3}；
之后遇到了事务T4的开始标识，把T4加入集合，集合变为{T3，T4}；
之后遇到了事务T5的开始标识，把T5加入集合，集合变为{T3，T4，T5}。
最终直到末尾，没有遇到{T3，T4，T5}的结束标识，所以未提交事务是{T3，T4，T5}。
图6-15展示了事务的开始标识、结束标识以及Checkpoint在Redo Log中的排列位置。其中的S表示Start transaction，事务开始的日志记录；C表示Commit，事务结束的日志记录。每隔一段时间，做一次Checkpoint，会插入一条Checkpoint日志。Checkpoint日志记录了Checkpoint时所对应的活跃事务的列表和脏页列表（脏页列表在图中未展示）。
问题（2）：求取Crash的时候，所有未刷盘的脏页集合。
假设在Checkpoint2的时候，脏页的集合是{P1，P2}。从Checkpoint开始，一直遍历到Redo Log末尾，一旦遇到Redo Log操作的是新的Page，就把它加入脏页集合，最终结果可能是{P1，P2，P3，P4}。
这里有个关键点：从Checkpoint2到Crash，这个集合会只增不减。可能P1、P2在Checkpoint之后已经不是脏页了，但把它认为是脏页也没关系，因为Redo Log是幂等的。
图6-15 事务在Redo Log上排列示意图
阶段2：进行Redo
假设最后求出来的脏页集合是{P1，P2，P3，P4，P5}。在这个集合中，可能都是真的脏页，也可能是已经刷盘了。取集合中所有脏页的recoveryLSN的最小值，得到firstLSN。从firstLSN遍历Redo Log到末尾，把每条Redo Log对应的Page全部重刷一次磁盘。
关键是如何做幂等？磁盘上的每个Page有一个关键字段——pageLSN。这个LSN记录的是这个Page刷盘时最后一次修改它的日志对应的LSN。如果重放日志的时候，日志的LSN <= pageLSN，则不修改日志对应的Page，略过此条日志。
如图6-16所示，Page1被多个事务先后修改了三次，在Redo Log的时间线上，分别对应的日志的LSN为600、900、1000。当前在内存中，Page1的pageLSN = 1000（最新的值），因为还没来得及刷盘，所以磁盘中Page1的pageLSN = 900（上一次的值）。现在，宕机重启，从LSN=600的地方开始重放，从磁盘上读出来pageLSN = 900，所以前两条日志会直接过滤掉，只有LSN = 1000的这条日志对应的修改操作，会被作用到Page1中。
图6-16 pageLSN实现Redo Log幂等示意图
这点与TCP在接收端对数据包的判重有异曲同工之妙！在TCP中，是对发送的数据包从小到大编号（seq number），这里是对所有日志从小到大编号（LSN），接收的一方发现收到的日志编号比之前的还要小，就说明不用重做了。
有了这种判重机制，我们就实现了Redo Log重放时的幂等。从而可以从firstLSN开始，将所有日志全部重放一遍，这里面包含了已提交事务和未提交事务的日志，也包含对应的脏页或者干净的页。
Redo完成后，就保证了所有的脏页都成功地写入到