Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1

沃趣科技發表於2019-08-05

Oracle研發工程師為了保證Cache Fusion的各個例項一致性使用了超過70種的佇列鎖,12.2版本有超過90種佇列。比如我們常見的HW,US,TX,TM,SS,LB等等。每一個版本的佇列資訊可以通過Oracle提供的v$lock進行檢視。比如我們最常用的11gR2的版本展示 https://docs.oracle.com/cd/E11882_01/server.112/e40402/dynviews_2027.htm

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1

Oracle的使用的佇列大致可以分為三種型別:

1.例項類:比如例項啟動和恢復,SCN同步;

2.事務類:比如library cache,dictionary cache,並行查詢。

3.使用者類:使用者自定義的佇列(enq:UL-contention)

佇列結構

當會話需要訪問指定資源的時候,就需要獲得鎖結構(ksqlk),請求以特定鎖模式獲得對資源的訪問。鎖請求的鎖結構屬於如下三個連結串列之一(所有者,等待者和轉換者)。可以根據v$lock檢視的LMODE列和REQUEST列區分所有者,等待者還是轉換者。平均等待時間可以通過v$enqueue_stat的cum_wait_time/total_wait#計算得到,單位為千分之一秒。

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1

        LMODE

REQUEST

ENQUEUE

非零

所有者

非零

非零

轉換者

非零

等待者


佇列和分散式管理

Oracle的本地佇列的申請在ksq層完成即可,對於全域性佇列則需要經歷ksi和kju層的申請。每一個佇列資源和鎖都對應分佈鎖管理的資源和鎖。如果存在當前事務,則事務識別符號(XID)是分佈鎖鎖定標識的一部分(Oracle使用它來做死鎖檢測)。如果沒有當前事務,鎖定標識則使用連線執行緒號(2個位元組),Oracle程式ID(2個位元組)和ksuseq的識別符號組成。對於每個Oracle程式而言,它們的ksuseq值始終以0開始然後遞增。

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1


Non-PCM鎖請求流

ksq層始終使用XID呼叫ksi層以申請建立分散式鎖。其他層(例如kqr或kqlm)在沒有XID(程式擁有)的情況下呼叫ksi層,因而不能使用DLM的死鎖檢測功能。

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1

鎖模式

在Cache fusion中佇列也可以視作一種資源,所以它會有不同模式的鎖,如下圖所示。細心的同學可以發現DLM lock和local lock的命名是不同的,Oracle稱之為“某些歷史”原因導致。

鎖相容性原則

1.相互相容的鎖可以同時存在於授權佇列中。

2.請求佇列上的鎖與授予佇列上的鎖不相容,並且與轉換佇列上的其他鎖不相容。

3.PR和CW組合存在特殊情況,PR與較小模式CW不相容。這就不允許從PR到CW的鎖降級。

4.GCS鎖定模式是用下劃線表示的。

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1

鎖轉換

鎖存在於資源授予或轉換佇列中。如果鎖模式發生更改,則它會在佇列之間發生移動。授予佇列中可以存在多個鎖,但是它們必須是相互相容的。相同模式的鎖不一定與另一個相同模式相容。在GES和GCS鎖之間各種鎖的相容性矩陣不同。同佇列的鎖轉換通常是降級,即轉換為較小的模式。存在一些例外情況,稍後會介紹。

鎖可以在以下任何條件下離開轉換佇列:

·程式請求鎖定終止(刪除鎖定)。

·程式取消轉換; 鎖被移回到授權佇列中以前的模式。

·請求的模式與Grant佇列中最高階別的鎖相容,請求的鎖在轉換佇列的前列(FIFO)並與先前的鎖模式相容。

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1

資源鎖更改

1. 會話A嘗試讀取一個資源這時它會在Grant佇列對資源新增授共享鎖(一致性)。

2.這時會話B申請共享讀鎖定。因為共享鎖是相互相容的,因此它們可以同時駐留在Grant佇列。

3.會話C申請共享讀鎖定,共享讀鎖被放置於Grant佇列中。

4.會話A持有的共享鎖轉換為NULL模式。因為這是一個簡單的降級,這種轉換可以在Grant佇列直接完成。

5.會話C嘗試更改資源因此持有的鎖嘗試轉換為獨佔模式,這時它必須放在轉換佇列。

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1

由於轉換佇列是先進先出(FIFO),這種情況下可能就會產生死鎖情況。

1.Grant佇列上現在有兩個共享的讀鎖和一個共享的寫鎖。

2.鎖A嘗試升級到獨佔模式。這個模式與B和C的模式不相容,因此它被放置在轉換上佇列。舊模式的資訊會保留防止轉換操作取消的情況。

3.鎖B嘗試升級到受保護的讀模式(不允許其他使用者寫)。此模式與C的模式不相容,因此也會北放置到轉換佇列中。

4.鎖C降級為NULL模式(對其他訪問沒有限制)。現在即使獨佔模式與NULL相容,但鎖定A無法完成轉換,因為與鎖B的舊共享讀取模式不相容。鎖B可以完成轉換,但它位於鎖A後面。

Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28218939/viewspace-2652672/,如需轉載,請註明出處,否則將追究法律責任。

相關文章