本文是介绍MySQL数据库InnoDB存储引擎重做日志漫游

  事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。如果在执行的过程中发生
  了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。

  Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方
  （这个存储数据备份的地方称为Undo Log）。然后进行数据的修改。如果出现了错误或者用户执行了
  ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。

除了可以保证事务的原子性，Undo Log也可以用来辅助完成事务的持久化。

  事务一旦完成，该事务对数据库所做的所有修改都会持久的保存到数据库中。为了保证持久性，数据库
  系统会将修改后的数据完全的记录到持久的存储上。

  之所以能同时保证原子性和持久化，是因为以下特点：
  B. 为了保证持久性，必须将数据在事务提交前写到磁盘。只要事务成功提交，数据必然已经持久化。
  D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。所以磁盘上的数据还是保持在事务开始前的状态。

缺陷：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。

如果能够将数据缓存一段时间，就能减少IO提高性能。但是这样就会丧失事务的持久性。因此引入了另外一
种机制来实现持久化，即Redo Log.

  不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统可以根据
  Redo Log的内容，将所有数据恢复到最新的状态。

  Undo + Redo的设计主要考虑的是提升IO性能。虽说通过缓存数据，减少了写数据的IO.
  但是却引入了新的IO，即写Redo Log的IO。如果Redo Log的IO性能不好，就不能起到提高性能的目的。

  前面说到未提交的事务和回滚了的事务也会记录Redo Log，因此在进行恢复时,这些事务要进行特殊的
  的处理.有2中不同的恢复策略：

  A. 进行恢复时，只重做已经提交了的事务。
  B. 进行恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过Undo Log回滚那些

- InnoDB存储引擎的恢复机制
  MySQL数据库InnoDB存储引擎使用了B策略, InnoDB存储引擎中的恢复机制有几个特点：

1.1.1Redo的作用是恢复已提交的事务，从而保证无论在介质失败还是实例失败时，都可以恢复用户已提交的事务，使数据库达到一致状态。

1.1.2Redo功能的实现依赖于以下三个组件：

• –联机重做日志文件和归档日志文件

  1.2.1用SQL*Plus内置的AUTORACE功能统计（只能针对简单的DML操作，无法统计存储过程调用等复杂操作的日志信息）：

本文主要讲述关于undo、redo的一些内容。由于undo、redo内容非常多，短时间内难以讲诉清楚，故若水三千，我们只取一瓢，我将从Oracle事务切入，分析undo、redo在事务中的作用。

分享一句出自《道德经》里的话，我做了一个曲解，即：“道”理解为原理；“术”理解为实践、操作，就是说如果我们懂得了事物的原理，那么实践性的东西我们是可以培养和训练的，但是如果我们只懂得表面的操作，而不懂原理，那我们就只能停留在事物的表层，如果遇到新的情况，就难以应对。我认为做DBA也是一样，要能够理解Oracle的原理，才能处理一些深层次的问题，而不是在google无结果后就缴械投降。本篇文章的主要内容就是布道。

1、Undo在事务中的作用

2、Redo在事务中的作用

• 解析redo结构、undo受redo保护的实质、CV对数据块的作用

• 理解快速提交机制、delete实质

最近连续遇到3个由于ORA-600错误导致数据库无法启动的情况，其中两个都是由于异常关机后导致无法启动，这种错误大部分情况是与redo、undo相关，但是怎样来定位问题，怎样解决？这就需要了解Oracle redo、undo的原理，定位问题的方向一般都是解读alert日志、trace日志、或者在mount阶段使用一些跟踪事件，比如10013、10015、10046等进行辅助分析。

当然还有最主要的一招，查MOS，MOS上有专门针对600错误的搜索入口，在这里根据错误代码的第一个参数进行匹配查找：

但如果这里匹配不上，或者MOS上给出的解决办法无效，就还是得回到使用trace日志等分析定位问题，但是这里的trace的解读可能会是拦路虎，怎样去解读trace不是今晚的主题，不做深入，当然不同的trace解读的方法也不尽相同，但是我自己有个体验，就是对Oracle的一些原理和数据结构理解越透彻，就越能读懂trace文件，我们只需要读懂其中的一些关键点，其余可以进行猜测，就足以解决问题，就像英语的阅读理解，只需要读懂1/3的内容，就能解答2/3的问题。这里扯的有点远了，我们回到今晚主题，希望通过今晚的分享能够让大家对undo、redo在Oracle事务中的作用有一定了解，并通过对undo、redo的部分结构的解析，让大家深入Oracle内部，在后续处理相关问题时能够有所帮助。

首先，先说下我对事务的理解。Oracle数据库根本上是一个程序，跟其他的应用系统程序无差别，应用系统的程序如果没有业务，那程序代码就无意义，Oracle如果没有事务运行，那Oracle代码也就无意义，所以，事务对于Oracle就像业务对于应用系统一样，是Oracle的灵魂，从这个意义上看，Oracle实例可以看做是用一段代码在维护很多事务运行，事务是oracle实例运行的核心任务，事务产生的数据就是db（控制文件、system文件等可看作内部事务产生）。个人理解，仅供参考。

下面描述一下oracle事务的一个简单过程：

1、在事务开始前，会申请redo资源、undo资源； redo的申请主要是要获取记录redo的内存资源，会涉及到redo allocation latch等资源的申请， undo资源申请是要获取到一个undo段用来存储undo数据（IMU机制会稍有不同）；

2、在undo段头的事务表中申请一个槽位，记录事务信息，这些相关信息也会以xid等形式写入到数据块的事务槽中；

3、undo段头的事务表指向可用的undo块，undo块用于存储具体的undo信息；

4、事务开始，进行增、删、改、查等操作，redo记录相关信息、undo也记录相关信息，在事务涉及到的行头还会设置行锁标记；

5、事务提交或回滚，结束事务。修改undo段头事务表信息，尽可能的修改相关数据块的事务槽信息、行锁信息，将相关事务信息写入redo log文件。

上面只是粗略的一个描述，其中涉及到很多概念，比如undo段头、unod块、事务槽、行锁标记、redo记录等，这些东西具体长什么样？是怎样工作的呢？这里让我想起了一句话：爱情就像鬼一样，谁都听过，但谁也没见过。下面我们就通过实验来解析上面提到的这些概念，看一看是否真的有爱情。

上面的实验修改了表中的两条记录，且这两条记录是存放在不同的块中先dump被修改的两个数据块进行观察

前面提到的事务槽和行锁标记都出现了，我们看到爱情了！！！

事务槽中涉及到几个重要的结构，下面进行下解释：

这两个重要结构简单的理解就是，xid指向了事务使用的undo段号、事务表中的槽位号、以及槽位被覆盖的次数；uba指向事务使用的最后一个undo块、seq值、以及最后一条undo记录。

事务槽中还有一个flag段，这个段有不同的取值，代表事务的不同状态，可以通过修改这个标志实现手工提交事务，常见的取值有以下几种：

再回到前面的两个块的dump数据可以发现，两个数据块的事务槽中都有一个未提交的事务，都是使用了第二个事务槽，两个块的xid完全相同，即两个块使用的是同一个undo段中的同一个事务表槽位，uba的前两部分也完全相同，即使用的是同一个undo块，第三部分不一样，说明两个块的前镜像使用了两个条undo record进行记录。

从xid信息可以知道，事务使用的是第6号回滚段，下面dump 6号undo段头进行观察：

上图就是undo段头中的事务表，又看到爱情了！！！

下面对其中的几个重要列进行解释：

Uel：跟提交列表有关

根据前面两个块的xid（0x0001a5）可知，事务使用的是1f号槽位，从前面事务表的图中可以看出，该槽位的state列为10，即事务未提交，其对应的undo block的地址为c03fba。

将该dba地址进行转换：

使用的undo块是3号文件的16314号块，下面dump该块进行观察：

这里有两个重要结构，irb指向事务的最后一条undo记录，即回滚的起点，icl指向事务的第一条undo记录，即回滚的终点。

• redo记录中的rci指向的是事务的前一条undo记录；

• 前镜像的内容中只记录了被修改列内容；

• undo块中存在着一条链表，这个链表见下图：

这就是undo chain的一部分，与事务的混滚操作有关，undo块的irb指向事务undo record的最后一条记录 ，该记录中的rci指向前一个undo record记录，以此类推，最后一个undo record的ric为空，表示事务的起点，也是回滚的终点。

这里大家可以扩展思考一下，oracle的save point是如何实现的，是不是会与undo chain有关？如果修改rci值是不是可以实现回滚部分事务？

下面我们来看一个网上流传比较广的一个图：

从前面我们的实验可以看出，这个图是有歧义的，undo镜像不是块级别的，所以不是一个数据块对应一个undo块，undo镜像其实是列级别的，只有被更改的列才会被记录。

Undo在事务中的工作方式我们就先分析到这。

2.1 解析redo结构、undo受redo保护的实质、CV对数据块的作用

下面来看一看redo是如何工作的：

接下来dump 405号块进行观察（这里只选取表数据部分）

使用BBED观察DBA+这列的行头信息

下面删除其中的两条数据（这两条数据是位于不同的块中）

3、 OP表示操作类型，不同的值表示不同的操作类型；

4、 redo中包含了前镜像，这就是redo保护undo的实质；

5、 上面的操作涉及两个块，但是只有一条redo record，所以redo record是可以包含多个块的，但是一个CV只能针对一个块，CV是一个数据块块版本演进的结果，CV只能向前推进数据块的版本，不能后退，对于回滚操作，会由于undo的应用而生成新的CV，这个CV依然是推进数据块版本，要使数据块版本回退的唯一方法是介质恢复。

2.2 理解快速提价机制、delete实质

下面再次dump 405号块（包含DBA+的数据块）

注意，这里nrow显示还有两行数据，但是删除行的数据没有在dump中显示；行锁标记也未释放，但是事务已经提交了，这就是Oracle的快速提交、和延迟块清除机制，只是保证修改undo段头事务表信息，块头和行头信息不一定进行修改。

那么delete到底发生了什么？下面用bbed进行观察：

发现被删除的数据依然在块中，只是行头标记被修改，这就是delete的实质。所以在数据被覆盖之前是可以通过修改行头标记恢复被delete的数据的。

还记得我们开始的那句话吗？爱情就像鬼一样，谁都听过，但谁也没见过。通过上面的实验，我们应该看到了一些东西。真爱还是有的！

时间，教会了我们很多东西。有些我们曾经认为根本没有的，后来发现，它确确实实存在着，而有些我们深信不疑的，后来却明白，根本就没有。比如，爱情…