Oracle undo in memery(转载)

Oracle in-memroy undo运作原理

Oracle中undo的作用主要有两个：

第一是回滚事务

第二是产生一致性读。

同时也衍生出了一些新的 功能，比如Flashback query。传统的undo是通过undo segment来管理的，我们看下面的示例： 

事务开始

必须冲data block中分配ITL,ITL中记录了事务的ID(XID),

XID由XIDUSN(回滚段号)， IDSLOT(回滚段槽 号），XIDSQN(序列号）组成

Undo segment header中有一个事务表，记录了该回滚段上的事务信息。每个事务都会占用一个事务槽 ,XID对应一个UBA（undo block address）

Undo segmet header 的uba则指向最后一个undo block，这是回滚的起始位置，如果事务需要回滚，只需要在undo segment header中的事务表中找到事务回滚的起始位置，然后通过undo链表，就可以依次回滚整个事务。 

每个data block的ITL中也有个给UBA(是指向了该block对应的undo信息的起始位置 )block历经的最后一次改变所对应的undo record所在的UBA，用于读一致性，因为读一致性需要undo信息来构造一个CR block，通过这个UBA就可以直接定位到block的回滚信息的起始位置，而不再需要通过undo segment header中的事务表。 

注意：所以Undo segmet header 的uba和data block的ITL的UBA可以不一致。

在传统的undo管理模式中，Oracle对于undo和data block是一视同仁的，他们都需要首先读入到data buffer中进行修改，并都会产生redo信息，

修改的过程大致是：

产生undo的redo，更改undo block

产生data的redo，修改data block

总之redo必须要先于数据被记录下来。

当数据库发生crash，可以通过redo日志，恢复data和undo block

然后再通过undo信息去回滚未提交的事务，保证数据的一致性

所以说instance recovery的过程是先前滚，再回滚的过程。 

传统的undo管理有弊端

第一是undo信息如果不在data buffer中，必须首先从外部文件中读入

第二是undo的所有变化也必须同时记录redo，在事务提交时被写入到redo log中。

Oracle提出了In-Memory UNDO的新特性，将undo信息都存放在内存结构中，缓解传统undo管理中带来的开销。 

IMU

IMU在share pool 中分配一个内存空间 (IML pool)

每个新的事务都会分配一个IMU buffer，相当于一个私有的undo buffer，用来记录undo的信息通过IMU buffer中的信息就可以完成一致读，从而大大提升了效率。（这里要澄清一点，我在dump data block时，并没有发现指向IMU node的具体信息）。 

在IMU模式下

undo信息依然会被写入到redo中，理解这点很重要！因为Instance recovery需要undo的信息去回滚未提交的事物，使数据库处于一致状态，如果redo中没有undo变化的信息，那么一旦发生Instance crash，数据库将有可能处于一个不一致的状态。 

事务开始会在data block中的分配ITL，并且它依然会指向undo segment header的事物表 

undo block中的信息并不需要马上写入，这时undo信息是记录在IMU Buffer中的，这时也不会产生undo block的redo信息。 

在以下两种情况下，undo buffer中的信息才会写入到undo block中

--IMU buffer空间不足 

--LGWR将redo信息被写入到redo log中时（比如commit） 

v$sysstat中可以看到IMU flush和IMU commit，分别表示以上两种情况，如果你发现这两个值不断增加，代表系统开启了IMU特性。 

转载