基於10.2.0.1 rac deadlock死鎖 trace file分析_增補二
結論
1,oracle 10g rac如果在2個節點間發生死鎖，會記錄到告警日誌中2,從告警日誌可以找到對應的死鎖的TRACE FILE
3，死鎖的TRACE FILE內容構成
第一部分：
略去，因為和死鎖內容無關
第二部分：
這是我們基於RAC死鎖最為關心的資訊
*** 2015-11-09 22:04:01.002
user session for deadlock lock 0x82f5c810
pid=18 serial=57 audsid=26 user: 27/TBS_ZXY --發生死鎖會話對應的程式號以及使用者
O/S info: user: oracle, term: pts/2, ospid: 6050, machine: jingfa1 --源於V$SESSION
program: sqlplus@jingfa1 (TNS V1-V3)
application name: SQL*Plus, hash value=3669949024
Current SQL Statement:
update t_lock set a=22 where a=2 --發生死鎖會話正在執行的SQL
小結下：第二部分包括死鎖會話的一些相關資訊，即死鎖會話SID及程式號以及終端資訊，還在正在執行的SQL
第三部分：
----可見如下on [0xa0006][0x7c],[TX] 含義為[0xa0006]對應xidusn+xidslot，而0x7c]對應xidsqn
ENQUEUE DUMP REQUEST: from 1.22803 on [0xa0006][0x7c],[TX] for reason 3 mtype 0
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0xa0006][0x7c],[TX] --同上
----------resource 0x0x7e51ac20----------------------
resname : [0xa0006][0x7c],[TX]
Local node : 0
dir_node : 0
master_node : 0
hv idx : 86
hv last r.inc : 4
current inc : 4
hv status : 0
hv master : 0
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 : 0x00000000000000000000000000000000 .
access_node : 0
vbreq_state : 0
state : x0
resp : 0x7e51ac20
On Scan_q? : N
Total accesses: 67
Imm. accesses: 58
Granted_locks : 1
Cvting_locks : 1
value_block: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
小結：
重點關注上述的資訊：ENQUEUE DUMP REQUEST: from 1.22803 on [0xa0006][0x7c],[TX] for reason 3 mtype 0，對應等待者會話的XID相關的資訊，即發生死鎖會話的XID
至於其它資訊，過於INTERNAL，還需要研究
第四部分
可見global blockers dump start即死鎖的持鎖者事務的資訊為如下資訊：
即res [0x110022][0x11],[TX]對應持鎖會話,具體為res [0x110022]對應xidusn + xidslot,而[0x11]對應xidsqn
也就是可以根據如下，把16進位制轉換為10進位制，然後到GV$TRANSACTION去匹配對應的會話，最終由GV$SESSION找到持鎖會話的資訊，進行針對性處理即可
Global blockers dump start:---------------------------------
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0x110022][0x11],[TX]
----------resource 0x0x7f32f540----------------------
resname : [0x110022][0x11],[TX]
Local node : 0
dir_node : 1
master_node : 1
hv idx : 7
hv last r.inc : 2
current inc : 4
hv status : 0
hv master : 1
open options : dd
Held mode : KJUSERNL
Cvt mode : KJUSEREX
Next Cvt mode : KJUSERNL
msg_seq : 0x1
res_seq : 3
grant_bits : KJUSERNL
grant mode : KJUSERNL KJUSERCR KJUSERCW KJUSERPR KJUSERPW KJUSEREX
count : 1 0 0 0 0 0
val_state : KJUSERVS_NOVALUE
valblk : 0x00000000000000000000000000000000 .
access_node : 1
vbreq_state : 0
state : x8
resp : 0x7f32f540
On Scan_q? : N
Total accesses: 29
Imm. accesses: 22
Granted_locks : 0
Cvting_locks : 1
value_block: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
GRANTED_Q :
CONVERT_Q:
lp 0x82f5c810 gl KJUSERNL rl KJUSEREX rp 0x7f32f540 [0x110022][0x11],[TX]
master 1 gl owner 0x83b4fe90 possible pid 16602 xid 12000-0001-00000035 bast 0 rseq 3 mseq 0 history 0x1495149a
convert opt KJUSERGETVALUE
----------enqueue 0x0x82f5c810------------------------
lock version : 1207
Owner node : 0
grant_level : KJUSERNL
req_level : KJUSEREX
bast_level : KJUSERNL
notify_func : (nil)
resp : 0x7f32f540
procp : 0x82d53660
pid : 16602
proc version : 6
oprocp : (nil)
opid : 0
group lock owner : 0x83b4fe90
possible pid : 16602
xid : 12000-0001-00000035
dd_time : 74.0 secs
dd_count : 1
timeout : 0.0 secs
On_timer_q? : N
On_dd_q? : Y
lock_state : OPENING CONVERTING
Open Options : KJUSERDEADLOCK
Convert options : KJUSERGETVALUE
History : 0x1495149a
Msg_Seq : 0x0
res_seq : 3
valblk : 0x00000000000000000000000000000000 .
小結下：
這部分可以理解為引發死鎖的會話及程式的相關資訊，重點關注如下資訊
Global blockers dump start:---------------------------------
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0x110022][0x11],[TX]
對應即res [0x110022][0x11],[TX]對應持鎖會話,具體為res [0x110022]對應xidusn + xidslot,而[0x11]對應xidsqn
也就是說先在TRAC FILE查詢Global blockers dump start,然後對應的res相關的資訊
然後根據res的資訊如下，把16進位制轉換為10進位制，然後到GV$TRANSACTION去匹配對應的會話，最終由GV$SESSION找到持鎖會話的資訊，進行針對性處理即可
關於第四部分，定位到引發死鎖的持鎖會話的相關資訊指令碼如下：
SQL> select inst_id,saddr,sid from gv$session where sid in (133,147);
INST_ID SADDR SID
---------- ---------------- ----------
1 0000000083B4FE90 133
1 0000000083B619A0 147
2 0000000083B619A0 147
SQL> select inst_id,xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn,ubarec from gv$transaction where ses_addr in ('0000000083B4FE90','0000000083B619A0');
INST_ID XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK UBASQN UBAREC
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
1 10 6 124 2 890 33 56 --等待者
2 17 34 17 4 434 7 20 --持鎖者
SQL> select to_char(17,'xxxxxxxx') xidusn,to_char(34,'xxxxxxxx') xidslot,to_char(17,'xxxxxxxx') xidsqn from dual;
XIDUSN XIDSLOT XIDSQN
--------- --------- ---------
11 22 11
SQL> select inst_id,ses_addr from gv$transaction where xidusn=12 and xidslot=16 and xidsqn=21;
INST_ID SES_ADDR
---------- ----------------
2 0000000083B619A0
SQL> select inst_id,sql_id from gv$session where saddr='0000000083B619A0' and inst_id=2;
INST_ID SQL_ID
---------- -------------
2 b3tmrc0st5pyb
可見最終定位到了引發死鎖的所屬例項及會話資訊，即執行的SQL
SQL> select sql_text from gv$sql where sql_id='b3tmrc0st5pyb' and inst_id=2;
SQL_TEXT
--------------------------------------------------
update t_lock set a=11 where a=1
4，檢測基於RAC的死鎖是由lmd程式負責
[oracle@jingfa1 bdump]$ ps -ef|grep lmd
oracle 4001 1 0 Nov09 ? 00:00:09 ora_lmd0_jingfa1
oracle 29844 29669 0 00:59 pts/3 00:00:00 grep lmd
5,基於RAC的死鎖檢測在前端報錯和單例項一樣，但是在告警日誌報銷有所區別，內容如下：
Tue Nov 10 00:16:26 2015
Global Enqueue Services Deadlock detected. More info in file
/u01/app/oracle/admin/jingfa/bdump/jingfa1_lmd0_4001.trc.
引申：也就是說GES是負責RAC的全域性鎖相關的內容
6，如果要深入理解基於RAC的死鎖，一定要研究程式LMD及GES的含義
7，感覺在RAC環境死鎖檢測時間將近30多秒，比較久，我分析有個引數控制，將於下文繼續研究
測試
--oracle version
SQL> select * from v$version where rownum=1;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
SQL> conn tbs_zxy/system
Connected.
---node 1 session 133
SQL> select sid from v$mystat where rownum=1;
SID
----------
133
SQL> select pid,spid,addr from v$process where addr=(select paddr from v$session where sid=(select sid from v$mystat where rownum=1));
PID SPID ADDR
---------- ------------ ----------------
18 16602 0000000083A5E4A8
SQL> create table t_lock(a int,b int);
Table created.
SQL> insert into t_lock select level,level from dual connect by level<=2;
2 rows created.
SQL> commit;
Commit complete.
SQL> select * from t_lock;
A B
---------- ----------
1 1
2 2
---node 2 session 147
SQL> select sid from v$mystat where rownum=1;
SID
----------
147
SQL> select pid,spid,addr from v$process where addr=(select paddr from v$session where sid=(select sid from v$mystat where rownum=1));
PID SPID ADDR
---------- ------------ ----------------
22 16151 0000000083A60448
SQL> update t_lock set a=22 where a=2;
1 row updated.
模擬死鎖的程式碼略
在告警日誌出生死鎖資訊
Mon Nov 9 22:04:01 2015
Global Enqueue Services Deadlock detected. More info in file
/u01/app/oracle/admin/jingfa/bdump/jingfa1_lmd0_1450.trc.
分析死鎖資訊,分析及註釋直接標記在TRACE FILE上面
第一部分：
這部分的內容好像和DRM有關，具體相關原理將於另一文章進行分析及測試
*** SERVICE NAME:() 2015-11-09 21:45:05.422
*** SESSION ID:(166.1) 2015-11-09 21:45:05.422
syncr inc 4 lvl 1 from 1 rcvd (my inc,lvl: 0, 0) (4/5.0.0)
s2m domain info received from 1 (4.6)
* kjxbdomps2m: domain 0 not valid according to instance 1
first hvmap received from 1 for domain 0 (4.7)
* kjxhvmaph: domain 0 valid = 0 according to instance 1
last hvmap received from 1, (4.7)
first hvmap received from 1 for enqueue mappings (4.7)
last hvmap received from 1, (4.7)
ftd received from node 1 (4/7.0.0)
all ftds received
syncr inc 4 lvl 2 from 1 rcvd (my inc,lvl: 4, 1) (4/7.0.0)
中間略
syncr inc 4 lvl 11 from 1 rcvd (my inc,lvl: 4, 10) (4/0.36.0)
ftd received from node 1 (4/0.38.0)
第二部分
這是我們基於RAC死鎖最為關心的資訊
*** 2015-11-09 22:04:01.002
user session for deadlock lock 0x82f5c810
pid=18 serial=57 audsid=26 user: 27/TBS_ZXY --發生死鎖會話對應的程式號以及使用者
O/S info: user: oracle, term: pts/2, ospid: 6050, machine: jingfa1 --源於V$SESSION
program: sqlplus@jingfa1 (TNS V1-V3)
application name: SQL*Plus, hash value=3669949024
Current SQL Statement:
update t_lock set a=22 where a=2 --發生死鎖會話正在執行的SQL
SQL> select inst_id,saddr,sid from gv$session where sid in (133,147);
INST_ID SADDR SID
---------- ---------------- ----------
1 0000000083B4FE90 133
1 0000000083B619A0 147
2 0000000083B619A0 147
SQL> select inst_id,xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn,ubarec from gv$transaction where ses_addr in ('0000000083B4FE90','0000000083B619A0');
INST_ID XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK UBASQN UBAREC
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
1 10 6 124 2 890 33 56
2 17 34 17 4 434 7 20
SQL> select to_char(10,'xxxxxxxx') xidusn,to_char(6,'xxxxxxxx') xidslot,to_char(124,'xxxxxxxx') xidsqn from dual;
XIDUSN XIDSLOT XIDSQN
--------- --------- ---------
a 6 7c
----可見如下on [0xa0006][0x7c],[TX] 含義為[0xa0006]對應xidusn+xidslot，而0x7c]對應xidsqn
ENQUEUE DUMP REQUEST: from 1.22803 on [0xa0006][0x7c],[TX] for reason 3 mtype 0
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0xa0006][0x7c],[TX] --同上
----------resource 0x0x7e51ac20----------------------
resname : [0xa0006][0x7c],[TX]
Local node : 0
dir_node : 0
master_node : 0
hv idx : 86
hv last r.inc : 4
current inc : 4
hv status : 0
hv master : 0
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 : 0x00000000000000000000000000000000 .
access_node : 0
vbreq_state : 0
state : x0
resp : 0x7e51ac20
On Scan_q? : N
Total accesses: 67
Imm. accesses: 58
Granted_locks : 1
Cvting_locks : 1
value_block: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
GRANTED_Q :
lp 0x7e5237d0 gl KJUSEREX rp 0x7e51ac20 [0xa0006][0x7c],[TX] ---同上
master 0 gl owner 0x83b4fe90 possible pid 16602 xid 12000-0001-00000035 bast 0 rseq 8 mseq 0 history 0x4977d495 --pid為發生死鎖會話的作業系統程式號
open opt KJUSERDEADLOCK
CONVERT_Q:
lp 0x7e524118 gl KJUSERNL rl KJUSEREX rp 0x7e51ac20 [0xa0006][0x7c],[TX]
master 0 owner 1 bast 1 rseq 12 mseq 0x1 history 0x97d497ad
convert opt KJUSERGETVALUE
----------enqueue 0x0x7e5237d0------------------------
lock version : 11
Owner node : 0
grant_level : KJUSEREX
req_level : KJUSEREX
bast_level : KJUSERNL
notify_func : (nil)
resp : 0x7e51ac20
procp : 0x82d4b4c8
pid : 1450
proc version : 0
oprocp : (nil)
opid : 0
group lock owner : 0x83b4fe90
possible pid : 16602
xid : 12000-0001-00000035
dd_time : 0.0 secs
dd_count : 0
timeout : 0.0 secs
On_timer_q? : N
On_dd_q? : N
lock_state : GRANTED
Open Options : KJUSERDEADLOCK
Convert options : KJUSERNOQUEUE
History : 0x4977d495
Msg_Seq : 0x0
res_seq : 8
valblk : 0x00000000000000000000000000000000 .
DUMP LOCAL BLOCKER: initiate state dump for
possible owner[18.16602]
Submitting asynchronized dump request [28]
----------enqueue 0x0x7e524118------------------------
lock version : 9
Owner node : 1
grant_level : KJUSERNL
req_level : KJUSEREX
bast_level : KJUSERNL
notify_func : 0x165d838
resp : 0x7e51ac20
procp : 0x82d4ea68
pid : 0
proc version : 0
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
Open Options : KJUSERNO_XID
Convert options : KJUSERGETVALUE
History : 0x97d497ad
Msg_Seq : 0x1
res_seq : 12
valblk : 0x00000000000000000000000000000000 .
SQL> select inst_id,saddr,sid from gv$session where sid in (133,147);
INST_ID SADDR SID
---------- ---------------- ----------
1 0000000083B4FE90 133
1 0000000083B619A0 147
2 0000000083B619A0 147
SQL> select inst_id,xidusn,xidslot,xidsqn,ubafil,ubablk,ubasqn,ubarec from gv$transaction where ses_addr in ('0000000083B4FE90','0000000083B619A0');
INST_ID XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK UBASQN UBAREC
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
1 10 6 124 2 890 33 56 --等待者
2 17 34 17 4 434 7 20 --持鎖者
SQL> select to_char(17,'xxxxxxxx') xidusn,to_char(34,'xxxxxxxx') xidslot,to_char(17,'xxxxxxxx') xidsqn from dual;
XIDUSN XIDSLOT XIDSQN
--------- --------- ---------
11 22 11
SQL> select inst_id,ses_addr from gv$transaction where xidusn=12 and xidslot=16 and xidsqn=21;
INST_ID SES_ADDR
---------- ----------------
2 0000000083B619A0
SQL> select inst_id,sql_id from gv$session where saddr='0000000083B619A0' and inst_id=2;
INST_ID SQL_ID
---------- -------------
2 b3tmrc0st5pyb
可見最終定位到了引發死鎖的所屬例項及會話資訊，即執行的SQL
SQL> select sql_text from gv$sql where sql_id='b3tmrc0st5pyb' and inst_id=2;
SQL_TEXT
--------------------------------------------------
update t_lock set a=11 where a=1
可見global blockers dump start即死鎖的持鎖者事務的資訊為如下資訊：
即res [0x110022][0x11],[TX]對應持鎖會話,具體為res [0x110022]對應xidusn + xidslot,而[0x11]對應xidsqn
也就是可以根據如下，把16進位制轉換為10進位制，然後到GV$TRANSACTION去匹配對應的會話，最終由GV$SESSION找到持鎖會話的資訊，進行針對性處理即可
Global blockers dump start:---------------------------------
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0x110022][0x11],[TX]
----------resource 0x0x7f32f540----------------------
resname : [0x110022][0x11],[TX]
Local node : 0
dir_node : 1
master_node : 1
hv idx : 7
hv last r.inc : 2
current inc : 4
hv status : 0
hv master : 1
open options : dd
Held mode : KJUSERNL
Cvt mode : KJUSEREX
Next Cvt mode : KJUSERNL
msg_seq : 0x1
res_seq : 3
grant_bits : KJUSERNL
grant mode : KJUSERNL KJUSERCR KJUSERCW KJUSERPR KJUSERPW KJUSEREX
count : 1 0 0 0 0 0
val_state : KJUSERVS_NOVALUE
valblk : 0x00000000000000000000000000000000 .
access_node : 1
vbreq_state : 0
state : x8
resp : 0x7f32f540
On Scan_q? : N
Total accesses: 29
Imm. accesses: 22
Granted_locks : 0
Cvting_locks : 1
value_block: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
GRANTED_Q :
CONVERT_Q:
lp 0x82f5c810 gl KJUSERNL rl KJUSEREX rp 0x7f32f540 [0x110022][0x11],[TX]
master 1 gl owner 0x83b4fe90 possible pid 16602 xid 12000-0001-00000035 bast 0 rseq 3 mseq 0 history 0x1495149a
convert opt KJUSERGETVALUE
----------enqueue 0x0x82f5c810------------------------
lock version : 1207
Owner node : 0
grant_level : KJUSERNL
req_level : KJUSEREX
bast_level : KJUSERNL
notify_func : (nil)
resp : 0x7f32f540
procp : 0x82d53660
pid : 16602
proc version : 6
oprocp : (nil)
opid : 0
group lock owner : 0x83b4fe90
possible pid : 16602
xid : 12000-0001-00000035
dd_time : 74.0 secs
dd_count : 1
timeout : 0.0 secs
On_timer_q? : N
On_dd_q? : Y
lock_state : OPENING CONVERTING
Open Options : KJUSERDEADLOCK
Convert options : KJUSERGETVALUE
History : 0x1495149a
Msg_Seq : 0x0
res_seq : 3
valblk : 0x00000000000000000000000000000000 .
DUMP LOCAL BLOCKER: initiate state dump for
possible owner[18.16602]
Submitting asynchronized dump request [28]
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0xa0006][0x7c],[TX]
----------resource 0x0x7e51ac20----------------------
resname : [0xa0006][0x7c],[TX]
Local node : 0
dir_node : 0
master_node : 0
hv idx : 86
hv last r.inc : 4
current inc : 4
hv status : 0
hv master : 0
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 : 0x00000000000000000000000000000000 .
access_node : 0
vbreq_state : 0
state : x0
resp : 0x7e51ac20
On Scan_q? : N
Total accesses: 69
Imm. accesses: 59
Granted_locks : 1
Cvting_locks : 1
value_block: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
GRANTED_Q :
lp 0x7e5237d0 gl KJUSEREX rp 0x7e51ac20 [0xa0006][0x7c],[TX]
master 0 gl owner 0x83b4fe90 possible pid 16602 xid 12000-0001-00000035 bast 0 rseq 8 mseq 0 history 0x4977d495
open opt KJUSERDEADLOCK
CONVERT_Q:
lp 0x7e524118 gl KJUSERNL rl KJUSEREX rp 0x7e51ac20 [0xa0006][0x7c],[TX]
master 0 owner 1 bast 1 rseq 12 mseq 0x1 history 0x97d497ad
convert opt KJUSERGETVALUE
----------enqueue 0x0x7e5237d0------------------------
lock version : 11
Owner node : 0
grant_level : KJUSEREX
req_level : KJUSEREX
bast_level : KJUSERNL
notify_func : (nil)
resp : 0x7e51ac20
procp : 0x82d4b4c8
pid : 1450
proc version : 0
oprocp : (nil)
opid : 0
group lock owner : 0x83b4fe90
possible pid : 16602
xid : 12000-0001-00000035
dd_time : 0.0 secs
dd_count : 0
timeout : 0.0 secs
On_timer_q? : N
On_dd_q? : N
lock_state : GRANTED
Open Options : KJUSERDEADLOCK
Convert options : KJUSERNOQUEUE
History : 0x4977d495
Msg_Seq : 0x0
res_seq : 8
valblk : 0x00000000000000000000000000000000 .
DUMP LOCAL BLOCKER: initiate state dump for
possible owner[18.16602]
Submitting asynchronized dump request [28]
----------enqueue 0x0x7e524118------------------------
lock version : 9
Owner node : 1
grant_level : KJUSERNL
req_level : KJUSEREX
bast_level : KJUSERNL
notify_func : 0x165d838
resp : 0x7e51ac20
procp : 0x82d4ea68
pid : 0
proc version : 0
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
Open Options : KJUSERNO_XID
Convert options : KJUSERGETVALUE
History : 0x97d497ad
Msg_Seq : 0x1
res_seq : 12
valblk : 0x00000000000000000000000000000000 .
Global blockers dump end:-----------------------------------
基於RAC的全域性死鎖的圖表鏈（此塊內容仍沒有完全理解）
Global Wait-For-Graph(WFG) at ddTS[0.1] :
BLOCKED 0x82f5c810 5 [0x110022][0x11],[TX] [12000-0001-00000035] 0 --blocked表示等待者，其中[0x110022][0x11]對應持鎖會話的[0x110022]對應xidusn + xidslot,而[0x11]對應xidsqn
BLOCKER 0x82eb5db0 5 [0x110022][0x11],[TX] [16000-0002-0000000A] 1 --blocker表示持鎖者
BLOCKED 0x82f59468 5 [0xa0006][0x7c],[TX] [16000-0002-0000000A] 1 ---表示等待者
BLOCKER 0x7e5237d0 5 [0xa0006][0x7c],[TX] [12000-0001-00000035] 0 ---表示等待者
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25462274/viewspace-2059761/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- oracle deadlock死鎖trace file分析之一增補Oracle
- oracle deadlock死鎖trace file分析之一Oracle
- 基於oracle 10.2.0.1 rac學習lmon程式系列六之增補一Oracle
- 基於oracle 10.2.0.1 rac死鎖deadlock檢測時間相關隱含引數及機制之一_lm_dd_intervalOracle
- 死鎖_DeadLock_示例
- 【DEADLOCK】Oracle“死鎖”模擬Oracle
- [Java]一個DeadLock(死鎖)的例子Java
- 關於 SAP HANA 資料庫的死鎖問題(deadlock)資料庫
- 使用oracle 10704 event分析獲取鎖lock及死鎖deadlock系列九Oracle
- Java 死鎖(DeadLock)例項分析和預防[base jdk8]JavaJDK
- RDSSQLServer死鎖（Deadlock）系列之三自動部署Profiler捕獲死鎖SQLServer
- 死鎖分析
- select for update語句造成ORA-00060 deadlock死鎖問題分析
- oracle lock轉換及oracle deadlock死鎖系列一Oracle
- 基於oracle 10.2.0.1 rac學習lmon程式系列六Oracle
- 基於oracle 10.2.0.1 rac學習lms程式系列四Oracle
- 用strace跟蹤分析oracle 10.2.0.1 rac lmd程式系列二Oracle
- 基於oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列四Oracle
- 基於oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列五Oracle
- 基於oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列六Oracle
- 死鎖案例分析
- HashMap死鎖分析HashMap
- 10.2.0.2 RAC DB ">>> ERROR IN KQLMBIVG SEE LCK TRACE FILEError
- MySQL：一個死鎖分析 (未分析出來的死鎖)MySql
- 【死鎖】ORA-00060: deadlock detected while waiting for resourceWhileAI
- 測試庫死鎖診斷DEADLOCK DETECTED ( ORA-00060 )
- GreatSQL 死鎖案例分析SQL
- 故障分析 | MySQL死鎖案例分析MySql
- SQLServer的死鎖分析（1）：頁鎖SQLServer
- 使用jstack檢測Java應用的死鎖(deadlock)狀態JSJava
- 【MySQL】死鎖案例之二MySql
- MySQL 死鎖問題分析MySql
- ORACLE 死鎖分析過程Oracle
- Sqlserver分析死鎖問題SQLServer
- 線上死鎖問題分析
- MySQL 死鎖日誌分析MySql
- RAC全域性死鎖檢測時間
- MySQL鎖等待與死鎖問題分析MySql