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的版本展示 ： https://docs.oracle.com/cd/E11882_01/server.112/e40402/dynviews_2027.htm 。

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

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后面。