enq: TX - row lock/index contention、allocate ITL等待事件

左手的ㄟ右手 2022-04-10 09:17 161阅读 0赞

SQL> select name from v$event\_name where name like '%TX%'; NAME \---------------------------------------------------------------- enq: TX - row lock contention enq: TX - allocate ITL entry enq: TX - index contention enq: TX - contention enqueue TX事务锁 transaction enqueue，顾名思义这个队列锁用来保护事务信息。 当进程修改某块中的一行数据，则Oracle必须将该事务信息与被改变的这一行联系起来，做法是在块中的row piece的lk上标记ITL位，而实际的ITL记录了这个事务相关的回滚段号USN，以便能够定位其撤销链。 这样做的目的有几个：

1.  允许用户手动rollback或者因为dead transaction的发生而后台(PMON or SMON 取决于\_cleanup\_rollback\_entries)回滚该事务。
2.  在块中留下Undo线索，才能让查询者Queryer顺藤摸瓜去构造这个块在事务发生前的镜像块

绝大多数情况下 ,TX enqueue的申请、获得模式总是排他的exclusive的即mode=6/request=6的(v$LOCK)，这通常意味着我们的DML操作所感兴趣的数据行正被其他事务锁定着， 但这并不绝对。 有场景中我们会以共享模式Share mode=4/request=4(V$LOCK)去申请、获得TX enqueue锁； 一种场景是进程仅仅先需要申请到数据块(data block包括table/index)上的 ITL(interested transaction lists)事务槽。 以share mode等待(request=4)TX enqueue 的一种可能就是块上无法再扩展本进程所需要的一个ITL了，要么这个块上的ITL 超过MAXTRANS(255)ITL的上限值了，要么是这个块没有更多的空间来容纳更多一个ITL了，(一个ITL 24字节)。 若争用contention缘起于排他的exclusive TX队列申请，则表明有并发事务试图锁住同一行数据。 大多数情况下这是由于应用引起的。 [实际上log file sync(其实是写redo慢)也会造成buffer busy wait。][log file sync_redo_buffer busy wait] 若争用contention缘起于共享shared TX 队列申请，则有可能是一个或多个数据块无法扩展事务表所导致的。在这种情况下可以考虑增加更大的INITTRANS来解决问题： 对于该问题建议做10046 level 8+ buffer cache dump配合V$SESSION fileid/blockid/objno来诊断问题。 从版本9iR2开始可以通过动态性能视图的V$SEGMENT\_STATISTICS来判断对象是否经历ITL 等待 ，但是实例参数 STATISTICS\_LEVEL必须设置为typical 以上，可以参考statspack中segment by ITL的环节，当然AWR里也有类似的信息： select owner, object\_name from v$segment\_statistics where statistic\_name = 'ITL waits' and value > 0; **TX锁的 ID1/ID2解释** ID1 是用来存放 USN==> Undo Segment Number以及相关的undo segment transaction slot，通过以下转换获得： (undo\_segment\_number << 16) + slot ID2是事务槽位序列号 transaction slot sequence number 或曰wrap number。 另外一些以共享模式share mode mode=4/request=4(V$LOCK)去申请、获得TX enqueue锁的场景：

1.  等待块上的ITL slot
2.  由于主键、唯一索引约束而等待
3.  由于位图索引bitmap index而等待
4.  因为2 phase commit，2段提交而等待

其他的一些官方调优手册中也提出了一些可能引起TX V$LOCK. lmode/request =4的shared lock contention的情况：

*  当2个session试图向一个unique index插入同一个索引键值时，后插入的那个session如此等待，知道先插入的session commit/rollback，则后一个session对应的ORA-0001或插入成功。
 *  当一个session因为bitmap index fragment而等待。位图索引bitmap index是一些索引键值加上ROWID的范围。位图索引中的每一条记录可以映射为实际表上的多条记录。 若2个session试图更新的行映射到同样的位图索引记录，则后者的session需要在前者commit/rollback之前一直等request=4的TX lock。
 *  当等待一个PREPARED transaction时也会出现mode 4的TX
 *  还有就是使用dbms\_repair时也可能看到mode 4的TX

**一些相关的BUG** Bug 3159414 documents another case where we might see a TX request in mode 4 when constraints are involved. Bug 5849679 documents an undetected deadlock case with RAC. Occurs when attempting to access a row that is locked in exclusive mode. more... Solutions 1) Waits due to row locked by an active transaction See if certain jobs can be run at other times; Investigate application code problems such as commits occurring later than necessary or unnecessary repetitive updates. 2) Waits due to Unique or Primary Key Constraint enforcement A possible, but risky solution is to drop the constraint and possibly check constraints at a later point (perhaps via a batch job). 3) Waits due to Insufficient 'ITL' slots in the Block(INITRANS and MAXTRANS) Increase the INITRANS and MAXTRANS (9i and below) settings 4) Waits due to rows being covered by the same BITMAP index fragment Rebuild index Compressed Indexes Expanded Definition A TX lock is acquired exclusive (X) when a transaction initiates its first change and is held until the transaction does a COMMIT or ROLLBACK. This ensures a read consistent image of the block before the transaction started. It is used mainly as a queuing mechanism so that other sessions can wait for the transaction to complete.

[log file sync_redo_buffer busy wait]: http://www.askmaclean.com/archives/why-slow-redo-write-cause-buffer-busy-wait.html