您好,登錄后才能下訂單哦!
本篇內容主要講解“Oracle中的死鎖怎么理解”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Oracle中的死鎖怎么理解”吧!
死鎖Dead Lock
我們大家最早接觸死鎖這個概念可能是在操作系統課程中,說多個進程(線程)對一個可共享的資源進行請求的時候,可能出現死鎖。死鎖問題分為死鎖檢測、處理等多個子問題可以進行討論。
其實,死鎖問題絕不僅僅限制在操作系統乃至計算機科學領域。死鎖存在的兩個必要條件,一個是多任務工作的并發,另一個是共享資源的獨占性需求。只要一個系統(廣義系統)中存在這兩個前提,我們就認為可能出現死鎖的情況。
死鎖描述的是一種狀態。當兩個或兩個以上的任務單元在執行過程中,因為請求資源出現等待,因資源永遠不能獲得而相互等待的狀態。如果沒有外力的作用,死鎖狀態是會一直持續下去。死鎖是伴隨著多任務、并行操作產生的,在單任務情況下,一個任務單元可以使用并且獨占所有資源,不存在資源等待的情況,所以也沒有死鎖的情況。在進入多任務系統環境下,多個任務之間存在資源共享和獨占的需求,才可能出現死鎖。
死鎖最簡單的例子:任務A,B,資源1,2。任務A獨占了資源1,任務B獨占了資源2。此時,任務A要資源2,向任務B提出請求并等待。任務B要求資源1,并且也等待。AB兩者均不釋放所占有的資源,就造成了死鎖。
Oracle中的死鎖
Oracle是目前商業數據庫市場上表現最優秀的并發數據庫系統,同樣存在死鎖的威脅。存在并發、存在資源獨占,就有鎖lock或者類似鎖概念的機制。Oracle提供了多種類型鎖和多種鎖的機制,包括共享鎖和獨占鎖。并且,在進行各類型操作的時候,自動的對對象進行加鎖解鎖,以及鎖升級操作,最大可能的保證數據完整性。
那么,如果出現死鎖,Oracle會如何處理呢?
Oracle的鎖機制是建立在行鎖一級,在插入、更新行一級信息的時候,會加入獨占鎖內容。那么,我們嘗試模擬下出現死鎖的狀態。兩個session分別更新兩條記錄,在一個事務里再嘗試更新對方記錄,那么可以引發死鎖。
實驗環境準備:
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
此時,鎖的狀態為:
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)鎖住了兩行。下面繼續相互請求。
//session1中,嘗試更新id=2的記錄
SQL> update t set comm='Tst2' where id=2;
Session1(SID=152)被hange住。
//鎖狀態
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正在等待資源被釋放,表現就是停住操作,不斷的輪詢資源。
Session2請求更新:
//session2(SID=150)
SQL> update t set comm='Tst1' where id=1;
注意:此時,應當出現死鎖狀態,而在系統中,也出現了一瞬間的兩個session互相hange的狀態;
此時,session2繼續被hange住,原先的session1退出,如下狀態:
//session1(SID=152)
SQL> update t set comm='Tst2' where id=2;
update t set comm='Tst2' where id=2
ORA-00060: 等待資源時檢測到死鎖
結果是:Oracle在兩個出現死鎖的session中,隨機尋找了一個session,駁回了其被hange住的請求,維持另一方session的hange狀態。
注意:Oracle此處的處理:只是駁回了一方的請求,并沒有回滾該請求,也沒有將另一方的hange狀態解除。
思考:顯然,這個過程中是Oracle內部的防護機制起了作用,防止了系統中死鎖的發生。在Oracle中,存在某種輪詢的機制,隨時檢查系統中出現的多會話被hange住的情況,一旦發生,就將一個session被hange住的請求退回,拋出00060錯誤。
在兩個session互鎖的情況下,Oracle死鎖檢測程序可以起作用。那么,如果死鎖結構復雜的時候,是不是Oracle的檢測機制會失效。筆者使用4-5個session進行檢查,雖然檢測起效的時間有長有短,但最后都是將死鎖的狀態加以解除。
有一點需要注意,Oracle解決死鎖的方式只是將請求拒絕,并不是將事務回滾。所以,在解決死鎖之后,其他被hange住的session依然還是被hange住。所以,從應用程序和PL/SQL的角度,如果接受到了60錯誤,應該做的工作就是回滾當前事務,解決整體的資源爭用現象。
Oracle死鎖發生
那么,Oracle中死鎖發生的幾率是不是那么高呢?答案是否定的。這個是由Oracle鎖的特性所決定的。
1、 Oracle對查詢不加鎖。Oracle本身支持多版本一致讀,如果當前的數據塊正在被修改(獨占)而并未提交,Oracle會根據SCN查找日志和Undo空間,找到合適SCN的版本返回結果。所以,在查詢的時候,是不需要加鎖的。
2、 Oracle數據操作使用行級鎖(本質上是事務鎖),實現最小粒度的獨占范圍。Oracle在DML的時候,只會對操作的行進行獨占鎖定,而不是過大的數據單元(如頁page)。這樣,就保證了不會引起過多的獨占資源。
同時,Oracle本身也提供了死鎖監視程序功能,能及時發現死鎖狀態,并自動的進行解鎖。在這些機制下,Oracle認為死鎖發生的概率很低(起碼自身不會引起死鎖)。只有一種情況會引發死鎖,就是開發人員手工提高加鎖的級別。
Oracle對于SQL的拓展中,有一部分是顯示對象加鎖。從lock table XXX到select XXX for update。這些操作都會引起對對象鎖級別的提升,這些都可能引發死鎖的發生。
到此,相信大家對“Oracle中的死鎖怎么理解”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。