1. 冲突解决
假如有一个系统只有你和我两个用户，并且我们都在持续对系统中一小部分数据做修改和查询操作。
如果你正在数据库中做一批修改操作，而我正在做查询，我一定不能看到你所做的修改，直到你告诉我可以看到你所做的所有更改才行（你提交了事务）。因此在oracle内部，必须有一个高效的办法来识别哪些数据我可以看到，哪些数据我不可以看到。
从相反的角度来看，在你提交事务的时候，你需要一种高效的机制让其他所有人能够看到事务已经提交(也就是要告诉别人你所有修改过的数据都是可见的了)。更极端一点的情况是，你可能需要决定回滚事务，这样的话，你也需要一种高效的机制能够关联上所有的undo记录，按生成的顺序排序，从而可以按相反的顺序回滚这些更改。
2. 事务与undo
创建数据库的时候，必须创建一个undo表空间。同时，oracle会在undo表空间中自动创建多个undo段，随着数据库负载的变化自动新增，扩大和收缩。
事务管理起始于undo段，并以此为中心。undo段的第一个块（段头块）包含如下结构：扩展映射，扩展控制头（跟其他类型的段头块一样），事务表，事务控制区（特殊的结构）。事务表的大概结构如下：
TRN TBL:
index state cflags wrap# uel scn dba nub cmt
0X00 9 0X00 0X2013 0X001b 0X0000.016f1fc1 0X0180083e 0X00000001 1302762364
0X01 9 0X00 0X2014 0X001a 0X0000.016f1f54 0X0180083e 0X00000001 1302762364
0X02 10 0X80 0X2013 0X001d 0X0000.016f20fc 0X0180083e 0X00000001 0
0X03 9 0X00 0X200c 0X001c 0X0000.016f20d8 0X0180083e 0X00000001 1302762364
0X04 9 0X00 0X200f 0X001f 0X0000.016f1c75 0X0180083f 0X00000001 1302762364
.........
index 表示事务表中槽号，只是一个序列而已，从0x00开始到0x21结束,11g的版本有34个槽。
state 表示事务状态：9代表事务不活动，10代表事务正在活动，从这里我们看出16进制第0x02号槽上的事务正在活动。
cflags 表示正在使用事务槽的事务的状态：0x00表示非活动事务、0x80表示活动事务、0x10表示死事务、0x90表示被回滚的死事务
wrap# 表示事务表上的事务槽被重用的次数，它是XID的一部分。0x2013表示此时事务槽被重用了8211次。
uel 表示当前活动事务所在事务槽的下一个事务槽的指针（即如果又发生一个新的事务，此时就会用到UEL指向的事务槽上的index）。
scn 表示务事启动、提交、回滚的SCN.
dba 表示uba:第一部分的undo块地址，这个DBA是(rollback)回滚的起始点，也就是说是记录事务修改的最后一条记录所在UNDO块的地址。这使oracle在崩溃恢复时，能够找到事务生成的最后一条undo记录，以便知道从何处开始处理回滚。
nub 表示当前事务所用到的UNDO块的个数。事务回滚时，可以看到该值会逐步减少。
cmt 表示最接近当前的提交时间戳，是从1970年1月1号零晨开始的（以秒为单位记录）。0表示事务正在活动。
2.1 事务的开始和结束
当会话开始一个事务的时候，会先取到一个undo段，从undo段的事务表中取得一条记录，然后增加该记录的wrap#的值，将state改为active(10),同时修改事务表其他一些列（比如cmt置0）。由于这也是对于数据库块的修改，所以会生成一条最终写入重做日志文件的重做改变向量（操作码为5.2），并写入数据库。这样会话就有了一个活动的事务了。
同样，当事务完成时（通常是用户commit），会将state设回为free（9），并更新其他一些列，比如将当期的SCN写入scn列。同样，对数据库块的这一修改也要生成一个重做改变向量（操作码5.4），最终记录到重做日志中。这一刻相当特别的重要，因为这个时刻你的会话正在向日志写进程（lgwr）发布命令将日志缓冲区的当前内容写入磁盘，并等待日志写进程确认写入完成，以保护所提交的更改。（这个发送命令要求lgwr进程输出重做日志到磁盘其实很简单，一旦发现进入日志缓冲区的重做日志操作码是5.4,也就是是提交事务记录，立刻将所有缓冲区的日志刷新输出磁盘，完成后并告知把这条提交记录放入日志缓冲区的会话。）
每一个事务会分配一个事务id，事务id由undo段编号，事务表中的条目索引号以及事务条目中最新的wrap#值构成。因此，当你看到像0X0009.002.00002013这样的事务id时，就会知道：这个事务在undo段9里，用的是第2条事务表记录，wrap#值为0X2013。如果你想看这是哪个undo段，以及相应的段头位置，可以使用segment_id列作为查询条件查询dba_rollback_segs视图。
2.2 事务表
在上面我们已经介绍了事务表的结构了，现在回顾一下，事务表主要的目的无非下面几个：
1. 显示事务是已提交还是仍旧活动
2. 已提交事务的SCN
3. 事务生成的最近一条undo记录的位置信息，便于回滚
4. 事务生成的undo量
如果一个事务必须回滚，或者一个会话被强制杀掉，使得smon（系统监视进程）必须要回滚它的事务，或者如果实例崩溃，在实例恢复期间，smon必须回滚所有崩溃时的活动事务。那么此时可以轻松找到所有活动事务（状态等于10），并且找到每一个事务正在使用的最后的undo块（dba列）。然后可以根据每一个事务对应的undo块链表往回查找，应用每一条undo记录，因为每一条undo记录指向了本事务中前一条undo记录。
2.3 undo块简要介绍
undo块和普通数据块有许多相似之处：块头部分记录了若干控制信息和元数据，行目录列出了堆积存放在块中的每一项的位置，若干undo记录在块中自底向上堆放在一起，块空闲空间位于块中间。但表行和undo记录最大的区别在于，undo记录不会被修改，因此一旦undo记录被写入块中，会永远保留在相同的位置。（表行被修改之后，如果原来位置放不下，会拷贝到另一个新位置，这样块中会留下杂乱的指针和临时的空洞）。
一个不太为人知的事实是，单个undo块也可以包含多个事务的undo记录。一个事务会以独占的方式请求undo块的所有权，pin住，然后使用该块直到块满（此时事务请求新undo块并更新它的事务表槽以指向新块）或事务提交。如果事务提交后，undo块中仍有空闲空间，该块会被加入到undo段头中空闲块池的候选链表中。如果发生这种情况，该undo块会被其他事务使用其剩余的空间。