20161208理解enq TX - row lock contention

[20161208]理解enq TX - row lock contention.txt

>SELECT * FROM v$event_name WHERE name = 'enq: TX - row lock contention';

EVENT#   EVENT_ID NAME                          PARAMETER1  PARAMETER2      PARAMETER3 WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS
------ ---------- ----------------------------- ----------- --------------- ---------- ------------- ----------- --------------------
   241  310662678 enq: TX - row lock contention name|mode   usn<<16 | slot  sequence      4217450380           1 Application

--同事不理解P1,P2,P3的含义,做一个例子说明一下:

1.环境:
SCOTT@book> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

create table deptx as select * from dept;
SCOTT@book> select * from deptx ;
    DEPTNO DNAME          LOC
---------- -------------- -------------
        10 ACCOUNTING     NEW YORK
        20 RESEARCH       DALLAS
        30 SALES          CHICAGO
        40 OPERATIONS     BOSTON

2.测试:

--session 1:
SCOTT@book(232,11)> update deptx set dname='A' where deptno=10;
1 row updated.

--session 2:
SCOTT@book(62,199)> update deptx set loc='B' where deptno=10;

--挂起!

SCOTT@book> @ &r/viewlock

   SID    SERIAL# USERNAME   OSUSER     MACHINE    MODULE       LOCK_TYPE       MODE_HELD  MODE_REQUE LOCK_ID1   LOCK_ID2   OWNER  OBJECT_TYP OBJECT_NAME          BLOCK LOCKWAIT
------ ---------- ---------- ---------- ---------- ------------ --------------- ---------- ---------- ---------- ---------- ------ ---------- -------------------- ----- --------------------
    62        199 SCOTT      oracle     gxqyydg4   SQL*Plus     TM DML(TM)      Row-X (SX) None       89351      0          SCOTT  TABLE      DEPTX                No    00000000851E9C50
    62        199 SCOTT      oracle     gxqyydg4   SQL*Plus     TX Transaction  None       Exclusive  589843     26935                                             No    00000000851E9C50
   232         11 SCOTT      oracle     gxqyydg4   SQL*Plus     TX Transaction  Exclusive  None       589843     26935                                             Yes
   232         11 SCOTT      oracle     gxqyydg4   SQL*Plus     TM DML(TM)      Row-X (SX) None       89351      0          SCOTT  TABLE      DEPTX                No

SCOTT@book> @ &r/wait
P1RAW            P2RAW            P3RAW                    P1         P2         P3    SID    SERIAL#       SEQ# EVENT                                    STATE               WAIT_TIME_MICRO SECONDS_IN_WAIT
---------------- ---------------- ---------------- ---------- ---------- ---------- ------ ---------- ---------- ---------------------------------------- ------------------- --------------- ---------------
0000000062657100 0000000000000001 00               1650815232          1          0     73         57         36 SQL*Net message to client                WAITED SHORT TIME                 2               0
0000000054580006 0000000000090013 0000000000006937 1415053318     589843      26935     62        199         40 enq: TX - row lock contention            WAITING                    94270097              94

3.如何理解参数P1,P2,P3:

--回到session 1:

SCOTT@book(232,11)> @ &r/xid
XIDUSN_XIDSLOT_XIDSQN
------------------------------
9.19.26935

C70                                                                        XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK     UBASQN     UBAREC STATUS            USED_UBLK  USED_UREC XID              ADDR             START_DATE
---------------------------------------------------------------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- ---------- ---------- ---------------- ---------------- -------------------
ALTER SYSTEM DUMP UNDO BLOCK '_SYSSMU9_1650507775$' XID 9 19 26935;             9         19      26935          3      14571       1375         15 ACTIVE                    1          1 0900130037690000 00000000818B4670 2016-12-08 15:06:04
ALTER SYSTEM DUMP UNDO HEADER '_SYSSMU9_1650507775$';
ALTER SYSTEM DUMP DATAFILE 3 BLOCK 14571;

--P3=26935,对应的事务的XIDSQN.

--P2=589843.
select 589843,trunc(589843/65536) XIDUSN,mod(589843,65536)  XIDSLOT from dual
    589843     XIDUSN    XIDSLOT
---------- ---------- ----------
    589843          9         19

--从这里可以看出前16位就是XIDUSN,后16位就是XIDSLOT.

4.剩下P1=1415053318.

--name|mode??

select 1415053318,trunc(1415053318/65536) XIDUSN,mod(1415053318,65536)  XIDSLOT from dual
1415053318     XIDUSN    XIDSLOT
---------- ---------- ----------
1415053318      21592          6

--表示mode=6

SCOTT@book> @ &r/10to16 21592
10 to 16 HEX   REVERSE16
-------------- ------------------
0000000005458 0x58540000

SCOTT@book> @ &r/16to10 54
16 to 10 DEC
------------
          84

SCOTT@book> @ &r/16to10 58
16 to 10 DEC
------------
          88

SCOTT@book> select chr(84)||chr(88) c10 from dual ;
C10
----------
TX
--表示name='TX'.

从这个视图也可以看出来:

SCOTT@book> select * from v$lock where type='TX';
ADDR             KADDR               SID TYPE      ID1        ID2      LMODE    REQUEST      CTIME          BLOCK
---------------- ---------------- ------ ----- ------- ---------- ---------- ---------- ---------- --------------
00000000851E9BF8 00000000851E9C50     62 TX     589843      26935          0          6        634              0
00000000818B4670 00000000818B46E8    232 TX     589843      26935          6          0        675              1

--这里ID1,ID2对应就是前面的P2,P3.

时间: 2024-11-09 00:10:00

20161208理解enq TX - row lock contention的相关文章

ORACLE等待事件:enq: TX - row lock contention

enq: TX - row lock contention等待事件,这个是数据库里面一个比较常见的等待事件.enq是enqueue的缩写,它是一种保护共享资源的锁定机制,一个排队机制,先进先出(FIFO).enq: TX - row lock contention等待事件,OACLE将其归类为application级别的等待事件.有些场景是因为应用逻辑设计不合理造成的.下面我们看看enq: TX - row lock contention的英文介绍: This wait indicates ti

【故障处理】队列等待之enq: TX - row lock contention

[故障处理]队列等待之enq: TX - row lock contention 1  BLOG文档结构图   2  前言部分 2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① enq: TX - row lock contention等待事件的解决 ② 一般等待事件的解决办法 ③ 队列等待的基本知识 ④ ADDM的使用 ⑤ 如何获取历史执行计划 ⑥ 查询绑定变量的具体值 ⑦ 很多有用的查询性能的SQL语句

ORACLE AWR结合ASH诊断分析enq: TX - row lock contention

  公司用户反馈一系统在14:00~15:00(2016-08-16)这个时间段反应比较慢,于是生成了这个时间段的AWR报告,   如上所示,通过Elapsed Time和DB Time对比分析,可以看出在这段时间内服务器并不繁忙.分析Top 5 Timed Events,我们可以看到前五的等待事件     可以看到等待事件enq: TX - row lock contention占了所有等待事件17.3%的比例,猜测有可能是锁等待(enqueue等待)引起的阻塞导致,但是这个还不能下定论,因为

ORACLE 归档空间满导致的enq: TX - row lock contention

  2016年10月10日,客户一预警系统发生会话数飙高,系统响应极慢,后来确诊根源是归档空间满,引起所有redo耗尽,导致会话堆积,下面是处理过程.  操作系统:HP-UX B.11.31 U ia64  数据库版本:ORACLE 10.2.0.5 RAC  按照常规处理思路,首先查看RAC数据库的告警日志:  实例1的告警日志 Mon Oct 10 19:24:48 EAT 2016 ORACLE Instance orcl1 - Can not allocate log, archival

Oracle中row lock contention的性能故障

这是一套Windows RAC的环境,也是之前处理  解决一则row cache lock引起的性能故障 那套环境.下面记录一下处理的经过: 1 对这一个小时进行AWR的收集和分析,首先,从报告头中看到DB Time达到近500分钟,(DB Time)/Elapsed=8,这个比值偏高: 2 再看TOP 5事件: 看到排在第一位的是enq: TX – row lock contention事件,也就是说系统中在这一个小时里产生了较为严重的行级锁等待事件. Top 5 Timed Events 通

[20151208]关于Oracle Row Lock.txt

[20151208]关于Oracle Row Lock.txt --参考链接 https://blogs.oracle.com/askmaclean/entry/know_more_about_oracle_row 大家都知道如何2个用户修改相同的记录,会出现enq: TX – row lock contention,另外一个用户会等待前面的用户修改的提交或者回 滚,如果不提交,该用户会一直等待,除非前面的用户给kill或者执行commit,rollback操作.而我们都知道在Oracle中实现

【MOS】 Troubleshooting waits for enq: TX - allocate ITL entry(1472175.1)

Troubleshooting waits for 'enq: TX - allocate ITL entry' (文档 ID 1472175.1) In this Document Symptoms Cause Solution   Increase INITRANS   Increase PCTFREE   A Combination of increasing both INITRANS and PCTFREE References APPLIES TO: Oracle Database

oracle数据库enq: TX - allocate ITL entry性能诊断

朋友公司的某铁路集团医保系统出现性能问题业务不能正常办理,下面是出现性能问题时的awr报告 从等待事件来看主要是出现了多处锁竞争.其中enq: TX - allocate ITL entry等待事件是由于缺省情况下创建的表的INITRANS参数为1,索引的INITRANS参数值为2.当有太多的并发DML操作同时操作相同的数据块或索引块就会出现这个等待事件,可以通过查看Segments by ITL Waits部分的信息来了解出现大量并发DML操作的对象 从下面的信息可以看出消耗时间最长的语句都是

TX:ITL LOCK(INITRANS,MAXINTRANS)

今天和老周老肖吃饭之于谈论了一个问题,就是INITRANS,MAXINTRANS对高并发量的数据块的影响.大家都知道在进行大量DML对同一个块的时候(不同行),不会出现TX:ROW LOCK,但是由于ITL的限制这样的操作可能出现TX:ITL LOCK(MODE=4),以前我遇到过各种TX TM,但是ITL确实没有遇到过,我记得10G的不管ASSM还是MSSM都是默认的最打MAXTRANS为255,所以没怎么关注,因为如果要达到这个值需要255个TRANSACTION对同一个块进行修改,基本不可