Oracle中关于事务槽.pptVIP

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的数据块，其余的部分就延迟清除，这样也是为了提