12.ATTRIBUTES OF ARIES
ARIES对数据或其模型做了少量的假设，并且相比其他恢复方法有一些优势。ARIES很简单，并且它拥有一些有趣并且实用的特性。正如最后一节总结的，这些特性中的大多数已经运用到现有的一些系统中了。然而，还有没有哪个单独的系统能拥有其所有特性。ARIES的特性如下：
（1）支持优于页级别的并行控制，并且支持多种颗粒度锁。ARIES以统一的方式支持页级别和记录级别的锁。恢复并不受使用哪种锁颗粒度影响。依赖于数据的竞争模型，选择合适的锁级别。它同样允许多种锁级别并存（比如，记录级，表级，表空间级别）。除了锁，也可以使用并行控制策略。（比如【2】中提到的策略）。
（2）在重启或正常流程时使用灵活的缓存管理。一旦遵循了日志先行协议，缓存管理就可以使用任意页替换策略。比如，在事务提交之前，这些事务需要将脏页落地（steal 策略）。同样，也可以不要求在事务提交前刷出所有脏页（比如：no-force策略）。这些特性降低了对缓存的要求，并且减少了对更新（热点）页的频繁调用。ARIES并不排除使用延迟更新或者强制提交策略，而且可以得益于他们。ARIES在这些方面是非常灵活的。
（3）Minimal space overhead–only one LSN per page。持久化（不包括日志）空间负载受限于每个页上存储的LSN，记录该页上最近一次动作。页LSn通常是单调增长的值。
（4）对数据无限制以确保redo或者undo的幂等性。数据上没有限制，比如唯一key等等。记录可以是变长的。数据可以在页内移动以便垃圾回收。操作的幂等性是通过每个页上的LSN来确保的，通过LSN来决定某个操作是否要redo。
（5）某个更新的undo顺序不需要和原始操作顺序完全逆序。由于在Undo的时候会写CLR，原操作的逆序和实际进行的undo可以在之前就记录下来。有一个例子说明完全的逆序并不一定正确，关于数据页的空闲空间信息的（类似，10%空闲，20%空闲），这些是在空间映射页中维护的。因为使用了优于页级的锁，某个事务在开始更新一个页是，表空间信息不会发生变更，在undo的时候空闲空间信息可能发生了变更，因为其他事务的一些逆操作（参见10.3节）。
关于基于Hash存储方案和索引管理的优点在【59,62】有详细讨论。
（6）支持操作日志和特殊锁模型。对于某页的变更可以以逻辑方式记录。对于这个对象的undo和redo信息就都不需要记录日志了。如果只有变更的字段被记录也是完全够用了。由于历史重演，对于自增自减这种操作，就不需要该字段的变更前后数据镜像。知道这种操作的减少或增加的量就足够了。垃圾回收器的动作并且对页的一些字段的更新（比如：空闲空间的大小）不需要记录日志。特殊锁模型是基于操作的可交换性以及一些其他特性才能支持的【2,26,88】
（7）redo-only和undo-only记录都是适用的。它们有时候是很高效的（对日志组件只调用一次），在同一条记录中包含了undo和redo信息。在其他时候，它可能是高效的（undo记录可以从源数据构建，在对数据原地更新之后，从更新的数据可以构建redo记录），可能是必须的（因为日志大小限制）以不同的记录来记录信息。ARIES都可以处理这两种情形。在这些情况下，undo记录必须在redo记录之前记录。
（8）支持部分和全部回滚。除了允许事务全部回滚，ARIES还支持构建savepoint，并且允许事务回滚到这些savepoint。若不支持部分回滚，甚至一些逻辑恢复错误（比如：唯一key违反，分布式系统中的缓存目录信息过期）都会要求全部回滚，这便浪费了很多工作。
（9）支持对象跨越多个页。对象可以跨越多个页（比如：IMS中的记录可以包含多数据段，并分散在很多页上）。当某个对象变更了，如果对每个页的更新都做了日志记录，ARIES就能很好的工作。ARIES本身并不会特别处理多个页的对象。
（10）允许在任意时刻从操作系统获取和归还文件。ARIES提供了对动态的永久的归还文件给操作系统的灵活性（参见【19】节中有对这一技术的详细讨论）。这样的操作是不能undo。它也不能阻止同样的文件被数据库系统重分配。System R并没有要求对象（比如表空间）和文件之间的静态映射。
(11)即使整个事务回滚，其中的一些操作也是可以提交的。这涉及到使用dummy CLR的概念来实现内嵌顶级动作。文件扩展就一个得益于此的例子。其他使用该技术的例子，在hash存储和索引管理方面，在【59,62】中有详细说明。
（12）高效的checkpoint(包括在重启恢复时)。通过支持模糊checkpoint，ARIES可以高效的执行checkpoint。执行checkpoint时，可以并行进行数据更新和日志处理。在重启流程中使用checkpoint，可以减少重启时再次崩溃后的影响。checkpoint中记录的脏页信息可以在重启恢复进行redo遍历时减少读取物理存储中页的数量。
（13）在正常或者回滚流程是，多个事务的并发访问同一页。由于多个事务可以同时对同一页更新或回滚，这对并发访问要求很高。除了在修改或检测页时加上短暂的闩，在正常执行，回滚时，都不能影响其他事务。
（14）在事务回滚时没有锁或没有死锁。因为在事务回滚的时候不需要加锁，这样回滚事务就不会导致死锁。在回滚时不加锁不仅仅简化了回滚逻辑，也简化了死锁检测逻辑。死锁检测器不担心会错误的将一个回滚的事务作为解决死锁问题的牺牲品了（System R和R*【31,49,64】）。
（15）在重启时，不管有没有重复崩溃或者嵌套回滚，只会记录有限的日志。即使在重启时重复崩溃，所输出的CLR记录数也不会有影响。同样在嵌套回滚的时候也是如此。这和在正常流程执行事务回滚的所写的日志数目一样。后者生成的固定数量通常和其undo的记录数一致。在重启，redo遍历时，不需要输出日志。
（16）运行并行、选择性、延迟执行来加速重启恢复。通过在处理相应记录异步的进行IO读取可以加快重启速度。ARIES可以提前对需要恢复的页打上标记，然后开始异步并行IO来读取这些页。这些页在redo遍历的时候就加载到内存中。Undo的并行需要每个完整的事务由单独的进程进行处理。推迟重启的一些流程来加速重启或者适应一些离线设备。如果需要的话，在执行失效事务的undo时，可以同时开启新的事务。
（17）使用模糊镜像备份（文件归档）来进行介质恢复。介质恢复和数据进行备份可以十分高效执行。利用设备的几何特性，实际的备份动作可以在事务系统之外执行（比如：不需要检查缓存池）。即使后者正在访问或者修改正在备份的数据，这也是可以的。在介质恢复时，只会执行一次向前遍历。
（18）在系统重启是继续执行失效的事务。由于ARIES进行历史重演并且支持savepoint，我们可以在undo遍历时，将其回滚到最后一次savepoint，而不是全部回滚。必须占有锁来保护事务未提交的，还没undo的更新。接着，触发应用来继续执行事务，并传入足够多的关于此savepoint的信息。
（19）在重启或介质恢复时，只有一次向后遍历日志。在介质恢复和重启恢复时，只做一次向后遍历就足够了。尤其当日志的一部分是存储在一些低俗介质上时（比如磁带），这一特性就十分重要了。
（20）对于补偿日志记录只需要记录redo信息就行了。由于补偿记录永远不会被undo，他们只需要包含redo信息。所以，平均的来看，在事务回滚所占用的日志空间只有正常事务的一半。
（21）支持分布式事务。ARIES适用于分布式事务。一个站点它是协调者还是下级站点都不会对ARIES有影响。
（22）使用部分回滚在事务回滚和解决死锁是提前释放锁。因为ARIES从来不undo CLR，并且也不会重复undo某个non-CLR，在（部分）回滚是，事务对某个对像进行undo时，会对此写一个CLR,系统可以释放该锁。这样使用部分回滚解决死锁问题成为可能。
需要注意的是，ARIES并不拒绝使用影子页技术，用来记录数据的某些部分，避免只记录undo信息，或者undo和redo信息。这在处理长字段的时候会比较有用，正如 OS/2 Extended Edition Database Manager。在这类场景中，对于这些数据，修改的页需要在提交前强制落地。是否能支持部分回滚和介质恢复取决于使用的是那种日志方式以及那种影子页技术。