事务和一致性
oracle的redo和undo机制保证了数据库的ACID特性，以及高性能和可恢复特性。
redo的数据是记录着数据块变更的顺序的正向数据流，
- commit时，保证redo同步持久化，保证高性能。
- 恢复的时候，顺序的应用日志。
redo的机制相对比较简单。
undo记录着数据块的前映像。
- 保证事务的特性，数据只有在commit后才可见。
- 提供读一致性，保证读写互不阻塞。
一方面，在undo segment header中transaction table中记录着事务，并在undo的record中维护着link list，实现事务的回滚。
另一方面，在数据块中intereted transaction list中保存着本事务对数据块的前映像的最新UBA，并在undo
recored中
维护着link list，用于构建数据块的一致性读。
在正常的业务处理中，rollback属于比较少的情况，所以，oracle也特别优化了机制，commit的时间会非常的快，而rollback
因为要根据linked
list顺序应用undo record，要比commit慢的多。
undo的机制相对比较复杂，这里就从两个不同的立足点去讨论
- 事务
- 表或者索引的数据块
1，事务
undo segment header包括了一般的数据块的通用结构，还包括了特殊的结构，
比如transaction table， extent
retention table。
在8k大小的数据块中，每个undo segment header中的transaction
table是有限的。比如下面的片段：
TRN TBL:: index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt ------------------------------------------------------------------------------------------------ 0x00 9 0x00 0x00f9 0x0011 0x0000.000e3357 0x008002be 0x0000.000.00000000 0x00000001 0x00000000 1326654543 0x01 9 0x00 0x00f9 0x0000 0x0000.000e3297 0x008002be 0x0000.000.00000000 0x00000001 0x00000000 1326654005 0x02 9 0x00 0x00f9 0x0006 0x0000.000e2fe0 0x008002bd 0x0000.000.00000000 0x00000001 0x00000000 1326652743 0x03 9 0x00 0x00f9 0x0008 0x0000.000e3153 0x008002be 0x0000.000.00000000 0x00000001 0x00000000 1326653343 0x04 9 0x00 0x00f9 0x002d 0x0000.000e30f3 0x008002bd 0x0000.000.00000000 0x00000001 0x00000000 1326653343 0x05 9 0x00 0x00f9 0x000c 0x0000.000e312a 0x008002be 0x0000.000.00000000 0x00000001 0x00000000 1326653343 .......
当事务为inactive状态，并且slot被重用的情况下，wrap#会向上递增。
这里有一点要注意：在oracle内容，持久化到文件的变更，db的restart都不会重置，而对于内存中的记录，比如动态性能视图，会被清除重置。
下面记录下事务的开始和结束进行的action：
1，begin transaction
2，写undo数据块变更的redo日志到redo
buffer
3，变更undo数据块，包括，选择undo segment，transaction table
entry，递增wrap#，更新state为10，即active。
4，commit
事务
5，写undo变更的redo
6，更新state为9，写入当前的scn到scn column中
7，同步等待lgwr写入完成
这里仅仅记录了在事务中，undo变化的过程。
注：在commit的时候，产生的所谓“redo commit record”，其实是undo segment header数据块变更的redo record。
在对事务的标示时，使用的是transaction id，这里唯一标识了一个事务，例如：0x0009.002.00002013
其包括：undo
segment， entry，wrap#三部分。
所以，以事务为单位，在transaction table中可以看到以下信息：
1，事务（transaction
id）的物理地址
2，事务的状态
3，事务提交的scn号
4，事务的最新的undo记录的地址
5，事务的undo记录量
查询这些信息不需要dump块，这里有一个视图x$ktuxe，但这个视图会扫描所有的undo segment header块。
select indx, ktuxesta, ktuxecfl, ktuxesqn wrap#, ktuxescnw scnW, ktuxescnb scnB, ktuxerdbf dba_file, ktuxerdbb dba_block, ktuxesiz nub from x$ktuxe where ktuxeusn = 9 and ktuxeslt <= 5
注意：在oracle的官方文档中有一句“transactions don’t share undo blocks”，这里的意思是，这个事务own这个undo块，但如果这个事务是inactive的时候，
如果还有空闲空间，可是会被其它事务所使用。当undo要被清除的时候，oracle开辟一个块大小的buffer，然后format，而并非是从文件中读取块的内容。
2，表或者索引的数据块
下面看一下构建一致性块的过程
主要存在以下两种情况：
1，当事务未commit状态的时候，使用undo信息构建一致性块内容。
2，当块中事务commit的scn比当前query的scn大，使用undo
信息构建一致性内容。
这其中存在延迟块清除的情况：即当commit的时候，为了加快commit的时间，当事务更新的块较多的时候，仅仅更新了undo segment header中的transaction table中记录的事务的状态，当后面query到这个块的时候，进行块清除，即更改itl中事务的状态。
所以构建的主要过程:
1，在buffer中克隆这个块，下面的步骤都将应用在这个块上。
2，对这个块上所以commit的事务，进行块清除。
3，回滚没有提交的事务，应用undo
record。
4，当commit的事务的scn大于query的scn时，就应用undo record。
5，重复第四步。
3，commit scn
fast commit：当事务commit的时候，仅仅修改transaction table的undo segment
header这一个块，而跟修改的数据块的数量没有关系，修改这个块的redo vector就是所谓的commit
record。
在oracle的演化过程中，oralce改变了fast commit，session memory中保存着（最多10% buffer
cache）更改的块的list，当commit的时候，就会访问这些块，进行块清除。主要包括：
1，清理lock
bytes
2，设置fsc/scn为commit的scn
3，设置commit的flag为C----
这个过程称为commit
cleanout。
注：在这个过程中，仅仅更改transaction table slot中产生了redo日志，oracle优化了commit
cleanout的过程。
其中，块的revisit并没有计入logical read，redo日志。
总结：
即：在事务的整个过程中，有两个重要的结构
1，itl
itl记录着事务的id，即txid，undo记录的地址UBA和commit
scn，如果commit scn不可用，那么可以根据txid来确定undo segment header中的transaction
table
slot中的信息，确定事务的状态，如果要构建一致性块，就根据UBA的地址找到undo record的链，回滚一致性的块内容。
2，transaction
table
slot中记录着transaction的状态，最后更新的块的undo地址和commit
scn，slot是有限的，当被重用的时候，会递增wrap#，wrap#数值是组成txid的一部分。
当事务回滚的时候，根据UBA地址，然后再undo
record中有pointer指向想一个UBA，以此来回滚整个事务。
当slot被重用的时候，前一个事务的commit
scn，uba地址会记录在下一个新事物的第一个undo record中，这样，就可以构建一致性的transaction table。
当事务根据UBA的链表查找的时候，发现当前undo record的seq#数值与当前不对，就会报出“ORA-01555”错误，说明undo块已经被重用。