oracle會自動解決思索問題，把響應的死鎖解除。實驗：create table A(id int);insert into A values(100); insert into A values(100); insert into A values(100);select * from A;>建立死鎖機制--A用戶update A set id = 1000 where id = 100;--B用戶update A set id = 2000 where id = 200;--A用戶去觸碰B用戶正在使用的id=200的數據update A set id = 1500 where id = 200;--B用戶去觸碰A用戶正在使用的id=100的數據 update A set id = 1100 where id = 100;這樣就會造成死鎖，oracle會自動解除死鎖。 --------------------- Oracle 10.2.0.1.0 64位 ，操作系統 AIX 6.1 近期在查看alert日志時發現如下信息 Mon Nov 5 16:02:40 2012 ORA-00060: Deadlock detected. More info in file /oradata/admin/$ORACLE_SID/udump/$ORACLE_SID_ora_6554104.trc. Mon Nov 5 16:06:52 2012 ORA-00060: Deadlock detected. More info in file /oradata/admin/$ORACLE_SID/udump/$ORACLE_SID_ora_9961902.trc. Mon Nov 5 16:51:21 2012 提示檢查到死鎖，然后查看trace文件more /oradata/admin/$ORACLE_SID/udump/$ORACLE_SID_ora_6554104.trc前面無關內容省略*** 2012-11-05 16:02:40.639 *** SERVICE NAME:(SYS$USERS) 2012-11-05 16:02:40.638 *** SESSION ID:(154.37034) 2012-11-05 16:02:40.638 DEADLOCK DETECTED [Transaction Deadlock] Current SQL statement for this session: UPDATE "RZ_DLOGIN" SET "D_DATA" = :1 WHERE "G_NAME" = :2 AND "D_CODE" = :3 AND "CLASS_ID" = :4 The following deadlock is not an ORACLE error. It is a deadlock due to user error in the design of an application or from issuing incorrect ad-hoc SQL. The following information may aid in determining the deadlock: Deadlock graph: ---------Blocker(s)-------- ---------Waiter(s)--------- Resource Name process session holds waits process session holds waits TX-00080028-0000d238 68 154 X 81 97 X TX-0005001d-0000ac81 81 97 X 68 154 X session 154: DID 0001-0044-00000E1E session 97: DID 0001-0051-00000BDA session 97: DID 0001-0051-00000BDA session 154: DID 0001-0044-00000E1E Rows waited on: Session 97: obj - rowid = 0000D950 - AAANlQAAFAAA/ilABD (dictionary objn - 55632, file - 5, block - 260261, slot - 67) Session 154: obj - rowid = 0000D950 - AAANlQAAFAAA/ilAA7 (dictionary objn - 55632, file - 5, block - 260261, slot - 59) Information on the OTHER waiting sessions: Session 97: pid=81 serial=21773 audsid=600338 user: 55/DB O/S info: user: Administrator, term: name1, ospid: 1408:1296, machine: factory\name1 program: name.exe application name: name.exe, hash value=0 Current SQL Statement: UPDATE "RZ_DLOGIN" SET "D_DATA" = :1 WHERE "G_NAME" = :2 AND "D_CODE" = :3 AND "CLASS_ID" = :4 End of information on OTHER waiting sessions.經過與開發人員溝通，已確認 UPDATE "RZ_DLOGIN" SET "D_DATA" = :1 WHERE "G_NAME" = :2 AND "D_CODE" = :3 AND "CLASS_ID" = :4 這一語句對應的前端應用A，與程序使用者溝通了解到前端應用A確認運行較慢，一般要等待一段時間才能完成，有時也會遇到等待無反應的情況，此時關閉應用A程序，重新運行就會正常。同時將上述日志中發現的問題反映給開發人員，開發人員也證實此處程序需要優化。 現在的問題是： 既然Oracle日志中已經提示檢查到死鎖，為何前端應用A只是等待了一段時間（這段等待時間用戶還能夠接受）就能夠繼續使用了，此時用下列語句查詢數據庫中是否存在死鎖 select username,lockwait,status,machine,program from v$session where sid in (select session_id from v$locked_object) 和 select sql_text from v$sql where hash_value in (select sql_hash_value from v$session where sid in (select session_id from v$locked_object)) 返回為空，說明查詢的時候死鎖已經不存在了，為什么Oracle檢測到死鎖后，沒有任何人處理，死鎖又自己消失了，難道是Oracle后臺進程可以智能處理這些死鎖? 另外，在百度查到關于死鎖的處理方法，有這么一段話： 一般情況下，只要將產生死鎖的語句提交就可以了，但是在實際的執行過程中。用戶可能不知道產生死鎖的語句是哪一句。可以將程序關閉并重新啟動就可以了。 這個說法似乎也與前端應用A的用戶遭遇的情況差不多：有時候如果等待無反應，關閉A程序，然后重新運行就正常了。 請問百度里的這個說法是不是正確的？是不是以后遇到Oracle數據庫死鎖都可以無視它，因為Oracle可以自己解決？ --------------------------------------------------------------- 最近在寫存儲過程的時候，因為要測試存儲過程的運行情況，中途操作失誤，導致存儲過程死鎖，寫了半天的東西編譯不了了，沒辦法只能重新創建一個存儲過程，以前的那個刪也刪不掉，用也用不了，很難受，最后是重啟了數據庫才解決這個問題。不過現在找到一種更簡單的方法解決這個問題。 四步解決： 1、執行語句select object_name,machine,s.sid,s.serial# from v$locked_object l,dba_objects o ,v$session s where l.object_id　=　o.object_id and l.session_id=s.sid; 1 2 3 查出來哪些對象被鎖，得到sid 2、還是執行語句 alter system kill session '24,111'; (其中24,111分別是上面查詢出的sid,serial#) kill該session （sid,serial#即為上面查出來的sid和serial#） 注：此語句只是將該存儲過程的狀態由active改為了killed，并沒有徹底的釋放該存儲過程，所以還是編譯不了存儲過程 3、要解決這一問題只能在OS上殺死這一線程（進程）了 執行語句獲得線程（進程）號select spid, osuser, s.program from v$session s,v$process p where s.paddr=p.addr and s.sid=24 1 2 3 （24是上面的sid） 4、在服務器上執行下列命令（數據庫在哪臺機子，就在哪臺機子執行）orakill sid thread 1 orakill是oracle提供的命令，一般裝oracle的時候，已經配上環境變量，這里可直接運行 其中sid為該存儲過程所在數據庫的實例名我的為orcl thread即為線程（進程）號，即第三步查出來的spid。以上就是解決存儲過程的死鎖問題了，也是從別人那取經回來的東西，寫出來，主要就是為了加強記憶 ---------------------

?

總結

以上是生活随笔為你收集整理的oracle解除死锁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。