這個是我之前在項目組里面，有一個功能模塊寫了一個很復雜的sql存儲過程，每次做業務都調用存儲過來處理邏輯。
當多人同時做業務調用這個存儲過程的時候，頁面沒法響應一直卡死在哪里，后面請教過專業的dba排查過問題，是存儲過程里面的某部分insert,update操作導致死鎖了。
現在講排查死鎖的步驟總結如下：
1、查行鎖：
column event format a30
column sess format a20
set linesize 150
break on id1 skip 1
select decode(request,0,'Holder:',' Waiter:') || s.inst_id || ':' || s.sid||','|| s.serial# sess,
id1, id2, lmode, request, l.type, ctime, s.sql_id, s.event,s.last_call_et
from gv$lock l, gv$session s
where (id1, id2, l.type) in
(select id1, id2, type from gv$lock where request>0)
and l.sid=s.sid
and l.inst_id=s.inst_id
order by id1, ctime desc, request;
2、通過查行鎖定位出來存儲過程里面是哪些sql導致的死鎖：
導致鎖表的sqlId:
select sql_text from gv$sql where sql_id='9g5813my4anbt'; 這個是查具體sql語句
一下為死鎖相關的表，通過dba權限去查看：
SELECT * FROM v$lock;
SELECT * FROM v$sqlarea;
SELECT * FROM v$session;
SELECT * FROM v$process ;
SELECT * FROM v$locked_object;
SELECT * FROM all_objects;
SELECT * FROM v$session_wait;
--查看被鎖的表
select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id;
--查看那個用戶那個進程照成死鎖
select b.username,b.sid,b.serial#,logon_time from v$locked_object a,v$session b where a.session_id = b.sid order by b.logon_time;
--查看連接的進程
SELECT sid, serial#, username, osuser FROM v$session;
--3.查出鎖定表的sid, serial#,os_user_name, machine_name, terminal，鎖的type,mode
SELECT s.sid, s.serial#, s.username, s.schemaname, s.osuser, s.process, s.machine,
s.terminal, s.logon_time, l.type
FROM v$session s, v$lock l
WHERE s.sid = l.sid
AND s.username IS NOT NULL
ORDER BY sid;
這個語句將查找到數據庫中所有的DML語句產生的鎖，還可以發現，
任何DML語句其實產生了兩個鎖，一個是表鎖，一個是行鎖。
--殺掉進程 sid,serial#
4、最后的解決辦法就是要去優化存儲過程,或者從業務方面就行優化才得到解決，我們當時對幾張幾千萬數據的大表做了表分區處理，按年份把不同年份的數據落到
不同的數據文件里面，希望通過我真實遇到的問題以及解決的技術方案對大家有所幫助！