Oracle 事务流程解读（事务表，事务槽）

事务表：

事务表存放在undo段头部（undo段头块），每一个undo段最多可以存放47个事务。
事务表按行存放事务记录，每行一个事务记录。
事务开始后，服务进程分配一个XID，将事务信息（XID UBA）存放在undo的段头块。

Oracle尽量一个事务使用一个回滚段，如果事务太多，会出现回滚段重用，多个事务使用同一个回滚段。并且Oracle会均匀的将事务分配在回滚段中。

查看当前事务信息
select xid,xidusn,xidslot,xidsqn,ubablk,ubafil from v$transaction ；
XID XIDUSN XIDSLOT XIDSQN UBABLK UBAFIL

06001C004B040000 6 28 1099 711 3

查看所有回滚段。
SYS@prod>Select * from v$rollname；

USN NAME

0 SYSTEM
1 _SYSSMU1_3724004606$
2 _SYSSMU2_2996391332$
3 _SYSSMU3_1723003836$
4 _SYSSMU4_1254879796$
5 _SYSSMU5_898567397$
6 _SYSSMU6_1263032392$
7 _SYSSMU7_2070203016$
8 _SYSSMU8_517538920$
9 _SYSSMU9_1650507775$
10 _SYSSMU10_1197734989$

从事务信息中可以看出，当前事务使用的是6号undo段。
找到6号undo段的段头块的位置：
SYS@prod>select header_file,header_block from dba_segments where segment_name = ‘_SYSSMU6_1263032392$’;

HEADER_FILE HEADER_BLOCK

3	     208

3号文件208块就为undo段的段头块。
可以将其转储查看事务表：
Alter system dump datafile 3 block 208

select dbms_rowid.rowid_relative_fno(rowid),dbms_rowid.rowid_block_number(rowid) block,id
from t1
DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) BLOCK ID

1	  91041 	 5
1	  91041 	 5
1	  91041 	 5

查看行数据所在数据块的位置进而转储查看数据块结构。

事务槽ITL：

事务槽存放在数据块的头部，事务修改一个数据块，需要在事务槽中记录事务信息。

XID 既是编号 又是地址。
1.使用了哪个回滚段的段头块
2.段头块使用了哪行来记录事务。
3.第几次覆盖。 （第几次循环使用）。

先简单叙述一下事务的流程：
1.开始一个事务，首先Oracle给这个事务分配XID，并找到一个回滚段，在回滚段头块将事务信息存放在事务表中，并给这个事务分配undo块，并将undo块的地址也写入事务表中（UBA地址） 。
2.事务准备修改一个数据块，在该数据块的头部的事务槽中写入事务信息（XID ，UBA（这个UBA指向相对应的undo块））。
3.开始修改数据，将数据块修改的前映像存放在undo块中。

事务表中与事务槽中的UBA是不同的：
事务表中的UBA：
事务表中的UBA是指向事务操作的最后一个undo块，同时也是事务回滚开始的位置。
rollback回滚时，根据事务表中的UBA直接定位事务回滚的起点。
并且要知道回滚块与回滚块之间是串起来。

事务槽中的UBA：
数据块中事务槽的UBA指向相对应的undo块，意义在于加快构造CR块的效率，
执行select时，服务进程如果发现该行数据正在有事务进行，且未提交，那么就会结合当前块以及undo块生成CR块（能够更加快速的找到相对应的undo块）。

事务槽中记录XID意义在于指向事务表，直接定位到事务表的位置，与Oracle提交方式有关，具体原因，后面描述。

一个DML事务开始时，需要修改的位置：
回滚段头部的事务表被修改
数据块块头部的事务槽被修改
undo块被修改
数据块的行数据被修改
（以上四种修改都会产生redo）

事务槽的数量查看：
Select ini_trans,max_trans from dba_tables where table_name = ‘T1’

事务槽的争用问题：
会话A启动第一个事务修改该数据块中的一行数据，
需要在该数据块中获取一个事务槽（未提交）
（没有提交事务槽不能被覆盖，只有事务已经提交的事务槽才可以被覆盖）

会话B启动第二个事务修改该数据块中另一行数据
也需要在该数据块中获取一个事务槽
当事务槽获取上限以后
再来一个事务修改该数据块的其他行，就需要等待事务槽释放。

解决：
可以增加pctfree减少争用
Oracle为了结局对事务槽的争用，对insert操作，Oracle会将其分布到多个块中。
但是对update 与 delete无能为力，只能增加事务槽，所以update与delete容易出现事务槽争用。

事务槽中记录XID的意义：
Oracle结合延迟块的清除实现快速提交：
如果一个事务修改了1000个块，事务信息在1001个块中存在（undo段头部块）
当事务提交时，需要在1001个块的位置将事务记录修改为已提交的状态，会很慢。

并且还可能出现一种情况事务修改了1000个块，当要提交时，已经有800个块被写入磁盘。
Oracle不可能再将这800个块重新读入磁盘，来将数据块头部事务槽中记录的事务修改为已提交状态。

Oracle延迟块清除的办法：
当事务提交时，Oracle仅更新undo段头的事务信息，根据buffer的数量，并且仅会更新部分buffer，剩余buffer Oracle会在下次读取这些数据块时清除事务记录。

所以说 数据块中事务槽记录未必准确， 如果数据块中事务槽记录的事务未提交，Oracle还需要根据事务槽头部的XID去undo段头事务表来进一步判断事务是否提交，如果undo段头事务表记录该事务已经提交，那么Oracle会选择相信undo段头，进而修改数据块，并且将上一个事务的事务槽中的事务记录修改为已提交。

Oracle的多种提交方式：
事务修改的数据块少时：
事务提交时
修改undo段头记录的事务状态
修改数据块头部事务槽中记录的事务状态
修改数据行标志（事务槽编号，指向事务槽，就是Oracle行级锁）

事务修改的块一般多时：
事务提交时
会将undo段头的事务表以及数据块头部的事务槽中的事务状态修改为已提交。
数据行标记（行锁）会在下次select访问时清锁。
（这也是有时select也会产生redo日志的原因）

事务修改的块很多时：
当事务提交时
仅会修改undo段头的记录。
事务槽，数据行标记（行锁）在下次select访问时修改清锁。

另一种情况：
如果一个数据块长时间未被读入到buffer cache，而且数据块事务槽以及锁还未清除，如果此时读取，服务进程会去undo段头的事务表中判断事务是否已经提交，但是服务进程读取undo段头的事务表时发现，事务表已经被覆盖15次，此时Oracle会认定事务已经提交，因为事务未提交在事务表中不可能被覆盖，然后服务进程清除该数据块事务槽的记录，清除数据块行锁。

Select流程总结：
（数据块中每行数据都会有指向事务槽的标记）
当客户端执行select查询时，服务进程接收请求，将符合要求的数据块读入到buffer cache中，服务进程会先去读取数据块中的行。
如果数据块的行上有事务槽标记（行锁）,服务进程会去事务槽中查看该事务槽中记录的事务是否已经提交。（由于快速提交，延迟块清除原则，锁信息并不代表事务情况）
如果事务槽中记录的事务已经提交，那么服务进程会清除数据块中这行记录的事务槽标记（行锁），直接读取该行数据。
如果事务槽中记录的事务没有提交，Oracle会产生怀疑，服务进程会根据事务槽中的XID去undo段头部中的事务表中读取事务状态（事务槽中记录XID的意义）。
如果事务表中的事务状态为已提交，那么服务进程会认定这行数据所对应的事务已经提交，清空行标记，将事务槽中未提交状态修改为已提交。
如果事务表中的事务状态为未提交，那么Oracle会认定该数据块中行对应的事务未提交，此时服务进程就会根据当前块中的行数据来结合undo块来构造CR块，用于一致性读。

Update流程总结：
简单的说，就是如果该行数据有事务正在进行，那么就需要等待
如果该行数据没有事务正在进行，那么就正常修改。
Oracle两个事务可以同时修改一个数据块，只要行不冲突即可。行级锁的并发性