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

block pings
       如果一個遠端例項需要以非相容模式獲取一個本地例項已有持有的鎖,這時持有這個鎖的lckn程式將接受到來自本地例項的lmdn程式的
一個bast資訊.如果目前或現在由lock element所保護的blocks皆不在cache中，或者在cache但是以相容模式存在,這時或那麼
lckn程式會馬上降級鎖的模式級別.但是，如果在cache中的由block element所保護的任何blocks是以非相容模式存在,那麼這些鎖不能降級直到塊的狀態發生變化才可以.
為了響應一個bast而改變快取中塊的狀態，這叫作一個ping.
     
       快取的塊可能有三種狀態。首先，它們可能會處於當前current或不新鮮（陳舊的）stale.快取中存放的陳舊的塊複製（備份）,這是為了滿足長時間執行的查詢.這類的查詢需要
一致性讀consistent reads.也就是說（那就是），自查詢開始時，發生修改的塊需要被rollback,為了查詢得到的結果將會反映當這個查詢（或者事務開始）進行時刻的資料庫的哪個一致性
快照.在cache中為了一致性讀保留塊的陳舊複製，可以減少為了查詢發必須需要的rollback changes.因為這個，仍舊在cache中的陳舊塊複製，可以稱為處於一致性讀狀態consistent read(cr)
state.請注意：cr也是併發讀鎖concurrent read lock mode的簡稱，它可能是一直引起迷惑不解的原因吧.
   (特別注意：我在此講的這種塊的狀態，但包含這些塊的緩衝狀態，和這個是兩回事）


      處於非陳舊的快取塊，就是當前的或處於當前狀態.當前狀態的塊current blocks會有兩種狀態,就是乾淨的clean或者髒的（未提交的）dirty.如果當前塊發生了變化或修改，但依舊沒有被寫入到磁碟，這個當前塊就是髒的.
如果這個當前塊沒有發生變化且所有變化已被寫入磁碟，這叫作clean乾淨的當前塊.


      pings這個操作只會影響當前塊.如果一個遠端例項需要對一個lock element施加一個共享鎖,這時由本地lock element所保護的任何dirty blocks需要寫入到磁碟，因此它們就是cleaned.當這些塊是clean時，lock element之上的本地鎖就會降級
過程共享模式.但是，如果一個遠端例項需要改變這個塊,這時它會請求對它的lock element加一個排它鎖.由本地lock element保護的任何dirty blocks需要寫入磁碟,clean block必須被標記為stale;這就是說，
它們必須被轉變為一致性讀狀態.lock element之上的本地鎖然後會降級到null mode.


      影響dirty blocks且讓dirty blocks寫入磁碟的pings，就是hard pings.但是公僅影響blocks的狀態，標記它們為stale的這種型別的pings，叫作soft pings.hard pings是強制寫入的一種形式.為了響應checkpoint object,重用block range，write
buffer cross-instance calls，這些會觸發強制寫forced writes.soft pings是快取不合理或無效的一種形式,它使用一個塊變為stale.快取不合理或無效也會在這些情況下發生：響應重用block range ci calls(cross-instance).強制讀，可以查詢gv$bh,這種情況是
：cache無效或不合理之後，一個例項必須把這個塊讀回到cache中.


     在hashed locking情況下，一個ping會影響多個快取的塊。同樣，也有可能一個ping會影響除了遠端例項所需要的其它塊.對遠端例項所需要的塊，其它塊的ping，這叫作false pings.true pings就是遠端例項ping所需要的塊，也僅僅只影響這些塊.
fine-grained locking不可能出現false pings,因為每個lock element只會保護一個block.

     pings是ops的主要效能問題.gv$file_ping包含每個資料檔案發生ping的詳細資訊,以及其它的強制寫和塊無效資訊.為了減少pings,調優一個ops時，對於精確定位問題，這個資訊是很有價值的.




consistent read requests
     oracle使用許多最佳化方法減少pings次數和它們的影響.查詢僅僅需要資料聲的一致性讀複製，沒有必要得到當前塊的映象.
如果本地快取發現，塊的一個陳舊複製新於current查詢的致性讀scn,這時會使用塊的一個陳舊複製.如果lock element沒有被遠端例項以排它模式鎖定,這時會採用共享模式鎖並且塊會從磁碟讀取，同時根據需要進行rollback.但是，如果遠端例項持有一個排它鎖，oracle
必須從例項得到一個這個塊的合適的讀一致性的複製.具體如何實現和oracle release有關.

     在oracle8中，oracle先去ping這個塊。但是，如果這個塊在遠端例項非常熱,6秒之後這個ping請求會發生超時（或者_cr_deadtime引數）.這種情況下，oracle使用一個write buffer cross-intance call，觸發遠端例項的dbwn程式把當前buffer寫到磁碟上.這個塊然後
從磁碟被讀入，根據需要進行rollback.但是一般情況下，rollback操作需要對於來自遠端例項的rollback segment blocks的更多呼叫次數.


     在oracle8.1中，oracle使用一個替代的ci call來觸發遠端block server process構建所需的塊一致性讀拷，然後直接把它傳遞到客戶端例項上.但是如果，遠端例項在快取中沒有這個塊的當前複製的話,這時允許客戶端例項從磁碟讀取這個塊的當前映象，然後實行必需的rollback.
這會反映在global cache cr blocks received和global cache cr blocks read from disk統計資訊中.


     oracle計劃擴充套件或加強block service特徵，包括在以後的oracle release之中傳遞當前模式的塊或叫current mode blocks.





deferred ping responses
     oracle為了減少ping影響所採用的另一個最佳化方法，就是以10 centiseconds單元來延遲響應hard pings，或者配置gc_defer_time.這個值足夠長得允許活動事務完成對塊目前一系列的改變，同時在block header中標誌它們（指這些塊）完成,以便遠端例項在讀取這個塊之後，不用再馬上檢查事務的狀態.
檢查遠端事務（遠端例項的事務)是一個非常高成本的操作,因為它需要對transaction的rollback segment header block進行一個ping,這肯定是一個非常熱的塊.

    調節gc_defer_time的問題就是權衡ping的次數和對於pings的響應時間,可以非常方便地用alter system動態進行調節.但是，如果pings要花費過長時間來處理，就會導致對於lock element的本地操作可能過度地延遲.這種情況會觀察到global cache lock busy waits.這個等待的超時是1秒，其等待引數和其它global
cache lock waits一樣.


    oracle另一個減少ping影響的最佳化方法，就是在每次ping後，自動地把一個轉變請求排隊，用於還原它的鎖模式.在oracle 8上使用_upconvert_from_ast來禁用它.
同樣，oracle有時或往往過早持有一個排它鎖，其實這不是減少鎖轉變次數所必須的.這可以用_save_escalates來禁用它.這些引數配置在正常情況下不用改變.
特別是假如它們(塊）全域性可見並且發生改變.但是假如使用一個非常大的blocking factor,這樣有時大量的buffers將會連結到個別（或獨自的）的blocking factor,這樣
會發生對覆蓋這些lock elements的lock element parent latches的競爭.而且，假如表中存在一些熱點區域，設定一個大點的blocking factor會增加發生false pings的可能性.
然而，



workload partitioning

      當前，減少pings的最好方法就是對工作負荷進行分割槽（分割），這樣每個例項就可以使用獨有的資料集.只需要你用小小的想像力，對於大量的工作，對大多工作負荷進行分割或分割槽是最好或令人滿意的.比如，一個方法（途徑），就是使用一個tp monitor和oracle的xa庫的三層架構，根據所需要的資料集，把全域性事務分支引導到不同的
例項上.


      另一種好方法就是優先接受或包含分散式資料庫技術,而不是並行伺服器技術.例項鎖的成本會極大增加應用的反應時間,
甚至在理想的工作負荷分割槽情況.其實這些成本可以忽略及替代，就是採用僅僅影響分散式事務的更為適度的網路反應latencies,只要你對資料和工作負荷進行分割槽，對應到不同的分散式資料庫.


      如果需要可伸縮性，就應採用或採納一個並行伺服器架構,前提是如果對資料和工作負荷進行分割槽到一系列的分散式資料庫不合理的話.一個並行伺服器資料庫的效能與一個對等的分散式或者單例項資料庫相比，經常是表現一般或普通.並行伺服器只是在大工作負荷的可伸縮性情況下，表現傑出.


     但是你必須意識到,並行服務度的可伸縮性不是自動進行的.詳細進行工作負荷分割槽是很有必要的.工作負荷分割槽不是會減少pings,而且會減少一個並行伺服器資料庫獲取例項鎖的成本--特別是，inter-instance message passing例項間訊息傳遞.


 


blocking factor

    這裡有一種提升或改進並行伺服器可伸縮性的方式，但這種變化不是馬上生效的（immediately obvious),但會導致pings和鎖獲取資訊的極大節省.


    在hashed locking的情況下，雖然每個lock element包含多個block,預設的blocking factor僅僅是一個塊.對於多塊讀取這種操作，這意味著每個連續的塊必須持有不同的pcm instance lock.
但是，如果採取多塊讀取的次數等於blocking factor,每個多塊讀只需要一個pcm instance lock.對於全域性可見的資料,這會減少pcm instance lock獲取，進而減少了例項間通訊的訊息數量.減少鎖獲取也同樣會減少
對於修改資料的pings。這是因為在這一個單一的ping操作時，遠端例項將會release所有以非相容模式持有的鎖覆蓋的資料塊.

    很顯然（很明顯）clearly,配置 大一點的blocking factor，對於資料檔案包含經常發生多塊讀取操作的表，是非常合理的，特別是，假如它們全域性可見且修改.但是如果使用一個非常大的blocking factor,有時就會把大量的buffers
連結到獨立或不同的(每個）lock elements,就會引起覆蓋這些lock elements的lock element parent latches的競爭可能性.
而且，假如在表上出現一些熱點區域，一個大點的block factor會增大發生false pings的可能性.然而，一個blocking factor大小几倍於多塊讀次數，對於這些資料檔案是很正常或合適的.對rollback segments設定一個大點的blocking factor也是合適的.


     索引 比表和rollback segment的問題更多，特別是全域性可見的索引且必須要修改。首先，必須要對單向遞增的主鍵索引使用反向鍵索引,以免發生過多的pcm instance lock的競爭，這些pcm instance覆蓋或佔據索引的右邊的葉子塊.
oracle knows few forms of contention so debilitating as this slow motion game of ping-pong.
     
     對於全域性可見和更新的索引一般情況，經常建議用fine-grained locking來對抗false pings.依我之見，確實，這種情況應採用fine-grained locking,甚至even then你正常情況下為了支援繁重的hashed locking 應該拒絕它.


     我勉強或暫且同意繁重的hashed locking需要一些重多的lock elements和instance lock resources 和locks.但是記憶體現在很cheap.somewhat more telling is
the complaint that heavy hashed locking（有些更要說的就是抱怨繁重的hashed locking)，因為這樣會持有大量的instance locks,當有必要時，在例項例重新分配時，這會增強或增大降級可用性的週期.另一方面，假如任何資料檔案使用fine-grained locking，進行
例項恢復期間的事務恢復階段，預設資料庫是被凍結的.假如使用相對更少的fine-grained locks，使用_freeze_db_for_fast_instance_recovery可以改變預設配置.
但是假如需要漫長時間進行事務恢復,採用hashed locking更為可取.但是，支援繁重hashed locking的決定性論據，就是減少或降低持有例項鎖的成本，這在大多數情況下比false pings的效能影響更重要.


    經常發生fast full scan的索引也會得益於blocking factor.但是，索引對於false pings比表更為敏感，因此建議採用
一個更為適度的blocking factor.
   
    總體來說，我的建議就是你應為所有資料檔案使用releasable hashed locking，這樣全域性可見和更新資料上面的lock elements會出現更為嚴重的集中(with a heavier concentration of lock elements on globally
visible and updated data)或譯為：對於全域性可見和更新資料上面的lock elements會出現更為嚴重的集中.





other instance locks
      還有一些例項鎖，用於控制並行伺服器資料庫中一些操作。比如，sm(smon)instance lock用於確保不能同時啟用多個smon程式.同樣，dr(distributed recovery)分散式恢復instance lock用於確保任何時刻只有一個reco程式是活動的.


df(data file) instance locks是另一種鎖.每個資料檔案有一個df resource,每個dbwn程式對每個dr資源持有一個共享模式的鎖.如果一個資料檔案在一個例項中offline,然後會告訴遠端dbwn程式，不用再嘗試往這個資料檔案寫入，這是透過
轉變這個資源(df)上面例項鎖的模式來完成.




引數





引數                                                               描述

_freeze_db_for_fast_instance_recovery                              無論例項恢復期間所進行的事務恢復階段，是否凍結資料庫活動.假如任何資料檔案使用fine-grained locking預設是true


_gc_class_locks