ITPub博客

首页 > 数据库 > Oracle > Oracle 事务流程分析

Oracle 事务流程分析

原创 Oracle 作者:DBhanG 时间:2020-07-11 21:12:33 0 删除 编辑

事务表:
事务表存放在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;
 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两个事务可以同时修改一个数据块,只要行不冲突即可。行级锁的并发性

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69975956/viewspace-2703948/,如需转载,请注明出处,否则将追究法律责任。

全部评论

注册时间:2020-05-28

  • 博文量
    45
  • 访问量
    17251