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*2) -> 服務進程獲取redo allocation latch(僅1個) -> 分配log buffer -> 釋放redo allocation latch -> 將Redo Entry寫入Log Buffer -> 釋放Redo Copy latch;

　　shared strand

　　為了減少redo allocation latch等待，在oracle 9.2中，引入了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控制的;在10g中，該參數成為隱含參數，并新增參數_log_parallelism_max控制shared strand的最大數量;_log_parallelism_dynamic則控制是否允許shared strand數量在_log_parallelism和_log_parallelism_max之間動態變化。

　　HELLODBA.COM>select nam.ksppinm, val.KSPPSTVL, nam.ksppdesc
　　2 from sys.x$ksppi nam,
　　3 sys.x$ksppsv val
　　4 where nam.indx = val.indx
　　5 --AND nam.ksppinm LIKE '_%'
　　6 AND upper(nam.ksppinm) LIKE '%LOG_PARALLE%';
　　KSPPINM KSPPSTVL KSPPDESC
　　-------------------------- ---------- ------------------------------------------
　　_log_parallelism 1 Number of log buffer strands
　　_log_parallelism_max 2 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 strand，10g以后存在)。

　　HELLODBA.COM>select indx,strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != '00';
　　INDX STRAND_SIZE_KCRFA
　　---------- -----------------
　　0 3514368
　　1 3514368
　　HELLODBA.COM>show parameter log_buffer
　　NAME TYPE VALUE
　　------------------------------------ ----------- ------------------------------
　　log_buffer integer 7028736

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

　　注意：在11g中，參數_log_parallelism被取消，shared strand數量由_log_parallelism_max、_log_parallelism_dynamic和cpu_count控制。

　　Private strand

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

　　HELLODBA.COM>select * from V$sgastat where name like '%strand%';
　　POOL NAME BYTES
　　------------ -------------------------- ----------
　　shared pool private strands 2684928
　　HELLODBA.COM>select indx,strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa = '00';
　　INDX STRAND_SIZE_KCRFA
　　---------- -----------------
　　2 66560
　　3 66560
　　4 66560
　　5 66560
　　6 66560
　　7 66560
　　8 66560
　　...

 　　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的新增的第13位鑒定：

　　HELLODBA.COM>select decode(bitand(ktcxbflg, 4096),0,1,0) used_private_strand, count(*)
　　2 from x$ktcxb
　　3 where bitand(ksspaflg, 1) != 0
　　4 and bitand(ktcxbflg, 2) != 0
　　5 group by bitand(ktcxbflg, 4096);
　　USED_PRIVATE_STRAND COUNT(*)
　　------------------- ----------
　　1 10
　　0 1

 　　對于使用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的大小為65K。10g中，shared pool中的Private strands的大小就是活躍會話數乘以65K，而11g中，在shared pool中需要為每個Private strand額外分配4k的管理空間，即：數量*69k。

　　--10g:
　　SQL> select * from V$sgastat where name like '%strand%';
　　POOL NAME BYTES
　　------------ -------------------------- ----------
　　shared pool private strands 1198080
　　HELLODBA.COM>select trunc(value * KSPPSTVL / 100) * 65 * 1024
　　2 from (select value from v$parameter where name = 'transactions') a,
　　3 (select val.KSPPSTVL
　　4 from sys.x$ksppi nam, sys.x$ksppsv val
　　5 where nam.indx = val.indx
　　6 AND nam.ksppinm = '_log_private_parallelism_mul') b;
　　TRUNC(VALUE*KSPPSTVL/100)*65*1024
　　-------------------------------------
　　1198080
　　--11g:
　　HELLODBA.COM>select * from V$sgastat where name like '%strand%';
　　POOL NAME BYTES
　　------------ -------------------------- ----------
　　shared pool private strands 706560
　　HELLODBA.COM>select trunc(value * KSPPSTVL / 100) * (65 + 4) * 1024
　　2 from (select value from v$parameter where name = 'transactions') a,
　　3 (select val.KSPPSTVL
　　4 from sys.x$ksppi nam, sys.x$ksppsv val
　　5 where nam.indx = val.indx
　　6 AND nam.ksppinm = '_log_private_parallelism_mul') b;
　　TRUNC(VALUE*KSPPSTVL/100)*(65+4)*1024
　　-------------------------------------
　　706560

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

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

　　HELLODBA.COM>select bytes from v$log where status = 'CURRENT';
　　BYTES
　　----------
　　52428800
　　HELLODBA.COM>select trunc(((select bytes from v$log where status = 'CURRENT') - (select to_number(value) from v$parameter where name = 'log_buffer'))*
　　2 (select to_number(val.KSPPSTVL)
　　3 from sys.x$ksppi nam, sys.x$ksppsv val
　　4 where nam.indx = val.indx
　　5 AND nam.ksppinm = '_log_private_mul') / 100 / 66560)
　　6 as "calculated private strands"
　　7 from dual;
　　calculated private strands
　　--------------------------
　　5
　　HELLODBA.COM>select count(1) "actual private strands" from x$kcrfstrand where last_buf_kcrfa = '00';
　　actual private strands
　　----------------------
　　5

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

　　HELLODBA.COM>alter system switch logfile;
　　System altered.
　　HELLODBA.COM>select bytes from v$log where status = 'CURRENT';
　　BYTES
　　----------
　　104857600
　　HELLODBA.COM>select trunc(((select bytes from v$log where status = 'CURRENT') - (select to_number(value) from v$parameter where name = 'log_buffer'))*
　　2 (select to_number(val.KSPPSTVL)
　　3 from sys.x$ksppi nam, sys.x$ksppsv val
　　4 where nam.indx = val.indx
　　5 AND nam.ksppinm = '_log_private_mul') / 100 / 66560)
　　6 as "calculated private strands"
　　7 from dual;
　　calculated private strands
　　--------------------------
　　13
　　HELLODBA.COM>select count(1) "actual private strands" from x$kcrfstrand where last_buf_kcrfa = '00';
　　actual private strands
　　----------------------
　　13

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

　　HELLODBA.COM>show parameter transactions
　　NAME TYPE VALUE
　　------------------------------------ ----------- ------------------------------
　　transactions integer 222
　　transactions_per_rollback_segment integer 5
　　HELLODBA.COM>select trunc((select to_number(value) from v$parameter where name = 'transactions') *
　　2 (select to_number(val.KSPPSTVL)
　　3 from sys.x$ksppi nam, sys.x$ksppsv val
　　4 where nam.indx = val.indx
　　5 AND nam.ksppinm = '_log_private_parallelism_mul') / 100 )
　　6 as "calculated private strands"
　　7 from dual;
　　calculated private strands
　　--------------------------
　　22
　　HELLODBA.COM>select count(1) "actual private strands" from x$kcrfstrand where last_buf_kcrfa = '00';
　　actual private strands
　　----------------------
　　22

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

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