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

Oracle研發(fā)工程師為了保證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的使用的隊列大致可以分為三種類型：

1.實例類：比如實例啟動和恢復(fù)，SCN同步；

2.事務(wù)類：比如library cache，dictionary cache，并行查詢。

3.用戶類：用戶自定義的隊列（enq:UL-contention）

當(dāng)會話需要訪問指定資源的時候，就需要獲得鎖結(jié)構(gòu)（ksqlk），請求以特定鎖模式獲得對資源的訪問。鎖請求的鎖結(jié)構(gòu)屬于如下三個鏈表之一（所有者，等待者和轉(zhuǎn)換者）?？梢愿鶕?jù)v$lock視圖的LMODE列和REQUEST列區(qū)分所有者，等待者還是轉(zhuǎn)換者。平均等待時間可以通過v$enqueue_stat的cum_wait_time/total_wait#計算得到，單位為千分之一秒。

Oracle的本地隊列的申請在ksq層完成即可，對于全局隊列則需要經(jīng)歷ksi和kju層的申請。每一個隊列資源和鎖都對應(yīng)分布鎖管理的資源和鎖。如果存在當(dāng)前事務(wù)，則事務(wù)標(biāo)識符（XID）是分布鎖鎖定標(biāo)識的一部分（Oracle使用它來做死鎖檢測）。如果沒有當(dāng)前事務(wù)，鎖定標(biāo)識則使用連接線程號（2個字節(jié)），Oracle進程ID（2個字節(jié)）和ksuseq的標(biāo)識符組成。對于每個Oracle進程而言，它們的ksuseq值始終以0開始然后遞增。

ksq層始終使用XID調(diào)用ksi層以申請創(chuàng)建分布式鎖。其他層（例如kqr或kqlm）在沒有XID（進程擁有）的情況下調(diào)用ksi層，因而不能使用DLM的死鎖檢測功能。

鎖模式

在Cache fusion中隊列也可以視作一種資源，所以它會有不同模式的鎖，如下圖所示。細(xì)心的同學(xué)可以發(fā)現(xiàn)DLM lock和local lock的命名是不同的，Oracle稱之為“某些歷史”原因?qū)е隆?/span>

鎖兼容性原則

1.相互兼容的鎖可以同時存在于授權(quán)隊列中。

2.請求隊列上的鎖與授予隊列上的鎖不兼容，并且與轉(zhuǎn)換隊列上的其他鎖不兼容。

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

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

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

鎖可以在以下任何條件下離開轉(zhuǎn)換隊列：

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

·進程取消轉(zhuǎn)換; 鎖被移回到授權(quán)隊列中以前的模式。

·請求的模式與Grant隊列中最高級別的鎖兼容，請求的鎖在轉(zhuǎn)換隊列的前列（FIFO）并與先前的鎖模式兼容。

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

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

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

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

5.會話C嘗試更改資源因此持有的鎖嘗試轉(zhuǎn)換為獨占模式，這時它必須放在轉(zhuǎn)換隊列。

由于轉(zhuǎn)換隊列是先進先出（FIFO），這種情況下可能就會產(chǎn)生死鎖情況。

1.Grant隊列上現(xiàn)在有兩個共享的讀鎖和一個共享的寫鎖。

2.鎖A嘗試升級到獨占模式。這個模式與B和C的模式不兼容，因此它被放置在轉(zhuǎn)換上隊列。舊模式的信息會保留防止轉(zhuǎn)換操作取消的情況。

3.鎖B嘗試升級到受保護的讀模式（不允許其他用戶寫）。此模式與C的模式不兼容，因此也會北放置到轉(zhuǎn)換隊列中。

4.鎖C降級為NULL模式（對其他訪問沒有限制）?，F(xiàn)在即使獨占模式與NULL兼容，但鎖定A無法完成轉(zhuǎn)換，因為與鎖B的舊共享讀取模式不兼容。鎖B可以完成轉(zhuǎn)換，但它位于鎖A后面。