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

Oracle研發工程師為了保證Cache Fusion的各個例項一致性使用了超過70種的佇列鎖,12.2版本有超過90種佇列。比如我們常見的HW，US，TX，TM，SS，LB等等。每一個版本的佇列資訊可以透過Oracle提供的v$lock進行檢視。比如我們最常用的11gR2的版本展示 ： 。

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#計算得到，單位為千分之一秒。

LMODE	REQUEST	ENQUEUE
非零	零	所有者
非零	非零	轉換者
零	非零	等待者

佇列和分散式管理

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

Non-PCM鎖請求流

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

鎖模式

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

鎖相容性原則

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

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

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

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

鎖轉換

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

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

·程式請求鎖定終止（刪除鎖定）。

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

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

資源鎖更改

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

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

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

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

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

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

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

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

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

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