今天，操作人員告知某系統無法進行刷卡操作，系統始終處於等待狀態。至中午時分，狀況愈演愈烈，只好先kill session部分阻塞使用者，以便緩解狀況。通過gv$lock檢視查詢可知主要鎖定在p_kaoqin等相關表。查詢對應語句多為insert，甚至包括select sysdate from dual，有點詭異。通過v$session_event檢視使用者等待事件,存在大量的enq:tm contention。
tm鎖定的物件是表，考慮是否由於外建索引失效造成。檢視相關表的約束條件，並無外建約束。看來不是外建的原因。
ges: potential blocker (pid=2146686) on resource tm-002e3d8b-00000000;
ges: potential blocker (pid=2183274) on resource tm-002e3d93-00000000;
ges: potential blocker (pid=860534) on resource tm-002e3d93-00000000;
ges: potential blocker (pid=1589864) on resource tm-002e3d93-00000000;
ges: potential blocker (pid=1675346) on resource tm-002e3d93-00000000;
ges: potential blocker (pid=1712332) on resource tm-002e3d93-00000000;
synca inc 4 lvl 58471 from 0 rcvd (my inc,lvl: 4,58470) (4/0.36.0)lock table p_kaoqin in exclusive modeftd received from node 0 (4/0.37.0)
all ftds received
synca inc 4 lvl 58472 from 0 rcvd (my inc,lvl: 4,58471) (4/0.38.0)
*** 2013-11-08 10:15:55.091
end drm(1832) for pkey transfer request(s) from 0
*** 2013-11-08 10:17:43.053
user session for deadlock lock 7000003c1357218
pid=107 serial=5367 audsid=463747602 user: 268/***x
o/s info: user: test, term: unknown, ospid: , machine: ***x-test3
program: jdbc thin client
client info: 172.16.1.193
current sql statement:
lock table p_kaoqin in exclusive mode
user session for deadlock lock 7000003c33578a8
pid=427 serial=15207 audsid=463728039 user: 268/***x
o/s info: user: guest, term: unknown, ospid: , machine: pc-201102091043
program: jdbc thin client
client info: 172.30.122.100
current sql statement:
update p_task set pt_kaig***=:1, pt_tingg***=:2, pt_tinggtime=:3, pt_tinggtime_sg=:4, pt_tinggyy=:5, pt_tinggdepartid=:6, pt_tinggusercod=:7 where pt_departid = :8 and pt_id = :9
global blockers dump start:---------------------------------
dump local blocker/holder: block level 5 res [0x2e3d93][0x0],[tm]
----------resource 0x700000385358ea0----------------------
resname : [0x2e3d93][0x0],[tm]
local node : 1
dir_node : 1
master_node : 1
hv idx : 114
hv last r.inc : 4
current inc : 4
hv status : 0
hv master : 1
open options : dd cached
grant_bits : kjusernl kjusercw
grant mode : kjusernl kjusercr kjusercw kjuserpr kjuserpw kjuserex
count : 2 0 1 0 0 0
val_state : kjuservs_value
valblk : 0x01000000000000000000000000000000 .
看來問題的根源已經找到了，剩下就是找出對應的程式並驗證。
死鎖的案例
死鎖就是當有兩個或兩個以上的執行緒都獲得對方的資源，但彼此有不肯放開，處於僵持狀態，此時便造成了死鎖 package cn.et.deadlock public class deadlock implements runnable catch interruptedexception e synch...
死鎖的小案例
關於死鎖的一些小概念 死鎖是指兩個或兩個以上的程序在執行過程中，由於競爭資源或者由於彼此通訊而造成的一種阻塞的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的程序稱為死鎖程序。就我個人而言,我喜歡將死鎖叫做執行緒版的鷸蚌相爭.1.產生原因 複製的...
Lock死鎖的案例
死鎖 執行緒a和執行緒b相互等待對方持有的鎖導致程式無限死迴圈下去 1 兩個執行緒裡面分別持有兩個object物件 lock1和lock2。這兩個lock作為同步 塊的鎖 2 執行緒1的run 方法中同步 塊先獲取lock1的物件鎖，thread.sleep 然後接著獲取lock2的物件鎖。這麼做主...