<form id="tznrh"><form id="tznrh"><th id="tznrh"></th></form></form>

            根據前面系列的文章的解釋,我們知道PCM資源的Master節點是通過hash算法得出。那么在一個多節點的RAC集群中,數據塊請求節點和存放它的相關鎖元素信息節點有很大概率是不相同的。這就意味著用戶對資源的請求會存在很多的2或3次回路,從而造成很多的消息通信增加私網的負載進而影響影響數據庫的性能。為了緩解這種性能影響,Oracle使用資源的remaster來減少資源的跨節點請求。針對某一個數據庫對象的的訪問次數和方式,來決定數據庫對象對應的buffer應該被mastering 到哪一個實例。這里的“訪問”更明確地說是請求BL鎖。


            其實早在9i版本,Oracle就意識到這個問題并開始引入了我們一般都不會注意到的隱含參數包括:_lm_dynamic_remastering,_lm_dynamic_lms,_lm_file_affinity,_lm_dynamic_load 可以通過SQL語句查看參數描述:


            SELECT KSPPINM AS "hidden parameter",
            
            KSPPSTVL AS "value",
            
            KSPPDESC "description"
            
            FROM X$KSPPI
            
            JOIN X$KSPPCV
            
            USING (INDX)
            
            WHERE KSPPINM LIKE "\_%" ESCAPE ""
            
            AND KSPPINM LIKE "_lm_%"
            
            ORDER BY KSPPINM;




            10.1版本開始Oracle正式支持file affinity。10.2版本Oracle進行了優化將file affinity進行細化為object affinityundo affinity,并記錄系統的負載信息(默認由參數_lm_lhupd_interval控制)。file affinity由下面兩個參數來控制:

            _gc_policy_time :單位為分鐘,控制DRM統計實例訪問buffer次數的時間間隔,默認為是10分鐘。

            _gc_affinity_ratio:控制進行remastering所需要達到的最小比例(閥值),默認為50。也就是說,如果某個實例在10分鐘。

            object affinity:根據一段時間內(默認10分鐘),如果某一個實例訪問某個數據庫對象次數高于其他實例一定倍數(默認50倍),則oracle 會把這個對象所有的buffer的master信息,轉移到對應實例(注意:不是轉移buffer)。當oracle 決定將一個buffer的master實例確定到本地實例后,會對這個buffer上加上affinity lock,來實現快速的訪問。


            DRM過程會存在如下幾個階段:
            1.QuiescsLmon通知所有實例,準備進行remastering。
            2.FreezeOracle停止所有在需要進行remasteringbuffer上的操作。
            3.
            Cleanup在舊的master實例清除對應buffermaster信息。
            4.
            Rebuildmaster信息傳遞給新的master實例,在新的master實例構建資源的最新狀態。
            5.
            Unfreeze結束,并釋放所有之前所有步驟占用的資源。

            注意:DRM是漸進的,也就是說以windows為單位,每次對一部分的buffer 進行remastering操作。

            從這個流程我其實就知道DRM雖好但是存在的問題也很明顯,即在DRM過程中對涉及的數據塊的請求都將被阻塞。因此Oracle一直在不斷的優化DRM動作,希望能夠減少DRM帶來的影響。11g版本減少DRM給系統帶來的影響Oracle進行了如下幾處優化:

            1.read-mostly locking(讀多寫少):簡單的說就是,對于某個對象,比如讀非常多,所有結點都會持有一個鎖,減少了共享鎖申請操作。而當需要寫操作時,需申請排它鎖時,在每個結點上都申請一個”anti-lock”鎖,可以理解為”反鎖”,然后再cache fusion。

            2.reader bypass(寫少讀多):主要是為讀少寫多的業務進行的優化。reader bypass同樣引入了一種新的鎖模式weak X lock(又稱xw鎖)??梢栽?/span>S鎖沒有釋放以前,為一個block加上一個xw鎖,對這個block進行修改,但是不允許立刻commit,直到所有的的S鎖都關閉或者降級到N鎖,LMS就會向xw鎖的持有者發送一條信息可以進行commit了。

            3.Parallel DRM FreezeDRM發生的過程中會存在凍結階段(Freeze,即所有節點的LMS進程在收到LMON發出的消息后,通知所有節點的LMS進程在結束master信息遷移前不再接受對這些快的新的請求。那么對于一個繁忙的系統這個過程是無法忍受的,因此Oracle引入了并行DRM加快master信息的遷移速度,使用_drm_parallel_freeze參數控制,默認情況下啟用。

            4.DRM Batch request批量處理DRM請求使用參數_lm_drm_batch_time控制,默認為10s。

            5.DRM interval增大DRM觸發時間間隔,針對連續的DRM動作時間間隔至少為120s,由參數_lm_drm_min_interval控制。

            6.Read Mostly數據固化:早先版本針對DRMReadMostly系統統計信息會隨著實例的重啟而被重置,為此從11.2.0.3版本開始,默認支持對read mostly的數據進行固化(通過_gc_persistent_read_mostly來實現)。

            7.drm hiload在數據庫負載很高的情況下,會暫時禁用DRM,數據庫負載下降以后又重新啟用DRM,由參數_lm_drm_hiload_percentage_lm_drm_lowload_percentage參數控制默認為200。


            Undo and affinity

            回滾段的Mastering和其它段不同,因為RAC環境中的每個實例均有各自自己的undo表空間?;貪L段的remastering是不會因為另外一個節點對于回滾段有大量讀取而發生的。只有在某個實例失效,為了進行實例恢復的需要,集群中負責進行實例恢復的其他實例會暫時的成為這些回滾段的master,然后進行實例的恢復動作。undoremaster是由參數_gc_undo_affinity控制。

            12C版本Oracle繼續對DRM進行優化,Oracle在進行資源凍結的時候并非凍結所有資源。而是將資源分解為多個分區,以只凍結資源分區的這種方式極大地減少DRM相關等待的影響。LMON一次只凍結一個資源分區。第一個分區中的資源被凍結,完成資源重新創建任務,并解凍該資源分區。然后凍結下一個資源分區并繼續,直到重新創建所有資源。除此之外12c還引入了很多相關的Latch機制(gcsaffinity object freelist latch)和統計信息鏈表(affinity statsobjects freelist ,Objectaffinity stats數據是由lck0進程來進行維持,還引入了可以由用戶自定義read mostly實例的參數(_read_mostly_instance ,_read_mostly_instance_qa_control)。

            Parameter_high_priority_processes

            ValueLMS*|VKTM|LM*|LCK0|GCR*|DIAG





            沃趣科技,讓客戶用上更好的數據庫技術!
            三分快3