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

distributed transactions
  對於distributed transactions，oracle無法區別blocking locks和deadlocks,因為並不是所有的鎖資訊在本地可見.為了防止
distributed transaction 死鎖，oracle會超時分散式事務中的任何呼叫，如果它沒有接受_distributed_lock_timeout 秒之內
任何響應.預設是60秒。如果一個分佈事務超時，事務會產生ora-60.強健的應用處理異常的方式和本地入隊死鎖一樣.

   同樣oracle 8.0，並行事務，包括多個兄弟姐妹同級別的事務分支，死鎖和其它單一事務會發現不了（或者隱伏起來）。如果一個事務
受到一個全域性事務某個分支的阻塞，也可能阻塞另一個，此時會發現正常的死鎖。在oracle8.0中，發現不了這種死鎖。為了防止這個，oracle會超時
任何入隊鎖請求或者鎖轉變請求（在並行事務的一個分支），如果它是一個分散式事務，ora-99錯誤會產生.parallel_transaction_resource_timeout預設
為300秒，用它來控制超時。在oracle8.1情況下，採用死鎖檢測演算法來發現這些死鎖，因此超時設定沒必要了.
   

optimistic locking
   有這樣一個情形。兩個不同的人可能同時向兩個不同的操作員預訂一個特定的座位（機票）。那麼應用如何處理呢？
  
   應用使用select for update nowait檢索這個資訊。這樣就會保證，如果一個座位可以用，此時它已經被鎖定，預訂這個座位就會成功實現。這也叫作
早期鎖定，或者悲觀鎖.
   另一種方式（或鎖）會延遲這個鎖的持有，直到客戶決定或進行一個預定座位時才會持有這個鎖。這叫作樂觀鎖或晚期鎖定.
  
   在業務或應用程式中，到底選擇悲觀或樂觀鎖。需要很詳細全面的分析。悲觀鎖應該全力避免，但這樣可能加大或增加blocking locks的可能性，雖然很易於得到或實現.



 
itl entry shortage ---缺乏itl條目
    itl是database block中可以變化的頭部部分.當一個segment格式化一個新的block,segment會根據initrans配置它的初始itl數量.要是空間足夠，itl會根據情況動態增加.直到
database block的大小的最大限制。或者segment的maxtrans,取其最小的一個.

    修改一個block的事務必須在itl條目中，記錄它的事務標識和對於這個塊變更的rollback segment的address.（但是對於離散的事條，為這些變更是沒有對應的rollback segment address)。
oracle會查詢itl找到重用或空餘的條目（指itl entry)。如果    itl所有的entry被一個未提交的事務佔用完了，動態會增加一個itl entry，如果有可能.

    如果block沒有足夠的內部空閒空間（24bytes)來建立額外的itl entry,此時事務必須等待（它使用已存在的itl entry提交或rollback)。被阻塞事務會另一個事務，以共享模式（對於tx enqueue)，會隨機偽選擇。
v$session行等待列會顯示物件，檔案，目標塊的多少個塊數量.但是，如果row_wait_row#列顯示為unset(沒有配置），表明
這個事務沒有等待row-level lock,有可能在等待一個空閒的itl entry.
   
    itl entry shortage不足的最大原因是：配置pctree為0.所以配置pctfree為0一定要三思，在多個會話併發訪問某個資料塊時，使用不必要及過大的inittrans或pctfree，會損及資料密度，降低表掃描的效能.



   有一種情況，非預設的initrans配置對於pdml情況下的segments，不能保證它的效能.如果a pdml事務的子事務碰到itl entry不足，它將檢查其它itl entry（塊中）是否全部被它的兄弟姐妹事務佔有，如果是這樣的話，
這個事務將rollback，報出ora-12829錯誤，為了避免自有死鎖。處理這種問題就是採用低階或少量的parallelism.或者用
更高的initrans重建這個segment.





row cache enqueues
   data dictionary的rows快取會儲存在shared pool中。採用cache不僅會減少對於system tablespace之中data dictionary tables的物理讀取次數，而且開啟每個對於data dictionary rows的精細粒度的locking.
對於data dictionary rows的鎖，叫作row cache enqueue locks.被快取的data dictionary rows起到resource structure的作用，enqueue lock structure會根據需要動態從共享池中分配。locks可以請求，轉化，release.
這種請求可以等待或超時，就像一般的入隊鎖一樣.
   但是，在v$lock中是看不到row cache enqueue locks資訊。事實上，只能在system 或process的state dumps中可以看到.
  
   根據操作情況，一些row cache enqueue locks透過no-wait mode請求。如果不能馬上得到鎖，會產生ora-54錯誤。否則，
如果可能row cache requests會入隊，程式等待一個row cache lock wait.



 
wait parameters(row cache lock waits)
 
引數                                               描述

p1                                                 v$rowcache cache#列表示row lock對應的data dictionary table

p2                                                 已經持有鎖的模式

p3                                                 必須以何種模式持有鎖





  以上所指的持有鎖模式表示的編號，只是針對於例項鎖，而不是本地locks，甚至執行單例項資料庫時.但是，這種等待在單例項下很少發生，僅僅只會發生於資源衝突，然而在並行服務中很普遍，因為新的鎖請求必須透過分散式鎖管理器dlm來socialized.


   oracle並不期望row cache enqueue lock的獲取和轉變，阻塞一些時間.因此，row cache locks等待時間每三秒會超時，假如100次超時（5分鐘），會產生一個內部死鎖，操作會中斷。同時會往alert寫入"waited too long for a row cache enqueue lock"資訊.另外，一個程式state dump會寫入到trace file.
除了對於一個長時間執行，正在發生作用的過程，或包進行ddl時，這個錯誤被視為bug.



library cache locks and pins
   library cache不是一個cache,而是好多少cache.它包含好多的pl/sql程式單元的虛擬碼。它包含解析樹和共享sql語句的執行計劃。它也包含sql語句所引用物件的某種抽象的diana形式.這些資訊用於pl/sql程式單元編譯及sql語句的解析及執行,儘管事實上是，dictionary cache包含不同形式的相同資訊.library cache也包含
像同義詞轉化，依賴跟蹤資訊，及library cache locks和pins的控制結構.

   library cache locks在oracle文件中叫作易碎的解析鎖。它們用於sql語句的library cache objects及pl/sql程式單元，以及遞迴對它們所引用的database object的library cache objects.library cache locks在解析操作被共享模式持有，其後會轉化為null mode.如果以後ddl語句修改一個資料物件的定義，這時這個物件的library cache 資訊及所有依賴的
library cache object會變成不合理，透過中斷這個library cache locks.
  
   但是，當library cache object沒有被pinned時，library cache locks被中斷。一個pin用於pl/sql程式單元的library cache object或者sql語句，當這些物件正在被編譯，解析，或執行時。pins一般情況以共享模式持有，但如果物件的library cache資訊被改變，必須以排它模式持有鎖.library cache object如：pipes和序列大多發生變化時。當一個library cache
object被pinned時，相反pins用於所有被引用的物件。當一個pin用於資料庫物件的library cache object,此時需要一個data dictionary row(基礎的）所對應的row cache enqueue lock,因此可以防止產生衝突的ddl.


   library cache中每個物件具有一個控制程式碼，它起到library cache locks和pins的資源結構。控制程式碼，鎖，pin結構所以從共享池中動態分配。控制程式碼會對持有的鎖實行雙向連結串列，等待的鎖，持有的pins,等待的pins.



wait parameters(library cache lock and library cache pin waits)


引數                                                        描述
p1                                                          記憶體中library cache handle的地址

p2                                                          鎖的記憶體地址或pin的結構

p3                                                          鎖模式或請求的pin,物件的名字空間namespace,是以10*mode+namespace編號方式來表示。
                                                             這種情況下，模式如下：
                                                                   2 shared
                                                                   3 exclusive
                                                                名字空間有:
                                                                   0 cursor
                                                                   1 table,procedure,and others
                                                                   2,package body
                                                                   3,trigger
                                                                   4,index
                                                                   5,cluster
                                                                   6,object
                                                                   7,pipe