探索系列——神人steve adams之著oracle8i interal service(十二）

     例項鎖instance locks用於例項內部鎖定locking及ops資料庫多個例項的通訊.雖然instance locks很少或沒有用於單例項資料庫中，但是大師建議大家還是要好好閱讀本章內容.


     單例項資料庫它僅僅只是並行伺服器的一種特別例子，你將會發現它的許多操作理解或領會，除非你理解一般或通用的案例。

    

the lock manager
   管理instance locks的哪部分oracle叫作the lock manager.the lock manager這部分或這層的功能會影響所有程式的操作.
但是，最明顯的證明或影響就是，你會發現存在許多（一系列）的lock management processes（也叫鎖管理程式），以及每個例項中關於例項例資訊的記憶體資料庫(取原文：and an in-memory database of instance lock information in each instance)

   the lock manager是採用分散式管理的。並沒有一個所謂中心控制。每個例項僅維護它感興趣的例項鎖的相關資訊.the lock manager也可以講是整合或綜合（整合的）。這是因為，oracle8以前，lock management的功能是需要由每個具體的os提供的。但從oracle8以
後，這個功能整合到了oracle kernel.
   
  
   雖然lock管理器整合到了oracle核心中，需要一個鎖控制程式碼的程式不會訪問例項鎖資料庫來直接分配一個鎖控制程式碼。相反，它們還是會構建併傳送一個訊息到lmdn後臺程式，同時等待lmdn程式返回一個鎖控制程式碼.這個訊息標識這個資源，同時配置一些選項，用於決定鎖的獲取和隨後的管理.


   如果本地例項鎖資料庫不存在這個資源，會從例項鎖資源表the instance lock resource table中獲得一個slot.
the instance lock database.如果曾經這個資源上面的鎖被release，它被保留下來，這個資源被打個一致性的標誌（或稱一致性資源）.從資源標識中計算出來目錄結點，同時主節點標誌為未知（除非資源是一致性的）。一旦本地例項鎖資料庫存在這個資源的話，例項鎖表the instance lock table的一個slot
會分配給這個鎖。它的程式或組所有權（所有者關係）會建立起來,設定死鎖檢測引數.lmdn後臺程式此時會構建繼而傳送一個響應資訊給客戶端程式。這個資訊叫作一個獲取非同步trap,或者叫獲取ast.這個獲取ast訊息包含一個鎖控制程式碼.

    等待lmdn程式返回一個鎖控制程式碼的程式，會去等待一個dfs lock handle等待事件(a dfs lock handle wait).dfs代表分散式檔案系統,它是oracle例項鎖管理功能的舊稱。鎖控制程式碼等待應該是很短暫的，因為
    instance locks的鎖及資源結構駐存在一個sga專有的區域中，被叫作例項例資料庫(the instance lock database).鎖及資源佇列大小由lm_locks和lm_ress來控制。第三個引數lm_procs定義持有這些鎖的例項及程式佇列的大小.這個佇列對於每個本地程式要一個slot，每個遠端例項也是一個slot.

   the instance lock database也包含一系列程式組.在這種情況下，instance locks可能被一組程式所持有，而不是單一的程式。組鎖關係(group lock ownership)允許多執行緒伺服器會話在共享伺服器程式之間遷移，允許從一個程式分離出來的oci事務然後在一個不同的程式上繼續。所有鎖獲取請求可以指定程式或者指定
組所有者.一個程式組的所有成員會在instance lock database中自動trace及infer.程式組內部的以組持有group-owned方式的例項鎖的交換，不需要任何lock或者轉換。程式組佇列的大小由_lm_groups引數來控制，預設為20.
  

例項鎖資料庫the instance lock database包含除了資源之外的其它一些結構，像鎖，程式，程式組.透過hash table訪問這些佇列；資源結構用於記錄統計資訊，管理等待和超時，檢測死鎖，實行恢復；還有一部分記憶體用於儲存訊息緩衝message buffers（這些message buffers用於例項內部的通訊）。buffers大小是由_lm_send_buffers來控制，預設為10000.


例項鎖資料庫大多部分在資料庫啟動後是不變的（固定的）。但是，oracle有這個一個選項或叫權利吧，如果有可能,為了額外動態分配資源和鎖，會從共享池中分配記憶體。如何發生這些，一個訊息會寫入alert,同時對應的引數會在下次資料庫重啟遞增，除非是由於另一個例項恢復引起的overrun（過量），就如gv$dlm_misc(dlm表示分散式鎖管理）.注意：
動態分配出來的記憶體不會再次重新release到共享池中.


lock mastering


   例項鎖資料庫是一個分散式資料庫.很少或沒有單節點會trace所有資源的鎖。對於每個資源，會有一個主節點master node.這個資源的主節點會儲存這個資源上面所有鎖的完全或全部資訊。其它節點只需要維護從本地持有這個資源鎖的相關資訊。為了動態分配資源，主節點一般情況是首次得到或獲取這個資源鎖的節點.對於每個資源，也會有一個目錄節點,它包含或維護指向主節點的指標資訊(可以理解為索引）。使用基於資源確認的一個hash function方式可以確定這個目錄節點。對於持續性的資源，
主節點經常就是目錄結點.
   只要發生這些情況：由於例項啟動或關閉，或者因為某節點例項的故障，活動例項會發生變化，這時節點對分配的資源必須要發生變化或者叫調整.一般而言，每個資源的主節點及目錄節點可能改變，這些必需資訊必須在每個節點重新構建或叫重建.如果一個例項出現故障，例項恢復的前滾roll forward（或叫cache recovery)必須完成以後，才可以進行驗證所有的例項鎖資訊是否合理或正確.

   例項鎖資料庫會在資源重新分配和cache recovery期間進行凍結，如何可能（適用或合理）。在這個期間啊，本地活動可以繼續進行，但它們只能在已經持有例項鎖的情況下進行.但是，如果一個例項沒有或丟掉這個例項鎖，哪它只能以只讀方式訪問記憶體中已經存在的資料，並且還在已經持有一個例項鎖.這是一個非常嚴重的約束或規定.
你應該嘗試限制資源重分配和例項恢復前滾的時間，這可以透過使用適度的資源數量和鎖,也可以配置檢查點活動確認可控制的恢復時間.


 

lock handle acquisition  獲得鎖控制程式碼

    大多例項鎖以兩步法（在兩個步驟中）獲取。第一個步驟：得到一個鎖控制程式碼，這是一個鎖的識別符號，可以實現隨後轉變或者release操作（對例項鎖）.當然，一些例項鎖會在整個例項生命週期內持有，也不會發生轉變或release.這種例項鎖在一個步驟就可以得到，不會返回鎖控制程式碼.