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

  如果對一個pipe有多個讀者，此時對於這個pipe的library cache object的library cache pin等待將會很正常routine,僅僅是短暫的.除了這個情況,
library cache waits相比很少發生，儘管更可能被延長.這些等待會超時（在3秒），如果超時的話，會發現死鎖。如果發生死鎖的話，lock或pin的請求會中斷並返回一個
ora-4020錯誤。這個錯誤一般就是由於ad hoc ddl所引起的.當然沒有必要專門編碼處理這個錯誤.
   
dml locks
  library cache pins和相關的row cache enqueue locks保護解析期間及執行呼叫期間的物件定義。但是，包括一系列語句的事務，同理也要在這個事務持有一個lock，以保護這個事務.

  而且（除此以外），鎖模式可能在這個事務期間會發生變化。比如，一個表首先被查詢，然後進行更新。也就是說鎖轉換是必要的。如果已存在的鎖被release，甚至暫時（立刻），有可能發生引用的物件被刪除或改變，這樣事務可能不能繼續或者rollback.

  rollback可能性，尤其rollback到某個儲存點，增加複雜度到dictionary locking字典鎖定。換句話說，如果一個事務rollback不在這個鎖升級的儲存點範圍之內,此時這個鎖必須發生對應的降級,作為rollback操作一部分，為了減少人工死鎖的可能性.

  執行事務需要dictionary locking,而且，特別要維護lock conversions的歷史變化資訊表(就是把事務中鎖轉換的資訊全記錄下來），它是透過dml lock及tm enqueues結合來達到這個目的。每個持有dml lock的事務同時會包含一個tm enqueue lock.
enqueue會提供基本的鎖定功能，dml lock會維護轉變歷史（鎖轉換）的資訊表.

  dml lock結構的固定佇列，由dml_locks來控制。它的自由列表由dml lock allocation latch給於保護，查詢v$locked_object會看到active slots.對於入隊資源和鎖，dml lock固定佇列的slots數目，對於效能的影響關係不大，只要你沒有用完free slots，否則會發生ora-55.
另外，v$resource_limit可以調整dml_locks，這樣確保不會發生以上情況。每個slot佔用116 bytes的順序,因此佔用大量的slots不是什麼問題.



disabling dml locks
   dml locks和對應的tm enqueue locks可以被禁用，你可以全部禁用，或者僅僅禁止用某些表。為了全部禁用這個鎖，
dml_locks必須被設定為0。在一個並行伺服器資料庫中，在所有例項中必須設定為0.為了禁用對於某個表的locks.必須要顯式指定alter table disable table locks.

   如果禁用了某個表的鎖，這樣dml 語句可以修改這個表的塊，同時持有row-level locks。但是，不會持有用於查詢情況的sub-shared mode的表鎖及用於dml的sub-exclusive mode的表鎖。相反它採用這樣的機制，在對一個表實行事務時，如果同時發生ddl操作，它只是簡單透過阻止所有對這個表加鎖的請求，而且防止所有對這個表的ddl操作.

   禁用dml locks和table locks有兩種原因。第一種，避免過多的得到鎖。在ops環境下，每個事務很短，這特別重要。在這種情況下，可能要花更多時間獲得tm instance lock比完成一個事務。


   在單例項資料庫下，獲得鎖的成本是很小的（微不足道）。但是，禁止表鎖會有效防止blocking lock問題.比如長期的blocking lock問題是由於鎖定整個表導致的，有時是由於ad hoc ddl，比如像一個索引，但往往可能是由於對引用表實行ad hoc dml引起的，這裡的關係沒有使用外來鍵索引.

   引用主表的外來鍵經常要構建索引，防止出現這種情況。但是，對於對這個表進行dml操作時，構建這種索引也會增加更多的成本。最好不用建立索引，防止禁用表鎖引起blocking locks問題。當然，在實行更新一個引用資料（表）或者重建索引時，需要暫時持有表鎖。但是，這並不難於實現，因為這種操作正常情況在一個特定的維護時間內進行.




   當然，最好是針對每個表禁用表鎖，而不是設定dml_locks為0來全部禁用它們。如果配置dml_locks為0,你可以建立臨時表，但不能刪除它們。如果你要進行某些維護操作：重建索引 ，你必須關閉和重啟系統二次.




buffer locks
   採用enqueue locking保護快取的database blocks.每個database buffer cache的buffer,都有一個buffer header.這些buffer headers在共享池固定記憶體部分組成一個固定佇列。這些buffer headers起到buffer locks的資源結構作用（或者講buffer header就是buffer lock的資源結構）.sessions會話操作buffer headers,進而操作buffers,透過buffer handles動態分配資源結構。這些
buffer handles相當於buffer  locks的lock structures.

   buffer lock只能要共享和排它模式下持有。buffer headers透過對buffer handles實現一個雙向連結串列，服務使用buffer的sessions，以及另外等待這些buffer會話，它們想拿到buffer handles.等待buffer lock的會話會報告可能是：buffer busy waits，或者buffer busy due to global cache waits,或者write complete waits.
buffer busy waits的引數如下：
   

 wait parameters(buffer busy waits)

引數                                          描述
p1                                            資料塊的檔案號
p2                                            檔案中資料塊的塊號
p3                                            等待原因.a或1014表明buffer被另一個會話以排它模式鎖定。這個會話正在從磁碟從一個block讀入到buffer中，因此這個讀不能完成目前.a表示用於consistent gets，這裡1014用於併發模式block gets，其它任何數字表明：buffer被另一個會話以排它模式鎖定




   buffer busy waits超時可能會在1到3秒之間被中斷或放棄。如果cache中某個block不能被程式持有buffer lock時，同時經歷了多次超時，如果會話對一個或多個其它的buffers持有buffer locks,這時會產生buffer lock deadlock.buffer lock deadlock之前的超時次數與嘗試的操作有關係，與它是否是離散事務的一部分也有關.因為離散事務不會持有事務鎖和行級鎖，它們必須
獲得在更新之前必須獲得所有的buffer locks，持有這些buffer locks直到事務準備完成這個更改和提交.這意味著離散事務會比正常的事務持有或佔有更多的buffer locks,且持有時間更長.

   如果懷疑出現buffer lock deadlock，想獲取一個buffer lock超時的會話，將會release持有其它buffers的lock,同時馬上又把這些released lock入隊，因此falling to到等待會話佇列的末端。它也給第一個程式（等待相關buffers的lock)傳送通知，然時讓出對應的cpu.雖然讓出cpu不是真正組成的等待，buffer deadlock wait會記錄下來，交換deadlocks統計的值會遞增。如果buffer lock
deadlocks發出event 370,分析它可以研究這個問題.
  
   在並行伺服器庫ops下，比如global cache操作（全域性快取操作）的寫操作為了響應ping請求，會鎖定buffers，塊伺服器程式進行直接記憶體傳遞時的一致性讀取consistent reads.如果請求一個buffer lock不能繼續下去，因為global cache operation會鎖定這個buffer,這時會生產（記錄下來）一個buffer busy due to global cache wait.

   同理，當請求buffer lock不能滿足（操作繼續下去），因為buffer被dbwn程式鎖定，用於以批處理方式寫入這些塊（從記憶體buffer cache到disk)，這時會記錄write complete waits。這些等待的超時是1秒，具體引數如下：
 

     wait parameters(write complete waits)

引數                                            描述
p1                                              資料塊所在的檔案號
p2                                              檔案中資料塊的塊號
p3                                              等待原因。正常的原因碼是1029;但是你會一直看到其它值



sort locks
    用於產生磁碟排序操作的磁碟空間.這裡有兩類sort locks:temprary table locks和sort segment locks.這些分別對應於
permanent表空間的臨時segments和termporary tablespace。在sga固定佇列會儲存及處理每種型別的sort lock(也就是剛說到的）。這兩個arrays大小由sessions來控制，請考慮使用sort locks的最大使用量.
    sort locks僅僅用於trace disk sort space使用情況，不會遭遇或碰到lock衝突，等待或死鎖。但是，你不要搞混sort locks和st(space transaction) enqueue,這特別可能產生鎖衝突，等待和一致even的死鎖。競爭st enqueue經常與disk sorts有關，因為建立，擴充套件，回收temporary segments要用到它。

   

parameters引數

  引數                                                                    描述
_distrubuted_lock_timout                                                  分散式事務上面鎖的超時。預設是60秒.

_enqueue_hash                                                             enqueue hash table大小

_enqueue_hash_chain_latches                                               用於訪問enqueue hash table的latch數目，預設是cpu count

_enqueue_locks                                                            enqueue lock結構的數量


dml_locks                                                                 dml locks固定佇列的大小。如果可能，禁用dml locking可以減少locking成本和出現blocking locks的風險


enqueue_resources                                                         enqueue resource佇列的大小



parallel_transaction_resource_timeout                                     在oracle 8.0中並行事務分支和另一個事務出現死鎖的超時


temporary_table_locks                                                     在oracle8中已經廢棄。它在oracle8.0存在，但已經不起任何作用了.






event事件


事件                                                                 描述

60                                                                   這是enqueue deadlock錯誤。如果重複發生這個情況，這種神秘的死鎖問題，你可能需要採用這個事件作一個systemstate dump，以分析或診斷引起死鎖問題的根源

370                                                                  buffer cache  deadlock會發出這個事件，用於調查或分析嚴重的buffer locking競爭，使用processstate dumps.

4020                                                                 這是library cache deadlock檢測錯誤，採用這個事件實行一個systemstate dump,你就會發現到底發生了什麼。反之，你不會發現這個。

4021                                                                 這是library cache deadlock超時錯誤。為何需要超時呢，因為library cache deadlock檢測機制不是exhaustive,而是過於昂貴。再次出現時，這個錯誤正常是由於ad hoc ddl引起





statistics統計
     統計                       資源（源處）                                   描述
enqueue conversions             v$sysstat                                      本地入隊轉化次數

enqueue deadlocks               v$sysstat                                      發現和中斷的本地入隊死鎖


enqueue releases                v$sysstat                                      本地入隊releases次數


enqueue requests                v$sysstat                                      本地入隊請求數


enqueue timeouts                v$sysstat                                      被中斷的本地入隊操作次數


enqueue waits                   v$sysstat                                      要等待入隊操作的次數，而不是等待的次數


exchange deadlocks              v$sysstat                                      本地buffer deadlock的數量。統計名字反映一個事實：索引 塊交換也可能是這種死鎖產生的原因之一


waits

 事件                                                      描述
buffer busy due to global cache                             獲取一個buffer上的本地buffer lock，因為當時發生global cache operation，如ping操作，而被阻塞




buffer busy waits                                           等待一個以非相容模式對本地buffer持有的鎖
                  


buffer deadlock                                             等待一個本地buffer lock發生死鎖



enqueue                                                      對本地和全域性入隊的等待



library cache load lock                                      如果兩個會話嘗試同時載入load一個物件的library cache information，就會發生這個鎖。相反，同時reload會引起library cache pin waits


library cache lock                                           等待引用或查詢處於(that is in flux)的library cache object


library cache pin                                            等待修改處於flux狀態的library cache object



row cache lock                                               等待獲取本地一個row cache enqueue或者一個row cache instance lock


write complete waits                                         等待一個block上面的一個buffer lock（它是正常批次寫的一部分）