Oracle中关于事务槽.ppt

Oracle的每个数据块中都有一个或者多个事务槽，每一个对数据块的并发访 问事务都会占用一个事务槽。 表和索引的事务槽ini_trans是1、max_trans是255，在oracle10g中，不能修改 max_trans这个参数，因为oracle10g忽略了这个参数。 我们来看一下oracle的事务槽的使用情况： 六行数据全部插入到了一个数 据块中。 select id,dbms_rowid.rowid_relative_fno(rowid) file#, dbms_rowid.rowid_block_number(rowid) block# from t10 / 另起两个会话，一共三个事务正在访问这个表。 其中两个会话访问一个数据块，一个 会话访问一个数据块。 在一个会话将会 使用一个新的数 据块。 在一个会话将会 使用一个新的数 据块。 Oracle为了防止itl的争用，采取了一些技术： 1、如果是insert，默认每个表的ini_trans itl是2，尽量保持这个数据块的事务 数不超过2，采用在多个数据块中插入的情况。这样将insert分布到多个数据 块中，防止了itl的争用。 两个事务槽都被占用。 结论：对于insert来说，oracle采用的是多数据块分布插入的方式， 2、对于update来说， 三个会话同时修改一个数据块。 事务槽自己增加到了3个。 因为max_trans是255，因此发生itl争用的几率也很小。 因此基于上面的两种情况来说，ITL发生争用的几率很小。 我们来分析一下数据块dump的结果： 最后一次对数据块进 行cleanout的SCN ITL数量 Xid：事务id，在回滚段事务表中有一条记录和这个事务对应 Uba：回滚段地址，该事务对应的回滚段地址 第一段地址：回滚数据块的地址，包括回滚段文件号和数据块号 第二段地址：回滚序列号 第三段地址：回滚记录号 Flag：事务标志位。这个标志位就记录了这个事务的操作，各个标志的含义分别是： C- = transaction has been committed and locks cleaned out -B- = this undo record contains the undo for this ITL entry -U- = transaction committed (maybe long ago); SCN is an upper bound -T = transaction was still active at block cleanout SCN Scn/Fsc：快速提交（Fast Commit Fsc）的SCN或者Commit SCN。 每条记录中的行级锁对应Itl条目lb，对应于Itl列表中的序号，即那个事务在该记录上 产生的锁。 1表示data 2表示index 这个事务在这个块上影响的 行数。 这个事务提交以后，将会 释放的字节数。 事务已经提交， 锁已经cleanout 事务是活动的 锁定标记还没有消除。事务已经提交，但 是还没有发生块清 除。 Flags -：事务是活动的，或者在块清除前提交事务。 C-：事务已经提交并且清除了行锁定。 -U-：事务已经提交（SCN已经是最大值），但是锁定还没有清除（快速清除）。 -T：当块清除的SCN被记录时，该事务仍然是活动的，块上如果有已经提交的事务 ，那么在clean ount的时候，块会被进行清除，但是这个块里面的事务不会被清除。 C-U-：块被延迟清除，回滚段的信息已经改写，SCN显示为最小的SCN，需要由由回 滚段重新生成，例如在提交以前，数据块已经flush到数据文件上。 Oracle的两种提交方式： 1、快速提交 2、延迟提交 块清除即清除数据块上与“锁定”有关的信息。Oracle的锁机制是一种轻量级的锁定 机制，不是通过构建锁列表来进行数据的锁定管理，而是直接将锁作为数据的属 性，存储在数据块首部。因此，每次访问数据时都要去看数据块头部的锁，如果 数据已经提交，则可能需要清理这个块，换句话说，要将这些事务信息删除。因 此这个动作就会生成redo。 事务槽（事务、是否提交、锁定）事务表（事务、是否提交） Cleanout有2种，一种是fast commit cleanout（提交清除）,另一种是delayed block cleanout（延迟清除）. 提交清除是如何工作的？ Oracle会记录已修改的块列表，这些列表可以有20个块，Oracle根据需要分配 多个这样的列表，但是如果这些修改的块加起来超过buffer_cache的10%， oracle就停止分配这样的列表，因此当提交时就只会清理最多10%buffer_cache 的数据块，其余的部分就延迟清除，这样也是为了提高commit的效率。 还有一种情况，就是当事务还未commit时，修改的数据块已经写入硬盘，当 发生commit时oracle并不会把block重新读入做cleanout，而是把cleanout留到下 一次对此块的访问是完成。 注意：对于Oracle来说，对于一个事务，可以是快速提交、也可以是延迟提交。 目的都是为了提高提交的速度。 提交以后，oracle需要对ITL事务槽、每一行的锁定标记进行清除。 如果是快速提交，那么在提交的时候，会将事务表和每一个数据块的ITL槽进行 清除。但是锁定标记可能没有清除，等下次用到的时候再进行清除。 如果是延迟提交，那么在提交的时候，只是将事务表进行清除，并没有对ITL事 务槽进行清除，每一行的锁定标记也没有清除。 因此C和U的情况特别多。 块清除的过程并不包括每个行的锁定标记的清除，主要指的是ITL的清除。 跟踪块清除： UBAFIL：回滚段文件号； UBABLK：数据块号； UBASQN：回滚序列号； UBAREC：回滚记录号。 这些数据就对应了数据块中的Uba。 declare v_file number; v_block number; begin v_file := dbms_utility.data_block_address_file(to_number(0080213c,xxxxxxxx); v_block := dbms_utility.data_block_address_block(to_number(0080213c,xxxxxxxx); dbms_output.put_line(file id: |v_file); dbms_output.put_line(block id: |v_block); end; / 回滚段事务表数据块 1、事务槽中首先记录的是Xid和Uba，只有在提交以后，当对这个数据块进 行cleanout的时候，才会更新Flag和Scn。因此Oracle总是以事务表中对这个 数据块的Scn以及Flag为准。 2、一个事务开始以后，在一个数据块上得到一个事务槽，那么在这个事务 提交以前，这个事务槽会一直占用，直到这个事务提交释放这个事务槽。 3、只有在已经提交以后，这个itl事务槽中的scn才会有数值。 4、一个事务在一个数据块上占用一个事务槽 回滚段 回滚段 数据块 回滚段 回滚段 回滚段事务表 1、事务是否已经提交、事务对应的SCN，这些信息都是以回滚段事务表 中的为主，事务槽中的不准确 2、事务槽中的事务id和uba地址是准确的 3、事务槽1中的事务id和回滚段中的事务id肯定不是一样的，不同回滚段 中的事务id也一定不一样。 4、每一个回滚段块中都有一个事务id，记录哪个事务正在使用这个块。 5、回滚事务表可能被覆盖，回滚段也可能被覆盖 对于前者，我们需要增加回滚段 对于后者，我们需要增大回滚段 回滚段也是循环使用的，只有活动的回滚段不会被覆盖 select id,dbms_rowid.rowid_relative_fno(rowid) file#, dbms_rowid.rowid_block_number(rowid) block# from t12 / 只有一个current块。 什么时候会产生cr块呢？ 另起一个会话，不会产生cr块。 另起一个会话，开始一个事务 同一个会 话，没有 提交 还是没有产生一个cr块。 启动第三个会话，查询 产生一个cr块。 启动第四个会话，再次查询。 又产生一个cr块。 虽然第三个和第四个会话一样，但是scn不一样。 连续开启多个会话，但是最终oracle只能开启