本篇內(nèi)容主要講解“Oracle中的死鎖怎么理解”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“Oracle中的死鎖怎么理解”吧!

10年積累的網(wǎng)站設(shè)計、成都做網(wǎng)站經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先網(wǎng)站設(shè)計后付款的網(wǎng)站建設(shè)流程，更有皇姑免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

死鎖Dead Lock

我們大家最早接觸死鎖這個概念可能是在操作系統(tǒng)課程中，說多個進程（線程）對一個可共享的資源進行請求的時候，可能出現(xiàn)死鎖。死鎖問題分為死鎖檢測、處理等多個子問題可以進行討論。

其實，死鎖問題絕不僅僅限制在操作系統(tǒng)乃至計算機科學(xué)領(lǐng)域。死鎖存在的兩個必要條件，一個是多任務(wù)工作的并發(fā)，另一個是共享資源的獨占性需求。只要一個系統(tǒng)（廣義系統(tǒng)）中存在這兩個前提，我們就認為可能出現(xiàn)死鎖的情況。

死鎖描述的是一種狀態(tài)。當(dāng)兩個或兩個以上的任務(wù)單元在執(zhí)行過程中，因為請求資源出現(xiàn)等待，因資源永遠不能獲得而相互等待的狀態(tài)。如果沒有外力的作用，死鎖狀態(tài)是會一直持續(xù)下去。死鎖是伴隨著多任務(wù)、并行操作產(chǎn)生的，在單任務(wù)情況下，一個任務(wù)單元可以使用并且獨占所有資源，不存在資源等待的情況，所以也沒有死鎖的情況。在進入多任務(wù)系統(tǒng)環(huán)境下，多個任務(wù)之間存在資源共享和獨占的需求，才可能出現(xiàn)死鎖。

死鎖最簡單的例子：任務(wù)A，B，資源1，2。任務(wù)A獨占了資源1，任務(wù)B獨占了資源2。此時，任務(wù)A要資源2，向任務(wù)B提出請求并等待。任務(wù)B要求資源1，并且也等待。AB兩者均不釋放所占有的資源，就造成了死鎖。

Oracle中的死鎖

Oracle是目前商業(yè)數(shù)據(jù)庫市場上表現(xiàn)最優(yōu)秀的并發(fā)數(shù)據(jù)庫系統(tǒng)，同樣存在死鎖的威脅。存在并發(fā)、存在資源獨占，就有鎖lock或者類似鎖概念的機制。Oracle提供了多種類型鎖和多種鎖的機制，包括共享鎖和獨占鎖。并且，在進行各類型操作的時候，自動的對對象進行加鎖解鎖，以及鎖升級操作，最大可能的保證數(shù)據(jù)完整性。

那么，如果出現(xiàn)死鎖，Oracle會如何處理呢？

Oracle的鎖機制是建立在行鎖一級，在插入、更新行一級信息的時候，會加入獨占鎖內(nèi)容。那么，我們嘗試模擬下出現(xiàn)死鎖的狀態(tài)。兩個session分別更新兩條記錄，在一個事務(wù)里再嘗試更新對方記錄，那么可以引發(fā)死鎖。

實驗環(huán)境準(zhǔn)備：

SQL> desc t;

Name Type         Nullable Default Comments

---- ------------ -------- ------- --------

ID   NUMBER                                 

COMM VARCHAR2(10) Y                        

SQL> select * from t where rownum<3;

        ID COMM

---------- ----------

         1 Tst1

         2 Tst2

兩個session，分別針對id=1,2兩條記錄做文章。

//Session1

SQL> select sid from v$mystat where rownum<2;

       SID

----------

       152

SQL> update t set comm='Tst1' where id=1;

1 row updated

//Session2

SQL> select sid from v$mystat where rownum<2;

       SID

----------

       150

SQL> update t set comm='Tst2' where id=2;

1 row updated

此時，鎖的狀態(tài)為：

SQL> select * from v$lock where sid in (150,152);

ADDR     KADDR           SID TYPE        ID1        ID2      LMODE    REQUEST

-------- -------- ---------- ---- ---------- ---------- ---------- ----------

333415A4 333415BC        152 TM        54599          0          3          0

33341668 33341680        150 TM        54599          0          3          0 

3338A42C 3338A548        150 TX       393251        795          6          0 

333B8954 333B8A70        152 TX       327686        779          6          0

此時，我們看到了在兩個session中，分別使用了行鎖，獨占（LMODE=6）鎖住了兩行。下面繼續(xù)相互請求。

//session1中，嘗試更新id=2的記錄

SQL> update t set comm='Tst2' where id=2;

Session1（SID=152）被hange住。

//鎖狀態(tài)

SQL> select * from v$lock where sid in (150,152);

ADDR     KADDR           SID TYPE        ID1        ID2      LMODE    REQUEST

-------- -------- ---------- ---- ---------- ---------- ---------- ----------

33834398 338343AC        152 TX       393251        795          0          6 

333415A4 333415BC        152 TM        54599          0          3          0 

33341668 33341680        150 TM        54599          0          3          0 

3338A42C 3338A548        150 TX       393251        795          6          0

333B8954 333B8A70        152 TX       327686        779          6          0 

說明：在Oracle中，hange表示session正在等待資源被釋放，表現(xiàn)就是停住操作，不斷的輪詢資源。

Session2請求更新：

//session2（SID=150）

SQL> update t set comm='Tst1' where id=1;

注意：此時，應(yīng)當(dāng)出現(xiàn)死鎖狀態(tài)，而在系統(tǒng)中，也出現(xiàn)了一瞬間的兩個session互相hange的狀態(tài)；

此時，session2繼續(xù)被hange住，原先的session1退出，如下狀態(tài)：

//session1（SID=152）

SQL> update t set comm='Tst2' where id=2;

update t set comm='Tst2' where id=2

ORA-00060:等待資源時檢測到死鎖

結(jié)果是：Oracle在兩個出現(xiàn)死鎖的session中，隨機尋找了一個session，駁回了其被hange住的請求，維持另一方session的hange狀態(tài)。

注意：Oracle此處的處理：只是駁回了一方的請求，并沒有回滾該請求，也沒有將另一方的hange狀態(tài)解除。

思考：顯然，這個過程中是Oracle內(nèi)部的防護機制起了作用，防止了系統(tǒng)中死鎖的發(fā)生。在Oracle中，存在某種輪詢的機制，隨時檢查系統(tǒng)中出現(xiàn)的多會話被hange住的情況，一旦發(fā)生，就將一個session被hange住的請求退回，拋出00060錯誤。

在兩個session互鎖的情況下，Oracle死鎖檢測程序可以起作用。那么，如果死鎖結(jié)構(gòu)復(fù)雜的時候，是不是Oracle的檢測機制會失效。筆者使用4-5個session進行檢查，雖然檢測起效的時間有長有短，但最后都是將死鎖的狀態(tài)加以解除。

有一點需要注意，Oracle解決死鎖的方式只是將請求拒絕，并不是將事務(wù)回滾。所以，在解決死鎖之后，其他被hange住的session依然還是被hange住。所以，從應(yīng)用程序和PL/SQL的角度，如果接受到了60錯誤，應(yīng)該做的工作就是回滾當(dāng)前事務(wù)，解決整體的資源爭用現(xiàn)象。

Oracle死鎖發(fā)生

那么，Oracle中死鎖發(fā)生的幾率是不是那么高呢？答案是否定的。這個是由Oracle鎖的特性所決定的。

1、 Oracle對查詢不加鎖。Oracle本身支持多版本一致讀，如果當(dāng)前的數(shù)據(jù)塊正在被修改（獨占）而并未提交，Oracle會根據(jù)SCN查找日志和Undo空間，找到合適SCN的版本返回結(jié)果。所以，在查詢的時候，是不需要加鎖的。

2、 Oracle數(shù)據(jù)操作使用行級鎖（本質(zhì)上是事務(wù)鎖），實現(xiàn)最小粒度的獨占范圍。Oracle在DML的時候，只會對操作的行進行獨占鎖定，而不是過大的數(shù)據(jù)單元（如頁page）。這樣，就保證了不會引起過多的獨占資源。

同時，Oracle本身也提供了死鎖監(jiān)視程序功能，能及時發(fā)現(xiàn)死鎖狀態(tài)，并自動的進行解鎖。在這些機制下，Oracle認為死鎖發(fā)生的概率很低（起碼自身不會引起死鎖）。只有一種情況會引發(fā)死鎖，就是開發(fā)人員手工提高加鎖的級別。

Oracle對于SQL的拓展中，有一部分是顯示對象加鎖。從lock table XXX到select XXX for update。這些操作都會引起對對象鎖級別的提升，這些都可能引發(fā)死鎖的發(fā)生。

到此，相信大家對“Oracle中的死鎖怎么理解”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！