OracleRedo並行機制

Redo log 是用於恢復和一個高級特性的重要數據一個redo條目包含了相應操作導致的數據庫變化的所有信息所有redo條目最終都要被寫入redo文件中去Redo log buffer是為了避免Redo文件IO導致性能瓶頸而在sga中分配出的一塊內存一個redo條目首先在用戶內存(PGA)中產生然後由oracle服務進程拷貝到log buffer中當滿足一定條件時再由LGWR進程寫入redo文件由於log buffer是一塊共享內存為了避免沖突它是受到redo allocation latch保護的每個服務進程需要先獲取到該latch才能分配redo buffer因此在高並發且數據修改頻繁的oltp系統中我們通常可以觀察到redo allocation latch的等待Redo寫入redo buffer的整個過程如下

　　在PGA中生產Redo Enrey > 服務進程獲取Redo Copy latch(存在多個CPU_COUNT*) > 服務進程獲取redo allocation latch(僅個) > 分配log buffer > 釋放redo allocation latch > 將Redo Entry寫入Log Buffer > 釋放Redo Copy latch;

　　shared strand

　　為了減少redo allocation latch等待在oracle 中引入了log buffer的並行機制其基本原理就是將log buffer劃分為多個小的buffer這些小的buffer被成為strand(為了和之後出現的private strand區別它們被稱之為shared strand)每一個strand受到一個單獨redo allocation latch的保護多個shared strand的出現使原來序列化的redo buffer分配變成了並行的過程從而減少了redo allocation latch等待

　　shared strand的初始數據量是由參數log_parallelism控制的;在g中該參數成為隱含參數並新增參數_log_parallelism_max控制shared strand的最大數量;_log_parallelism_dynamic則控制是否允許shared strand數量在_log_parallelism和_log_parallelism_max之間動態變化

HELLODBACOM>select  namksppinm valKSPPSTVL namksppdesc    
    from    sysx$ksppi nam    
            sysx$ksppsv val    
    where namindx = valindx    
    AND   namksppinm LIKE _%    
    AND   upper(namksppinm) LIKE %LOG_PARALLE%;    
  
KSPPINM                    KSPPSTVL   KSPPDESC    
    
_log_parallelism                     Number of log buffer strands    
_log_parallelism_max                 Maximum number of log buffer strands    
_log_parallelism_dynamic   TRUE       Enable dynamic strands    

　　每一個shared strand的大小 = log_buffer/(shared strand數量)strand信息可以由表x$kcrfstrand查到(包含shared strand和後面介紹的private strandg以後存在)　

HELLODBACOM>select indxstrand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != ;    
  
      INDX STRAND_SIZE_KCRFA    
    
                        
                        
  
HELLODBACOM>show parameter log_buffer    
  
NAME                                 TYPE        VALUE    
    
log_buffer                           integer       

　　關於shared strand的數量設置個cpu之內最大默認為當系統中存在redo allocation latch等待時每增加個cpu可以考慮增加個strand最大不應該超過並且_log_parallelism_max不允許大於cpu_count

　　注意在g中參數_log_parallelism被取消shared strand數量由_log_parallelism_max_log_parallelism_dynamic和cpu_count控制

　　Private strand

　　為了進一步降低redo buffer沖突在g中引入了新的strand機制——Private strandPrivate strand不是從log buffer中劃分的而是在shared pool中分配的一塊內存空間　

HELLODBACOM>select * from V$sgastat where name like %strand%;

　　POOL NAME BYTES

　　

　　shared pool private strands

　　HELLODBACOM>select indxstrand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa = ;

　　INDX STRAND_SIZE_KCRFA

　　

　　

　　

　　

　　

　　

　　

　　

　　

　　Private strand的引入為Oracle的Redo/Undo機制帶來很大的變化每一個Private strand受到一個單獨的redo allocation latch保護每個Private strand作為私有的strand只會服務於一個活動事務獲取到了Private strand的用戶事務不是在PGA中而是在Private strand生成Redo當flush private strand或者commit時Private strand被批量寫入log文件中如果新事務申請不到Private strand的redo allocation latch則會繼續遵循舊的redo buffer機制申請寫入shared strand中事務是否使用Private strand可以由x$ktcxb的字段ktcxbflg的新增的第位鑒定

　HELLODBACOM>select decode(bitand(ktcxbflg )) used_private_strand count(*)

　　 from x$ktcxb

　　 where bitand(ksspaflg ) !=

　　 and bitand(ktcxbflg ) !=

　　 group by bitand(ktcxbflg );

　　USED_PRIVATE_STRAND COUNT(*)

　　

　　

　　

　　對於使用Private strand的事務無需先申請Redo Copy Latch也無需申請Shared Strand的redo allocation latch而是flush或commit是批量寫入磁盤因此減少了Redo Copy Latch和redo allocation latch申請/釋放次數也減少了這些latch的等待從而降低了CPU的負荷過程如下

　　事務開始 > 申請Private strand的redo allocation latch (申請失敗則申請Shared Strand的redo allocation latch) > 在Private strand中生產Redo Enrey > Flush/Commit > 申請Redo Copy Latch > 服務進程將Redo Entry批量寫入Log File > 釋放Redo Copy Latch > 釋放Private strand的redo allocation latch

　　注意對於未能獲取到Private strand的redo allocation latch的事務在事務結束前即使已經有其它事務釋放了Private strand也不會再申請Private strand了

　　每個Private strand的大小為Kg中shared pool中的Private strands的大小就是活躍會話數乘以K而g中在shared pool中需要為每個Private strand額外分配k的管理空間即數量*k

　g:

　　SQL> select * from V$sgastat where name like %strand%;

　　POOL NAME BYTES

　　

　　shared pool private strands

　　HELLODBACOM>select trunc(value * KSPPSTVL / ) * *

　　 from (select value from v$parameter where name = transactions) a

　　 (select valKSPPSTVL

　　 from sysx$ksppi nam sysx$ksppsv val

　　 where namindx = valindx

　　 AND namksppinm = _log_private_parallelism_mul) b;

　　TRUNC(VALUE*KSPPSTVL/)**

　　

　　

　　g:

　　HELLODBACOM>select * from V$sgastat where name like %strand%;

　　POOL NAME BYTES

　　

　　shared pool private strands

　　HELLODBACOM>select trunc(value * KSPPSTVL / ) * ( + ) *

　　 from (select value from v$parameter where name = transactions) a

　　 (select valKSPPSTVL

　　 from sysx$ksppi nam sysx$ksppsv val

　　 where namindx = valindx

　　 AND namksppinm = _log_private_parallelism_mul) b;

　　TRUNC(VALUE*KSPPSTVL/)*(+)*

　　

　　

　　Private strand的數量受到個方面的影響logfile的大小和活躍事務數量

　　參數_log_private_mul指定了使用多少logfile空間預分配給Private strand默認為我們可以根據當前logfile的大小(要除去預分配給log buffer的空間)計算出這一約束條件下能夠預分配多少個Private strand　

HELLODBACOM>select bytes from v$log where status = CURRENT;

　　BYTES

　　

　　

　　HELLODBACOM>select trunc(((select bytes from v$log where status = CURRENT) (select to_number(value) from v$parameter where name = log_buffer))*

　　 (select to_number(valKSPPSTVL)

　　 from sysx$ksppi nam sysx$ksppsv val

　　 where namindx = valindx

　　 AND namksppinm = _log_private_mul) / / )

　　 as calculated private strands

　　 from dual;

　　calculated private strands

　　

　　

　　HELLODBACOM>select count() actual private strands from x$kcrfstrand where last_buf_kcrfa = ;

　　actual private strands

　　

　　

　　當logfile切換後(和checkpoint一樣切換之前必須要將所有Private strand的內容flush到logfile中因此我們在alert log中可能會發現日志切換信息之前會有這樣的信息Private strand flush not complete這是可以被忽略的)會重新根據切換後的logfile的大小計算對Private strand的限制

　HELLODBACOM>alter system switch logfile;

　　System altered

　　HELLODBACOM>select bytes from v$log where status = CURRENT;

　　BYTES

　　

　　

　　HELLODBACOM>select trunc(((select bytes from v$log where status = CURRENT) (select to_number(value) from v$parameter where name = log_buffer))*

　　 (select to_number(valKSPPSTVL)

　　 from sysx$ksppi nam sysx$ksppsv val

　　 where namindx = valindx

　　 AND namksppinm = _log_private_mul) / / )

　　 as calculated private strands

　　 from dual;

　　calculated private strands

　　

　　

　　HELLODBACOM>select count() actual private strands from x$kcrfstrand where last_buf_kcrfa = ;

　　actual private strands

　　

　　

　　參數_log_private_parallelism_mul用於推算活躍事務數量在最大事務數量中的百分比默認為Private strand的數量不能大於活躍事務的數量

HELLODBACOM>show parameter transactions

　　NAME TYPE VALUE

　　

　　transactions integer

　　transactions_per_rollback_segment integer

　　HELLODBACOM>select trunc((select to_number(value) from v$parameter where name = transactions) *

　　 (select to_number(valKSPPSTVL)

　　 from sysx$ksppi nam sysx$ksppsv val

　　 where namindx = valindx

　　 AND namksppinm = _log_private_parallelism_mul) / )

　　 as calculated private strands

　　 from dual;

　　calculated private strands

　　

　　

　　HELLODBACOM>select count() actual private strands from x$kcrfstrand where last_buf_kcrfa = ;

　　actual private strands

　　

　　

　　注在預分配Private strand時會選擇上述個條件限制下最小一個數量但相應的shared pool的內存分配和redo allocation latch的數量是按照活躍事務數預分配的

　　因此如果logfile足夠大_log_private_parallelism_mul與實際活躍進程百分比基本相符的話Private strand的引入基本可以消除redo allocation latch的爭用問題

From:http://tw.wingwit.com/Article/program/Oracle/201311/17848.html