ITPUB论坛-中国最专业的IT技术社区

 
 注册
热搜:
查看: 886|回复: 2

[原创] 如何看懂死锁trace文件定位死锁成因

[复制链接]
论坛徽章:
7
娜美
日期:2017-06-26 15:18:15目光如炬
日期:2017-08-20 22:00:00目光如炬
日期:2017-08-27 22:00:01火眼金睛
日期:2017-09-01 17:00:07目光如炬
日期:2017-09-03 22:00:01火眼金睛
日期:2017-09-30 22:00:01目光如炬
日期:2017-11-26 22:00:00
跳转到指定楼层
1#
发表于 2017-11-20 14:54 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
目前就职海天起点,服务于电力行业,致力于帮助客户解决生产过程中出现的问题,提高生产效率, 爱好书法,周易!愿结交志同道合之士!共同进步! 微信号:sunyunyi_sun



系统发生死锁应该如何正确快速找出原因,这个问题经常困扰DBA,因为死锁一旦发现orale自动清除阻塞者,
所以很难从相关视图中查找有用信息,而大部分DBA不善于分析trace文件内容,因为trace文件很难看懂呀!
其实不然,当我们养成了看trace的习惯你会发现oracle trace 文件很详细而且很容易看懂,oracle各种trace
报告dump文件都是一样的,最近客户遇到了大量的死锁问题导致应用大量报错,我模拟TX 死锁类型,讲解
如何看懂死锁trace文件内容。

这里只测试TX在RAC环境的死锁,至于单实例trace很好看懂,里面详细列出了等待着和阻塞者的信息。另外
其他类型的死锁测试大家可以自己构建,比如典型的位图死锁,ITL死锁,外键无索引死锁。

实验环境:11.2.0.4 RAC LINUX 5.8

1. TX deadlock in Exclusive(X) mode

node2:
create table tbdl (id number,name varchar2(200))
/
insert into tbdl values(1,'a')
/
insert into tbdl values(2,'b')
/
insert into tbdl values(3,'c')
/
commit
/

node2 session1:
select sid from v$mystat where rownum<2;

select s.sid,s.SERIAL#,s.saddr,p.pid,p.spid from v$process p,v$session s
where s.paddr = p.addr
and s.sid=
(select sid from v$mystat where rownum<2)
/

       SID    SERIAL# SADDR                   PID SPID
---------- ---------- ---------------- ---------- ------------------------
      1146      34903 00000000EFC07780         34 19635

update tbdl set name='sb' where id=2;

node1 session2:

     SID    SERIAL# SADDR                   PID SPID
---------- ---------- ---------------- ---------- ------------------------
        15      14837 00000000F0D9B7E0         44 29988

update tbdl set name='la' where id=1;

node2:
update tbdl set name='sa' where id=1;

node1:
update tbdl set name='lb' where id=2;

node2:
SQL> update tbdl set name='sa' where id=1;
update tbdl set name='sa' where id=1
       *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource

node1:
waiting

全局事物:
select s.INST_ID,s.sid,p.spid,s.SQL_ID,t.XIDUSN,t.XIDSLOT,t.XIDSQN,t.STATUS
from gv$session s,gv$process p,gv$transaction t
where
s.INST_ID=p.INST_ID
and p.INST_ID=t.INST_ID
and s.PADDR=p.ADDR
and s.TADDR=t.ADDR
/

Inst
id    SID SPID                     SQL_ID              XIDUSN    XIDSLOT     XIDSQN STATUS
---- ----- ------------------------ --------------- ---------- ---------- ---------- ----------
   2  1146 19635                    f45a3usq403ws            7         31     108110 ACTIVE
   1    15 29988                    f28tgjwt4s0qm           11         28     110592 ACTIVE

死锁过程:
1:node2 lock ID=2  持有ID=2 TX
2:node1 lock ID=1  持有ID=1 TX

3:node2 req lock ID=1  NODE1持有ID=1 TX,NODE2 等待ID=1 tx
4:node1 req lock ID=2  NODE2持有ID=2 TX,NODE1 等待ID=2 tx

死锁产生,oracle 撤销第三步 node2 req lock ID=1 操作。


我们分析trace文件,因为当业务发生死锁时oracle自动解除死锁,我们只能看到trace文件内容,
所以必须要读懂trace文件

Global Enqueue Services Deadlock detected. More info in file
/u01/app/oracle/diag/rdbms/pmssn/pmssn_2/trace/pmssn_2_lmd0_1230.trc.

trace文件开始打印阻塞者的信息,因为node1第四步最终导致了死锁,
node2是阻塞者,下面就是阻塞者node2的信息。


*** 2017-11-20 08:43:19.185
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0x7001f][0x1a64e],[TX][ext 0x0,0x0]
注释:
这里首先dump 本地BLOCKER/HOLDER:本地阻塞者,[0x7001f][0x1a64e],[TX] 是节点2的事物xid
以前文章讲过enqueue的结构,eq是由资源和lock队列组成,下面首先是资源信息,后面对应lock信息主要持有者和转换者列表。

----------resource 0xecb1aeb8----------------------资源
resname       : [0x7001f][0x1a64e],[TX][ext 0x0,0x0] --资源名,前面就是事物的XID号,对应UNDO段solt和seq
hash mask     : x3
Local inst    : 2
dir_inst      : 2
master_inst   : 2
hv idx        : 65
hv last r.inc : 2
current inc   : 12
hv status     : 0
hv master     : 1
open options  : dd
grant_bits    : KJUSERNL KJUSEREX
grant mode    : KJUSERNL  KJUSERCR  KJUSERCW  KJUSERPR  KJUSERPW  KJUSEREX
count         : 1         0         0         0         0         1
val_state     : KJUSERVS_NOVALUE
valblk        : 0x000000000000000000000000a17f0000 .
access_inst   : 2
vbreq_state   : 0
state         : x0
resp          : 0xecb1aeb8
On Scan_q?    : N
Total accesses: 62
Imm.  accesses: 59
Granted_locks : 1
Cvting_locks  : 1
value_block:  00 00 00 00 00 00 00 00 00 00 00 00 a1 7f 00 00
GRANTED_Q :持有链表,持有tx锁
lp 0xea2111e8 gl KJUSEREX rp 0xecb1aeb8 [0x7001f][0x1a64e],[TX][ext 0x0,0x0]
  master 2 gl owner 0xefc07780 possible pid 19635 xid 22000-0002-00006521 bast 0 rseq 4 mseq 0
  history REM_AST > REM_AST > MSGSENT > FREE > REF_RES > LOC_AST
  open opt KJUSERDEADLOCK  
CONVERT_Q: 转换列表
lp 0xea211758 gl KJUSERNL rl KJUSEREX rp 0xecb1aeb8 [0x7001f][0x1a64e],[TX][ext 0x0,0x0]
  master 2 owner 1  bast 1 rseq 8 mseq 0x1
  history MSGSENT > FREE > REF_RES > REM_AST > GR2CVT > MSGSENT
  convert opt KJUSERGETVALUE  
----------enqueue 0xea2111e8------------------------lock详细信息
lock version     : 31
Owner inst       : 2
grant_level      : KJUSEREX
req_level        : KJUSEREX
bast_level       : KJUSERNL
notify_func      : (nil)
resp             : 0xecb1aeb8
procp            : 0xec28dd18
pid              : 1230
proc version     : 0
oprocp           : (nil)
opid             : 1230
group lock owner : 0xefc07780
possible pid     : 19635
xid              : 22000-0002-00006521
dd_time          : 0.0 secs
dd_count         : 0
timeout          : 0.0 secs
On_timer_q?      : N
On_dd_q?         : N
lock_state       : GRANTED ---已经持有TX
ast_flag         : 0x0
Open Options     : KJUSERDEADLOCK
Convert options  : KJUSERNOQUEUE KJUSERNODEADLOCKWAIT
History          : REM_AST > REM_AST > MSGSENT > FREE > REF_RES > LOC_AST
Msg_Seq          : 0x0
res_seq          : 4
valblk           : 0x00000000000000000100000000000000 .

user session for deadlock lock 0xea2111e8
注释:这一块就是阻塞者session信息和当前执行的SQL语句:
从hash value值可以看出下面这部分信息是相同的
  sid: 1146 ser: 34903 audsid: 2840406 user: 86/USER_SUN
    flags: (0x41) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40009) -/-/INC
  pid: 34 O/S info: user: grid, term: UNKNOWN, ospid: 19635
    image: oracle@pmsup1 (TNS V1-V3)
  client details:
    O/S info: user: grid, term: pts/0, ospid: 19615
    machine: pmsup1 program: sqlplus@pmsup1 (TNS V1-V3)
    application name: SQL*Plus, hash value=3669949024
  current SQL:
  update tbdl set name='sa' where id=1
DUMP LOCAL BLOCKER: initiate state dump for DEADLOCK
  possible owner[34.19635] on resource TX-0007001F-0001A64E

*** 2017-11-20 08:43:19.255
Submitting asynchronized dump request [1c]. summary=[ges process stack dump (kjdglblkrdm1)].
----------enqueue 0xea211758------------------------
lock version     : 29
Owner inst       : 1
grant_level      : KJUSERNL
req_level        : KJUSEREX
bast_level       : KJUSERNL
notify_func      : 0x533cc6e
resp             : 0xecb1aeb8
procp            : 0xec2a0d80
pid              : 0
proc version     : 216
oprocp           : (nil)
opid             : 0
group lock owner : (nil)
xid              : 0000-0000-00000000
dd_time          : 0.0 secs
dd_count         : 0
timeout          : 0.0 secs
On_timer_q?      : N
On_dd_q?         : N
lock_state       : GRANTED
ast_flag         : 0x0
Open Options     :  KJUSERNO_XID
Convert options  : KJUSERGETVALUE
History          : MSGSENT > FREE > REF_RES > REM_AST > GR2CVT > MSGSENT
Msg_Seq          : 0x1
res_seq          : 8
valblk           : 0x000000000000000040b6980a00000000 .@

Global blockers dump start:---------------------------------
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0xb001c][0x1b000],[TX][ext 0x0,0x0]
----------resource 0xecf16b18----------------------
resname       : [0xb001c][0x1b000],[TX][ext 0x0,0x0]
hash mask     : x3
Local inst    : 2
dir_inst      : 1
master_inst   : 1
hv idx        : 112
hv last r.inc : 12
current inc   : 12
hv status     : 0
hv master     : 0
open options  : dd
Held mode     : KJUSERNL --没有锁
Cvt mode      : KJUSEREX --请求转换为EX LOCK
Next Cvt mode : KJUSERNL
msg_seq       : 0x1
res_seq       : 7
grant_bits    : KJUSERNL
grant mode    : KJUSERNL  KJUSERCR  KJUSERCW  KJUSERPR  KJUSERPW  KJUSEREX
count         : 1         0         0         0         0         0
val_state     : KJUSERVS_NOVALUE
valblk        : 0xd0ae7590fc7f0000ac08c90900000000 .u
access_inst   : 1
vbreq_state   : 0
state         : x8
resp          : 0xecf16b18
On Scan_q?    : N
Total accesses: 82
Imm.  accesses: 73
Granted_locks : 0
Cvting_locks  : 1
value_block:  d0 ae 75 90 fc 7f 00 00 ac 08 c9 09 00 00 00 00
GRANTED_Q :
CONVERT_Q:
lp 0xea800c78 gl KJUSERNL rl KJUSEREX rp 0xecf16b18 [0xb001c][0x1b000],[TX][ext 0x0,0x0]
  master 1 gl owner 0xefc07780 possible pid 19635 xid 22000-0002-00006521 bast 0 rseq 7 mseq 0
  history LOC_AST > CLOSE > FREE > REF_RES > MSGSENT > GR2CVT
  convert opt KJUSERGETVALUE  
----------enqueue 0xea800c78------------------------
lock version     : 605847
Owner inst       : 2
grant_level      : KJUSERNL
req_level        : KJUSEREX
bast_level       : KJUSERNL
notify_func      : (nil)
resp             : 0xecf16b18
procp            : 0xec2a1970
pid              : 19635
proc version     : 6920
oprocp           : (nil)
opid             : 19635
group lock owner : 0xefc07780
possible pid     : 19635
xid              : 22000-0002-00006521
dd_time          : 10.0 secs
dd_count         : 1
timeout          : 0.0 secs
On_timer_q?      : N
On_dd_q?         : Y
lock_state       : OPENING CONVERTING
ast_flag         : 0x0
Open Options     : KJUSERDEADLOCK
Convert options  : KJUSERGETVALUE
History          : LOC_AST > CLOSE > FREE > REF_RES > MSGSENT > GR2CVT
Msg_Seq          : 0x0
res_seq          : 7
valblk           : 0xf8b87590fc7f00000000c90900000000 .u
user session for deadlock lock 0xea800c78
  sid: 1146 ser: 34903 audsid: 2840406 user: 86/USER_SUN
    flags: (0x41) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40009) -/-/INC
  pid: 34 O/S info: user: grid, term: UNKNOWN, ospid: 19635
    image: oracle@pmsup1 (TNS V1-V3)
  client details:
    O/S info: user: grid, term: pts/0, ospid: 19615
    machine: pmsup1 program: sqlplus@pmsup1 (TNS V1-V3)
    application name: SQL*Plus, hash value=3669949024
  current SQL:
  update tbdl set name='sa' where id=1
DUMP LOCAL BLOCKER: initiate state dump for DEADLOCK
  possible owner[34.19635] on resource TX-000B001C-0001B000

*** 2017-11-20 08:43:19.256
Submitting asynchronized dump request [1c]. summary=[ges process stack dump (kjdglblkrdm1)].
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0x7001f][0x1a64e],[TX][ext 0x0,0x0]
----------resource 0xecb1aeb8----------------------
resname       : [0x7001f][0x1a64e],[TX][ext 0x0,0x0]
hash mask     : x3
Local inst    : 2
dir_inst      : 2
master_inst   : 2
hv idx        : 65
hv last r.inc : 2
current inc   : 12
hv status     : 0
hv master     : 1
open options  : dd
grant_bits    : KJUSERNL KJUSEREX
grant mode    : KJUSERNL  KJUSERCR  KJUSERCW  KJUSERPR  KJUSERPW  KJUSEREX
count         : 1         0         0         0         0         1
val_state     : KJUSERVS_NOVALUE
valblk        : 0xe0ad7590fc7f0000e5f8e60200000000 .u
access_inst   : 2
vbreq_state   : 0
state         : x0
resp          : 0xecb1aeb8
On Scan_q?    : N
Total accesses: 65
Imm.  accesses: 61
Granted_locks : 1
Cvting_locks  : 1
value_block:  e0 ad 75 90 fc 7f 00 00 e5 f8 e6 02 00 00 00 00
GRANTED_Q :
lp 0xea2111e8 gl KJUSEREX rp 0xecb1aeb8 [0x7001f][0x1a64e],[TX][ext 0x0,0x0]
  master 2 gl owner 0xefc07780 possible pid 19635 xid 22000-0002-00006521 bast 0 rseq 4 mseq 0
  history REM_AST > REM_AST > MSGSENT > FREE > REF_RES > LOC_AST
  open opt KJUSERDEADLOCK  
CONVERT_Q:
lp 0xea211758 gl KJUSERNL rl KJUSEREX rp 0xecb1aeb8 [0x7001f][0x1a64e],[TX][ext 0x0,0x0]
  master 2 owner 1  bast 1 rseq 8 mseq 0x1
  history MSGSENT > FREE > REF_RES > REM_AST > GR2CVT > MSGSENT
  convert opt KJUSERGETVALUE  
----------enqueue 0xea2111e8------------------------
lock version     : 31
Owner inst       : 2
grant_level      : KJUSEREX
req_level        : KJUSEREX
bast_level       : KJUSERNL
notify_func      : (nil)
resp             : 0xecb1aeb8
procp            : 0xec28dd18
pid              : 1230
proc version     : 0
oprocp           : (nil)
opid             : 1230
group lock owner : 0xefc07780
possible pid     : 19635
xid              : 22000-0002-00006521
dd_time          : 0.0 secs
dd_count         : 0
timeout          : 0.0 secs
On_timer_q?      : N
On_dd_q?         : N
lock_state       : GRANTED
ast_flag         : 0x0
Open Options     : KJUSERDEADLOCK
Convert options  : KJUSERNOQUEUE KJUSERNODEADLOCKWAIT
History          : REM_AST > REM_AST > MSGSENT > FREE > REF_RES > LOC_AST
Msg_Seq          : 0x0
res_seq          : 4
valblk           : 0x00000000000000003100050200000000 .1
user session for deadlock lock 0xea2111e8
  sid: 1146 ser: 34903 audsid: 2840406 user: 86/USER_SUN
    flags: (0x41) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40009) -/-/INC
  pid: 34 O/S info: user: grid, term: UNKNOWN, ospid: 19635
    image: oracle@pmsup1 (TNS V1-V3)
  client details:
    O/S info: user: grid, term: pts/0, ospid: 19615
    machine: pmsup1 program: sqlplus@pmsup1 (TNS V1-V3)
    application name: SQL*Plus, hash value=3669949024
  current SQL:
  update tbdl set name='sa' where id=1
DUMP LOCAL BLOCKER: initiate state dump for DEADLOCK
  possible owner[34.19635] on resource TX-0007001F-0001A64E

*** 2017-11-20 08:43:19.256
Submitting asynchronized dump request [1c]. summary=[ges process stack dump (kjdglblkrdm1)].
----------enqueue 0xea211758------------------------
lock version     : 29
Owner inst       : 1
grant_level      : KJUSERNL
req_level        : KJUSEREX
bast_level       : KJUSERNL
notify_func      : 0x533cc6e
resp             : 0xecb1aeb8
procp            : 0xec2a0d80
pid              : 0
proc version     : 216
oprocp           : (nil)
opid             : 0
group lock owner : (nil)
xid              : 0000-0000-00000000
dd_time          : 0.0 secs
dd_count         : 0
timeout          : 0.0 secs
On_timer_q?      : N
On_dd_q?         : N
lock_state       : GRANTED
ast_flag         : 0x0
Open Options     :  KJUSERNO_XID
Convert options  : KJUSERGETVALUE
History          : MSGSENT > FREE > REF_RES > REM_AST > GR2CVT > MSGSENT
Msg_Seq          : 0x1
res_seq          : 8
valblk           : 0x000000000000000040b6980a00000000 .@
Global blockers dump end:-----------------------------------

Global Wait-For-Graph(WFG) at ddTS[0.1] :
BLOCKED 0xea800c78 5 wq 2 cvtops x1 TX 0xb001c.0x1b000(ext 0x0,0x0)[22000-0002-00006521] inst 2
BLOCKER 0xea1c0838 5 wq 1 cvtops x28 TX 0xb001c.0x1b000(ext 0x0,0x0)[2C000-0001-0000817E] inst 1
BLOCKED 0xea8079f8 5 wq 2 cvtops x1 TX 0x7001f.0x1a64e(ext 0x0,0x0)[2C000-0001-0000817E] inst 1
BLOCKER 0xea2111e8 5 wq 1 cvtops x28 TX 0x7001f.0x1a64e(ext 0x0,0x0)[22000-0002-00006521] inst 2

*** 2017-11-20 08:43:20.281
* Cancel deadlock victim lockp 0xea800c78

其实我们主要看Global Wait-For-Graph(WFG)信息然后再回去查找user session信息和对应SQL语句然后处理问题即可。
内容含义:
<BLOCKED|BLOCKER> <lockp> <cvt|held mode> <which q> <convert options> <res name - type id1.id2> [deadlock-level-trace] <node>  
Above graph shows the deadlock is related with 2 TX lock in mode 5 (exclusive) which happens on instance 1 and 2
从上面看出都是 mode 5 (exclusive) TX lock,该类型原因为SQL的执行顺序问题和高并发SQL,需要修改应用设计修改SQL执行顺序。
TX 0xb001c.0x1b000和TX 0x7001f.0x1a64e导致该死锁。
更详细的步骤如下:
BLOCKER 0xea2111e8 表示第一步, TX 0x7001f.0x1a64e已经获取
BLOCKED 0xea800c78 表示第三步,没有获取TX,TX 0xb001c.0x1b000阻塞者的事物XID.
同理:注意下面两个锁结构没有dump
BLOCKER 0xea1c0838 表示第二步,已经获取了资源TX
BLOCKED 0xea8079f8 表示第四步,没有获取TX,TX 0x7001f.0x1a64e表是阻塞他的事物

如果为高并发SQL执行导致SQL执行顺序互相哪资源锁这部分会存在较多的列表




当然oracle死锁类型较多如下所示:参见MOSI(ID 1443482.1)

2. TX deadlock in Share(S) mode

trace shows:

Global Wait-For-Graph(WFG) at ddTS[0.b7] :
BLOCKED 0x2310e8918 3 [0x731000e][0x56268],[TX] [F1000-0001-0000000F] 0
BLOCKER 0x2310e87c8 3 [0x731000e][0x56268],[TX] [19F000-0001-00000011] 0
BLOCKED 0x2310e3c50 3 [0x72a0023][0x530d7],[TX] [19F000-0001-00000011] 0
BLOCKER 0x2310e7e80 3 [0x72a0023][0x530d7],[TX] [F1000-0001-0000000F] 0  

Corresponding to:
<BLOCKED|BLOCKER> <lockp> <cvt|held mode> <res name> <pid|did|txn_id> <node>  
mode 3 is shared lock
The causes for TX deadlock in S mode wait can be:

a. ITL contention, eg: INITRANS setting for the object is too small, it can not handle the number of concurrent transactions.

The solution is to increase INITRANS setting for the object involved in the deadlock using "alter table" or "alter index" command
The SQL involved in the deadlock can be found in lmd0 or client trace. The object involved in the SQL should be checked including table and its associated index.

b. If the object involved is an unique key index, the wait could be caused by uniqueness validation. Application needs to be checked to avoid unique key violation.

c. If the object involved has a bitmap index, then the bitmap index should be dropped to accommodate concurrent DML. Please refer to Document 1496403.1 ORA-60 DEADLOCK DUE TO BITMAP INDEX IN RAC.


3. TM deadlock

典型的外键无索引:
trace shows:

Global Wait-For-Graph(WFG) at ddTS[0.1] :
BLOCKED 0x7000003ccbf4798 3 wq 2 cvtops x1 TM 0x1cbde.0x0 [1004-004D-00000003] 0
BLOCKER 0x7000003d0bf9ad8 3 wq 1 cvtops x1 TM 0x1cbde.0x0 [200A-00AC-00000019] 1
BLOCKED 0x7000003d0bfcf88 2 wq 2 cvtops x1 TM 0x1cc77.0x0 [200A-00AC-00000019] 1
BLOCKER 0x7000003cc338e88 2 wq 2 cvtops x1 TM 0x1cc77.0x0 [2006-0063-00000055] 1
BLOCKED 0x7000003cc338e88 3 wq 2 cvtops x1 TM 0x1cc77.0x0 [2006-0063-00000055] 1
BLOCKER 0x7000003c879f9c0 3 wq 1 cvtops x1 TM 0x1cc77.0x0 [2006-0063-00000020] 1
BLOCKED 0x7000003c87978a8 2 wq 2 cvtops x1 TM 0x1cbde.0x0 [2006-0063-00000020] 1
BLOCKER 0x7000003ccbf4798 2 wq 2 cvtops x1 TM 0x1cbde.0x0 [1004-004D-00000003] 0
The object involved here are 0x1cbde and 0x1cc77, convert the hex number to decimal, they are the object_id for the tables involved in above deadlock

The deadlock is usually caused by missing index for foreign key constraint, refer to Document 473124.1 - "Frequent GES: Potential Blocker (Pid=nnnn) On Resource TM-<id1>-<id2>" for more information. Check dba_constraints and dba_index to verify if foreign key index is missing. Also refer to Document 1019527.6 Script to Check for Foreign Key Locking Issues for a Specific User which will generate a report for all problem objects.

The solution is to create index for every foreign key constraint.


4. Single resource deadlock for TX , TM or IV

trace shows:

Single resource deadlock: blocking enqueue which blocks itself, f 1
Granted global enqueue 0xd078cec0
...
resname :[0x2001f][0x1a96c3],[TX]
or
resname :[0x00001432][0x0],[TM]
or
resname : [0xbb7cc5db][0x82d0d4b5],[IV]

a. For single resource deadlock on TX enqueue, often it is caused by using autonomous transaction in stored procedure or PL/SQL. It is a known issue that the use of autonomous transactions is vulnerable to deadlocks. Please check out Oracle? Database Concepts  Overview of Autonomous Transactions for detail explanation. Since AUTONOMOUS transaction has been used in the stored procedure, the system would consider any DML statement under this transaction as a separate one (commit/rollback won't affect the parent), and this would cause conflict if the same row is involved in the parent transaction (INSERT, UPDATE or DELETE), and hence deadlock is reported rightly. Usually the SQL involved in the deadlock is called from a stored procedure or PL/SQL with the following line:

PRAGMA AUTONOMOUS_TRANSACTION;
To avoid such deadlock, please remove the autonomous transaction in the application code.

b. If there is no autonomous_transaction involved, please check out Document 6145177.8, it can also be caused by Bug 6145177 - Single resource deadlock with a zero DID

c. For single resource deadlock on TM enqueue, missing foreign key index is often the cause, please check case 3 for the solution.

d. For single resource deadlock type IV (Instance Validation), refer to Document 973178.1, as mentioned in Bug 8843816, this message can be ignored. Bug 8843816 has been fixed in 11.1.

5. LB deadlock

Global Wait-For-Graph(WFG) at ddTS[0.390] :
BLOCKED 0x3bc3e1b48 5 wq 2 cvtops x0 [0xd2703c03][0x545a14a5],[LB] [7B000-0002-00006C9D] 1
BLOCKER 0x3bc2efad0 5 wq 1 cvtops x0 [0xd2703c03][0x545a14a5],[LB] [48000-0001-000069FE] 0
BLOCKED 0x3bc2ed1c0 3 wq 2 cvtops x0 [0x415d0160][0xca28e8cf],[LB] [48000-0001-000069FE] 0
BLOCKER 0x3bc2dc648 3 wq 2 cvtops x0 [0x415d0160][0xca28e8cf],[LB] [34000-0001-0000095E] 0
BLOCKED 0x3bc2dc648 5 wq 2 cvtops x0 [0x415d0160][0xca28e8cf],[LB] [34000-0001-0000095E] 0
BLOCKER 0x3bc2dbbb0 5 wq 1 cvtops x0 [0x415d0160][0xca28e8cf],[LB] [76000-0002-000074D4] 1
BLOCKED 0x3bc2ef830 3 wq 2 cvtops x0 [0xd2703c03][0x545a14a5],[LB] [76000-0002-000074D4] 1
BLOCKER 0x3bc3e1b48 3 wq 2 cvtops x0 [0xd2703c03][0x545a14a5],[LB] [7B000-0002-00006C9D] 1
LB lock type refers to library cache lock. This type of deadlock is usually caused by a bug.

For example: Bug 6475688  Concurrent rewrite and on-commit refresh can deadlock (library cache pin <--> lock) Document 6475688.8
The bug has been fixed in 11.1.0.7 and 11.2. Please apply patch accordingly.

6. Known Issues

For other deadlock type or known issues related to dead lock, refer to Document 554567.1 Summary Of Bugs Which Could Cause Deadlock In RAC Environment

7. Further Diagnosis

Please collect the following information for further diagnosis:

a. alert log lmd0, and trace mentioned in the alert log from all instances.
b. set the following event to collect systemstate dump ONLY if the information in trace files are insufficient:

alter system set events '60 trace name systemstate level 258';
It will cause a systemstate dump to be generated whenever a deadlock is reported. If there are constant deadlocks, it could cause a lot of trace files being generated, monitor the system carefully.

To turn off the trace:

alter system set events '60 trace name context off';


总结:

当遇到死锁问题后台alert会打印一条死锁trace文件的记录,查看trace文件
查找Global Wait-For-Graph(WFG)图表,依据上面文档分析死锁类型,是TX-5还是TX-3等
依据该信息找到对应的user session,找到SQL语句,TX-5解决应用
设计问题,ITL问题增大ITL,删除位图,外键加索引,bug? 具体问题具体处理






论坛徽章:
0
2#
发表于 2017-11-25 08:54 | 只看该作者
学习了,多谢分享!

使用道具 举报

回复
论坛徽章:
0
3#
发表于 2017-11-25 08:55 | 只看该作者
收藏慢慢学习

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档 |
  | | |
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 网站律师 隐私政策 知识产权声明
 北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表