我們今天主要介紹的是Redo log 恢復與高級特性的重要相關(guān)數(shù)據(jù)，我們大家都知道一個Oracle redo條目包含了相應(yīng)操作導致的數(shù)據(jù)庫變化的所有的信息，所有redo條目最終都要被寫入redo文件中去。

成都創(chuàng)新互聯(lián)技術(shù)團隊十載來致力于為客戶提供成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計、品牌網(wǎng)站制作、營銷型網(wǎng)站建設(shè)、搜索引擎SEO優(yōu)化等服務(wù)。經(jīng)過多年發(fā)展，公司擁有經(jīng)驗豐富的技術(shù)團隊，先后服務(wù)、推廣了1000+網(wǎng)站，包括各類中小企業(yè)、企事單位、高校等機構(gòu)單位。

Redo log buffer是為了避免Redo文件IO導致性能瓶頸而在sga中分配出的一塊內(nèi)存。

一個redo條目首先在用戶內(nèi)存(PGA)中產(chǎn)生，然后由oracle服務(wù)進程拷貝到log buffer中，當滿足一定條件時，再由LGWR進程寫入Oracle redo文件。

由于log buffer是一塊“共享”內(nèi)存，為了避免沖突，它是受到redo allocation latch保護的，每個服務(wù)進程需要先獲取到該latch才能分配redo buffer。因此在高并發(fā)且數(shù)據(jù)修改頻繁的oltp系統(tǒng)中，我們通常可以觀察到redo allocation latch的等待。Redo寫入redo buffer的整個過程如下：

在PGA中生產(chǎn)Redo Enrey -> 服務(wù)進程獲取Redo Copy latch(存在多個---CPU_COUNT*2) -> 服務(wù)進程獲取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(為了和之后出現(xiàn)的private strand區(qū)別，它們被稱之為shared strand)。

每一個strand受到一個單獨redo allocation latch的保護。多個shared strand的出現(xiàn)，使原來序列化的redo buffer分配變成了并行的過程，從而減少了Oracle redo allocation latch等待。

shared strand的初始數(shù)據(jù)量是由參數(shù)log_parallelism控制的;在10g中，該參數(shù)成為隱含參數(shù)，并新增參數(shù)_log_parallelism_max控制shared strand的***數(shù)量;_log_parallelism_dynamic則控制是否允許shared strand數(shù)量在_log_parallelism和_log_parallelism_max之間動態(tài)變化。

 
 
 

  
  
  
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數(shù)量)。strand信息可以由表x$kcrfstrand查到(包含shared strand和后面介紹的private strand，10g以后存在)?！?/p>

 
 
 

  
  
  
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  
 
 
 

關(guān)于shared strand的數(shù)量設(shè)置，16個cpu之內(nèi)***默認為2，當系統(tǒng)中存在Oracle redo allocation latch等待時，每增加16個cpu可以考慮增加1個strand，***不應(yīng)該超過8。并且_log_parallelism_max不允許大于cpu_count。

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

 
 
 

  
  
  
Private strand
 
 
 

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

 
 
 

  
  
  
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的Oracle Redo/Undo機制帶來很大的變化。每一個Private strand受到一個單獨的redo allocation latch保護，每個Private strand作為“私有的”strand只會服務(wù)于一個活動事務(wù)。

獲取到了Private strand的用戶事務(wù)不是在PGA中而是在Private strand生成Redo，當flush private strand或者commit時，Private strand被批量寫入log文件中。如果新事務(wù)申請不到Private strand的redo allocation latch，則會繼續(xù)遵循舊的redo buffer機制，申請寫入shared strand中。事務(wù)是否使用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的事務(wù)，無需先申請Oracle Redo Copy Latch，也無需申請Shared Strand的redo allocation latch，而是flush或commit是批量寫入磁盤，因此減少了Redo Copy Latch和redo allocation latch申請/釋放次數(shù)、也減少了這些latch的等待，從而降低了CPU的負荷。過程如下：

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

注意：對于未能獲取到Private strand的Oracle redo allocation latch的事務(wù)，在事務(wù)結(jié)束前，即使已經(jīng)有其它事務(wù)釋放了Private strand，也不會再申請Private strand了

網(wǎng)頁名稱：OracleRedo的并行機制運行中要用到的代碼
URL鏈接：http://uogjgqi.cn/article/cdhoghh.html