如果再有人问你数据库的原理,把这篇文章给他(19)

  • 2) Redo阶段:这一关从分析中选中的一条日志记录开始,使用 REDO 来将数据库恢复到崩溃之前的状态 。
  • 在REDO阶段,REDO日志按照时间顺序处理(使用LSN) 。
    对每一条日志,恢复进程需要读取包含数据的磁盘页LSN 。
    如果LSN(磁盘页)>= LSN(日志记录),说明数据已经在崩溃前写到磁盘(但是值已经被日志之后、崩溃之前的某个操作覆盖),所以不需要做什么 。
    如果LSN(磁盘页)< LSN(日志记录),那么磁盘上的页将被更新 。
    即使将被回滚的事务,REDO也是要做的,因为这样简化了恢复过程(但是我相信现代数据库不会这么做的) 。
    • 3) Undo阶段:这一阶段回滚所有崩溃时未完成的事务 。回滚从每个事务的最后一条日志开始,并且按照时间倒序处理UNDO日志(使用日志记录的PrevLSN) 。
     
    恢复过程中,事务日志必须留意恢复过程的操作,以便写入磁盘的数据与事务日志相一致 。一个解决办法是移除被取消的事务产生的日志记录,但是这个太困难了 。相反,ARIES在事务日志中记录补偿日志,来逻辑上删除被取消的事务的日志记录 。
    当事务被『手工』取消,或者被锁管理器取消(为了消除死锁),或仅仅因为网络故障而取消,那么分析阶段就不需要了 。对于哪些需要 REDO 哪些需要 UNDO 的信息在 2 个内存表中:
    • 事务表(保存当前所有事务的状态)
    • 脏页表(保存哪些数据需要写入磁盘)
    当新的事务产生时,这两个表由缓存管理器和事务管理器更新 。因为是在内存中,当数据库崩溃时它们也被破坏掉了 。
    分析阶段的任务就是在崩溃之后,用事务日志中的信息重建上述的两个表 。为了加快分析阶段,ARIES提出了一个概念:检查点(check point),就是不时地把事务表和脏页表的内容,还有此时最后一条LSN写入磁盘 。那么在分析阶段当中,只需要分析这个LSN之后的日志即可 。
    结语写这篇文章之前,我知道这个题目有多大,也知道写这样一篇深入的文章会相当耗时 。最后证明我过于乐观了,实际上花了两倍于预期的时间,但是我学到了很多 。
    如果你想很好地了解数据库,我推荐这篇研究论文:《数据库系统架构》,对数据库有很好的介绍(共110页),而且非计算机专业人士也能读懂 。这篇论文出色的帮助我制定了本文的写作计划,它没有像本文那样专注于数据结构和算法,更多的讲了架构方面的概念 。
    如果你仔细阅读了本文,你现在应该了解一个数据库是多么的强大了 。鉴于文章很长,让我来提醒你我们都学到了什么:
    • B+树索引概述
    • 数据库的全局概述
    • 基于成本的优化概述,特别专注了联接运算
    • 缓冲池管理概述
    • 事务管理概述
    但是,数据库包含了更多的聪明巧技 。比如,我并没有谈到下面这些棘手的问题:
    • 如何管理数据库集群和全局事务
    • 如何在数据库运行的时候产生快照
    • 如何高效地存储(和压缩)数据
    • 如何管理内存
    所以,当你不得不在问题多多的 NoSQL数据库和坚如磐石的关系型数据库之间抉择的时候,要三思而行 。不要误会,某些 NoSQL数据库是很棒的,但是它们毕竟还年轻,只是解决了少量应用关注的一些特定问题 。
    最后说一句,如果有人问你数据库的原理是什么,你不用逃之夭夭,现在你可以回答:给你篇文章自己看~

    【如果再有人问你数据库的原理,把这篇文章给他】


    推荐阅读