Oracle Redo 并行机制
?
?????? 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之間動態變化。
?
SQL>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以后存在）。
?
SQL>select?indx,strand_size_kcrfa?from?x$kcrfstrand?where?last_buf_kcrfa?!=?'00'; ??
??
??????INDX?STRAND_SIZE_KCRFA ??
----------?----------------- ??
?????????0???????????3514368 ??
?????????1???????????3514368 ??
??
SQL>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中分配的一塊內存空間。
?
SQL>select?*?from?V$sgastat?where?name?like?'%strand%'; ??
??
POOL?????????NAME????????????????????????????BYTES ??
------------?--------------------------?---------- ??
shared?pool??private?strands???????????????2684928 ??
??
SQL>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位鑒定：
?
SQL>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 事務過程如下：
??? 事務開始 -> 申請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 ??
??
SQL>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: ??
SQL>select?*?from?V$sgastat?where?name?like?'%strand%'; ??
??
POOL?????????NAME????????????????????????????BYTES ??
------------?--------------------------?---------- ??
shared?pool??private?strands????????????????706560 ??
??
SQL>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：
?
SQL>select?bytes?from?v$log?where?status?=?'CURRENT'; ??
??
?????BYTES ??
---------- ??
??52428800 ??
??
SQL>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 ??
??
SQL>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的限制：
?
SQL>alter?system?switch?logfile; ??
System?altered. ??
??
SQL >select?bytes?from?v$log?where?status?=?'CURRENT'; ??
?????BYTES ??
---------- ??
?104857600 ??
SQL>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 ??
??
SQL >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的數量不能大于活躍事務的數量。
?
?
SQL >show?parameter?transactions ??
??
NAME?????????????????????????????????TYPE????????VALUE ??
------------------------------------?-----------?------------------------------ ??
transactions?????????????????????????integer?????222 ??
transactions_per_rollback_segment????integer?????5 ??
?
SQL >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 ??
??
SQL >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的爭用問題。
?
?
?
?
轉自Hello DBA
http://www.hellodba.com/Doc/Oracle_redo_strand_cn.html
?
?
------------------------------------------------------------------------------
Blog： http://blog.csdn.net/tianlesoftware
網上資源： http://tianlesoftware.download.csdn.net
相關視頻：http://blog.csdn.net/tianlesoftware/archive/2009/11/27/4886500.aspx
DBA1 群：62697716(滿); DBA2 群：62697977(滿)
DBA3 群：62697850?? DBA 超級群：63306533;????
聊天 群：40132017
--加群需要在備注說明Oracle表空間和數據文件的關系，否則拒絕申請
轉載于:https://www.cnblogs.com/tianlesoftware/archive/2010/11/17/3609918.html
總結
以上是生活随笔為你收集整理的Oracle Redo 并行机制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HDU 2573 HDOJ 2573 T
- 下一篇： 软件该如何定位？