11. OTHER WAL-BASED METHODS其他基于WAL的方案
接下来，我们会总结一些其他使用WAL协议的恢复策略的特性。基于影子页技术的恢复策略（比如System R）不在此考虑之内，因为一些众所周知的缺陷，比如：执行checkpoint很耗时，对于数据的影子备份需要额外的存储空间，disturbing the physical clustering of data,对于页映射需要额外的IO（参见本文的之前的章节，【31】中有更多的讨论）。首先，我们简略的介绍这些系统及其恢复策略。接着，我们会从不同维度对比这些不同的方法。我们得知【25】中的DB-cache恢复策略已经被Siemens做了很大的修改。但是无法获取这方面实现细节，我们就不包含对其的讨论。
IBM的IMS/VS 【41, 42, 43, 48, 53, 76, 80, 94】，是一种分层数据库系统，包含两个部分：IMS Full Function (FF),这是相对灵活的，IMS Fast Path [28, 42, 93],这个相对更高效点，但是有很多限制（比如：不支持secondary索引）。同一个IMS事务可以同时访问FF和FP数据。这两个所使用的恢复和缓存方法都有很多不同之处。在FF中，锁有多种颗粒度，取决于数据库类型和其操作类型。FP支持两种数据库，主存储数据库（MSDB）和数据实例数据库（DEDB）。MSDB只支持固定长度记录，但是FP提供一种机制来使得对MSDB记录锁的持有次数尽可能的少。DEDB只支持页锁。但是DEDB有很多高可用性，高并发的特性，并且支持大数据量。IMS连同XRF一起，支持热备份【43】。IMS通过全局锁，可以支持不同系统之间的数据共享，但是用自己的缓存池【80，94】。
DB2是IBM为MVS操作系统开发的关系型数据库。DB2支持有限分布式数据库访问。DB2的恢复算法在【1,13,14,15,19】中有详细描述。它支持多种颗粒度锁(表空间，表，数据页，迷你页，索引页)和多种一致性级别（游标稳定性，重复读）【10,11,12】。DB2支持临时关闭表和索引的日志记录，只有在一些工具类操作比如加载和重组数据的时候。同一个事务可以同时原子性的访问DB2和IMS。Encompass恢复算法【4,37】修改了一些之后已经合并到Tandem的NonStop SQL中【95】。通过NonStop，Tandem的产品就能够支持热备份。Encompass和NonStop SQL 都支持分布式数据访问。他们支持在一个事务中执行多站点更新，使用【63,64】的Presumed Abort两段式提交协议。NonStop SQL 支持不同颗粒度锁（文件，前缀key和记录）和一致性级别（游标稳定性，重复读，非锁或脏读）。可以临时关闭日志，即使没有工具对其文件进行操作的时候。
Schwarz【88】提供了两种不同的恢复方式，基于值日志和操作日志。这两个方法有几处不同，下面将会详细列出来。值日志方法（VLM）比操作日志方法（OLM）要简单很多，在CMU的Camelot【23,90】就是这么实现的。
缓存管理
Encompass, NonStop SQL, OLM, VLM 和 DB2都支持强制和非强制策略。在正常流程时，VLM和OLM，从持久化存储读取页时都会写一条fetch记录，把脏页写会到持久化存储中时也会写一条end-write记录。在重启恢复时，只有OLM会这么写。这些记录可以用来帮助标识在系统崩溃时还有哪些脏页在缓存池中。DB2有一个很复杂的缓存管理模块【10,96】。并且在打开表空间，索引空间的时候都会写日志，关闭的时候也会写另一条日志。只有当该空间中的所有脏页都写回到持久化存储时才会执行关闭操作。DB2的分析遍历会使用这些日志来将脏页信息更新到系统崩溃时刻的状态。
对于MSDB，IMS FP会延迟更新。也就是说，某个事务会看不到自己的对MSDB的更新。对于DEDB，使用的是非强制策略。FP在提交时才会写，该事务的所有日志记录会在一个调用中传给日志管理组件。在将日志写到日志缓存（不是持久化存储上）中后，MSDB上的更新就生效了，MSDB的记录锁会被释放。在提交日志落地之前，MSDB的锁就释放了。这就是FP如何减少对于MSDB记录的锁持有时间的。DEDB的锁被传送给系统进程。在一定时间内，日志组件会强制将日志落地（比如，在事务提交之后），所有被该事务修改的DEDB的页都会通过系统进程强制落地，完成IO之后就会释放DEDB的锁。这不会导致任何未提交的更新会落地，因为DEDB对页锁使用了非强制策略。使用单独的进程来刷出DEDB的页到持久化存储上，是为了让用户进程能够尽快的执行下一条事务，也提高了IO的并行度。IMS FF使用了强制策略。在事务提交之前，IMS FF会强制将该事务修改的页刷出到持久化存储中。由于FF支持的比页还要低颗粒度的锁，这就会导致一些未提交的数据也被落地了。当然本节中讨论的所有恢复算法都会在提交阶段强制日志输出。
正常checkpoint
正常检测点是指在系统非恢复模式下执行的的检测点。OLM和VLM在系统中默默执行这些活动，这和System R类似，并执行一致性（不需要事务一致性）checkpoint.checkpoint的记录内容和ARIES的类似。DB2，IMS，NonStop SQL和Encompass都采用（模糊）checkpoint，即使当更新和日志活动并行执行时。DB2的checkpoint动作和ARIES的类似。他们最大的不同是，它是用每个对象的RecLSN来写脏对象（表空间，索引空间）列表【96】，而不是写脏页表。对于单独的MSDB，IMS在checkpoint时会将其完整的内容写到交替的两个持久化文件中去（选择一个写）。由于MSDB使用了延迟更新，在checkpoint没有未提交的更新。因此，也可以确保没有部分提交的更新。需要注意的是，由于在写了提交记录后，更新就生效了。对于DEDB来说，任何已提交的更新，但还没落地的会包含在checkpoint记录中。这样在重启恢复FP数据时，就不需要检验checkpoint之前的记录了。Encompass 和NonStop SQL可能会在checkpoint的时候强制落地脏页。它们的强制策略是这样的：一个脏页在第二次检测点完成之前必须落地。因为这个策略，检测点因为要等待老的脏也刷出而延迟完成。
部分回滚
Encompass, NonStop SQL, OLM and VLM 都不支持事务的部分回退。对于IMS的第二版本支持部分回退。实际上，savepoint是暴露给应用层的。只有当应用不会访问FP数据时才会支持。排除FP数据的原因是FP在日志中不写undo数据，并且MSDB是延迟更新的。DB2内部使用部分回滚，用来提供语句级的原子性【1】。
补偿日志记录
Encompass, NonStop SQL, DB2, VLM, OLM和IMS FF在正常回滚时都会写CLR。在正常回滚时，IMS FP不写CLR，因为在回滚之前它不会输入任何变更的日志。这是因为FP通常使用两段式提交，因此它不会进到prepared状态。由于MSDB使用延迟提交，在回滚的时候只要丢弃保留在追加（todo）列表中的更新就行了。由于DEDB使用的是非强制策略和页锁，在回滚的时候，被修改的页只是简单的重置了。Encompass, NonStop SQL, DB2 和 IMS (FF 、 FP)在重启回滚的时候也会写CLR。在重启恢复时，IMS FP可能找不到（最多）一个in-progress态事务的日志。该事务必须已经在提交了--比如，快要提交了，系统崩溃时，有些日志已经刷到持久化存储上。尽管，由于使用了非强制策略，没有FP的更新落地，因此就没有东西需要undo,IMS FP会写一些记录来简化介质恢复【93】。由于FP日志只包含redo信息，仅仅写一些CLR,这正是undo信息所需要的，在重启恢复时就可以访问那些没有被修改的数据。得向读者阐明的是：即使使用了非强制策略，并且不支持部分回滚，重启时处理FP仍然有一些问题。通常，人们认为，no-steall杜绝了很多问题。实际上它也有很多弊端。
VLM在重启恢复时不会写CLR。结果，在回滚事务的时候就只会写有限的日志，即使在重启时系统再次崩溃。实际上，只有在正常回滚时才会写CLR。当然，这对介质恢复也会影响介质恢复。OLM在重启时会对undo和redo都会写CLR（分别称之为undomodify和redomodify记录）。如果重启流程被打断的话，OLM可能对于同一条更新记录写多条undomodify和redomodify记录。CLR不会给自己生成CLR。在重启恢复时，Encompass 和 DB2会undo CLR的变更，从而输出CLR的CLR，在正常流程或重启恢复时会多次写这些CLR。最坏的情况是，如果不断的重启失败，日志记录数会呈指数级增长。图5展示了ARIES是如何规避此问题的。IMS在undo遍历的时候忽略了CLR，这样就不会对它们写CLR了。继而导致的结果是：因为多次崩溃，和其他的一样，IMS可能会对同一条记录结束写相同的CLR。更糟的是，IMS和OLM写的日志记录数呈线性增长。因为它的强制策略，IMS只有在介质恢复的时候才会redo CLR的变更。
日志记录内容
IMS FP只会写redo信息（比如，完整数据镜像），因为它使用的是no-steal策略。正如之前提到的，IMS使用值（或者状态）日志和物理（比如字节尺度的）锁（参见【76】）。IMS FF日志包含undo信息和redo信息。由于IMS不会undo CLR的更新，只有redo信息中需要CLR。为了支持XRF热备份，IMS在其日志记录中包含了足够的信息来备份系统，并跟踪所更新对象的锁信息。IMS FP 同样记录被修改页所占的缓存地址。在备份恢复或重启恢复时，可以使用此信息来减少redo DEDB的更新的工作量。Encompass 和 VLM同样记录变更记录的完整undo,redo信息。DB2和NonStop SQL log只记录变更字段前后的镜像数据。OLM记录更新的操作。Encompass和DB2的CLR需要包含redo和undo信息，因为它们的CLR可能会被undo。OLM会周期性的记录每个对象的一致性快照。OLM的undomodify和redomodify记录，没有redo或undo信息，只包含了被修改记录的LSN。但是OLM的modify , redomodify , undomodify 也包含了一个对页的映射，这可以标识出修改的对象处于哪些页上。
Page overhead
Encompass 和 NonStop SQL使用页LSN来跟踪每个页的状态。VLM使用多LSN，但OLM使用单LSN。DB2使用单LSN，IMS FF不使用LSN。IMS FF不使用LSN，VLM想知道页状态也没问题的，因为IMS和VLM的值日志和物理锁属性。redo一个已生效的更新或者undo一个不存在的更新是可以接受的。IMS FP使用DEDB中的一个字段来记录版本号，这样就能在系统崩溃后能正确处理redo【67】。当DB2将一个索引页分割成迷你页时，它会在每个迷你页上加上LSN，除此以外整个页上还有一个LSN。
Log passes during restart recovery重启恢复时的日志遍历
Encompass和NonStop SQL进行两次遍历（redo然后undo）,DB2进行3次遍历（分析，redo，然后undo，参见第6节）。Encompass和NonStop SQL从倒数第二个成功的checkpoint开始redo遍历。这就足够了，因为缓存组件会要求两个检测点之间的脏页都会刷到磁盘上。在执行undo遍历之前，它们似乎也会重演历史。如果主系统崩溃了，然后启动备份系统的话，就不会进行历史重演【4】。在被热备份接管时，首先获取对失效事务的更新锁。然后回滚这些失效事务，同时还可以开启新事务。每个失效事务使用一个单独进程来回滚，从而获取并行性。DB2的redo扫描的其实点，取决于最近一次checkpoint中包含的信息，这会有分析遍历来修改。正如之前所提到的，DB2使用选择redo（参见10.1小节）
VLM进行向后遍历，OLM执行3次遍历（分析，undo，redo）。在OLMS和VLM的遍历过程中会维护很多列表。OLM的undomodify和redomodify日志记录只是用来修改这些列表，这和其他系统输出的CLR不同。在VLM中，使用向后遍历来undo那些没有提及的变更，并且redo已提交的变更。在执行这些操作时不会写日志。在OLM进行undo遍历是，对于恢复的每个对象，如果某个对象的操作一致性版本不在持久化存储上，那么它就会从快照日志中读取该对象的快照，然后从这个对象开始：（1）在剩余的redo遍历中，任何对这个快照记录之前的更新都可以进行逻辑undo。（2），在redo遍历时，对于此快照对象的已提交的或in-doubt态的更新都可以逻辑redo.这和【16,78】中使用单独日志的影子技术类似--不同的在于对象级别的checkpoint代替数据库层面的checkpoint，并且只用一个日志而不是两个。
IMS首先重新加载MSDB，使用崩溃前最近一次成功的checkpoind收到的内容。包含在checkpoint中的脏DEDB缓存也会被加载到相同的缓存中。也就是说，在崩溃后重启时缓存数不可以再改变了。接着，它只做对日志做一次向前遍历（参见第6节）。在这次遍历过程中，它将日志在内存中按事务分开然后，如果需要的话，redo那些完整的事务的FP更新。可以使用多进程来redo这个DEDB更新。考虑到FP，只关心从最后一个checkpoint开始的更新。在遍历结束是，会undo那些in-progress事务的FF更新。（使用内存中日志记录），一个事务一个进程并行处理。如果某个事务的日志记录因为空间不够没法记录在内存中，就会发起一次向后扫描来获取该事务回滚所需的日志记录。在XRF环境中，如果一个热备份IMS接管了，对于失效事务的处理和Tandem类似。也就是说，在回滚的同时新的事务也可以执行。
Page forces during restart.
OLM，VLM，DB2在重启结束时会强制刷出所有脏页。Encompass 和 NonStop SQL就不得知了。
Restart checkpoints
IMS, DB2, OLM 和 VLM只有在重启恢复结束时才会执行checkpoint.Encompass 和 NonStop SQL就不得知了。
Restrictions on data.数据限制
Encompass 和 NonStop SQL 的每条记录必须要有唯一key。该唯一key使用来确保如果想undo一个日志操作，该操作并没有在持久化存储执行过，那么undo就会失败了。也就是说，使用唯一key可以保证操作的幂等性。IMS使用字节尺度的锁和日志，因此不允许记录在页内随意移动。这就导致了碎片化，空间利用率较低。IMS对FP数据强加了一些限制。VLM要求数据分隔成固定整数长度（小于一页的大小）。这些限制所导致的结果和IMS的类似。
【2,26,56】没有讨论系统崩溃后的恢复，【33】的原理论述也没有包含富语义的锁模型（比如，操作日志）。在本文的其他章节，我们已经指出使用一些其他方法（由那边论文中提出的）的问题。