2.2 隊列鎖（enqueue lock）
2.2.1 lock與latch的差別
oracle鎖（lock）也被稱為隊列鎖（enqueue lock），而latch則被稱作為“細粒度”的鎖。lock與latch的差別如表2-1所示。
不難看出：
oracle使用latch保護記憶體資料被間歇地、短持續地通路；
latch不适合保護持續時間相對較長的資源（resource），在這種情況下，就需要使用lock持續鎖定；
lock允許并發等待：目前不可擷取的resource會被放入請求隊列中進行排隊（fifo），這樣就避免了類似latch的spin等待；
lock允許多個session通路同一個resource（session互相相容），但是latch必須是獨占地排他通路。
2.2.2 常見的lock
oracle常見的lock有四種，下面将逐一介紹。
1.事務鎖和行級鎖
行級鎖（row-level lock）是oracle引以為傲的鎖定模式。當事務（transaction）更改了一行，那麼該事務的唯一标志（itl）就會被記錄在資料庫塊頭（data block header）中。
在transaction開始前，系統從復原段頭的事務表（undo transaction table list）中配置設定一個itl事務槽，同時将itl記錄到被事務影響的data block中。與此同時，被該事務影響更改的行将會使用lock bytes索引指向該itl。
有關itl以及事物的内容可參考第3章、第4章的相關内容。
這樣，當新的事務需要更改同一行時，将會發現有尚未送出的事務（uncommited tran-saction）正在修改該行，那麼該事務就會被阻塞等待（transaction block wait）。
一旦事務送出或者復原，事務鎖就會被釋放。即那個被阻塞等待的事務就鎖定該行了。
rollback to savepoint不能釋放先前的行級鎖，是以會阻塞後續對該行級鎖的擷取。隻有復原到事務開始的最初狀态或者事務送出後才能擷取該行級鎖。
buffer lock
行級鎖是保護資料中粒度較小的鎖，oracle提供了buffer block級别的鎖（buffer lock）來保護修改buffer cache中的buffer block。buffer lock僅提供了read/write鎖定模式，用于保護buffer block的完整性。
data dictionary lock
當資料庫字典對象（procedure、view等）被調用的時候，必須保證資料字典對象的完整性、有效性。資料字典鎖（data dictionary lock）就是用于保護資料字典對象完整性的，通過row cache enqueue locks進行保護。
pcm執行個體鎖
pcm執行個體鎖（parallel cache management instance lock）主要用于叢集環境中，保護分布式叢集資源的協調配置設定。
2.2.3 lock相關參數
oracle隊列鎖是通過enqueue hash chain結構實作的。當需要通路enqueue hash chain時，必須在“enqueue hash chains latches”保護下才能進行。
“enqueue hash chains latches”數量由參數_enquenue_hash_chain_latches決定，預設值為cpu數量。
1）檢視cpu數量：
可以看到，“enqueue hash chains latches”數量與cpu數量是一緻的。
2.2.4 lock先請求先服務機制
在多并發session的場景中，需要先擷取resource的x鎖定才能對該resource進行修改。與此同時，當其他session也同樣請求修改該resource時，則必須按照先請求先服務的方式進入請求隊列進行排隊等候。可以通過下面示例驗證。
可以看出：enqueue lock的擷取遵循先請求先服務的原則。是以，在高并發業務環境中，業務架構設計必須遵循這個原則，以保證資料庫的高并發運作。